Introducing Pages - A component convention to manage pages

Previously on...

• Widgets introduction
• Input-set "pattern" in Widgets
• Read-only primitives in Widgets

And now...

Ok, boys, girls, another people that thinks that you can decide wherever pasta is rice just cause it defines it self as such, right now I had published two of my ways to manages components. I currently separate my angular components into 3 categories, based on what their concern is, widgets, to manage the look of them, components, to manage the behavior of them, and as I will introduce to you today, pages, to manage well, pages.

What a page is?

A page is this. What you are looking, what the user will look. Most of the time will be a component that will no be referenced by its selector, but by the router at a certain url. And that its the is first difference between a page component and a regular component.

• A page can contain another pages

For sure. But, they all should be represented by a url state, nothing more, nothing else. They should never be reference by it's selector, cause, then I won't be much of a page, would it?

• A page should not have a selector

If the @Component decorator does not have a selector them is unlikely to reference a page by such. I think is just safer to not do so.

• A page should not have a behavior

Much as our AppComponent, or wherever you call the entry component of your application, the logic there should be minimum. Most of the AppComponent delegates the behavior to their inner components, the router, and the services.

• A page must have components only

Well, you have to show something after all. But, why components only? Well, it happens that if you put a widget there, them is more likely to put the logic of that widget inside your page, and it should not be there.

• A page should have end-to-end test

This is what you user will interact, so I think is logic to put aside this your e2e for that page. If your components should have a unit test beside them, and your widgets should... I think they should have a unit test as well, then your pages should contain nothing more than e2e tests. After all you test all your components. Right? RIGHT? 'Cause I don't.

A page

What would be life without examples to copy-paste? Well, I'm sorry, this is just too useless to be copy-pasted. But still, I hope this idea keeps in you mind.

import { Component } from '@angular/core';

@Component({
  template: `
    <my-add-todo></my-add-todo>
    <my-visible-todo-list></my-visible-todo-list>
    <my-filter-buttons-widget></my-filter-buttons-widget>
  `,
})
export class TodoPage {}

In this example we can see how a todo page would be. When you navigate to /todo url you would know exactly what to expect, only the components you previously defined, with the behavior you put into them.

Thanks you!

As always, I hope you liked this post, and I'm very thankful that you read all of it. If you have comments about it, ideas or just want to say that this should not be like this, please, use the comment section below. I'm looking forward to read you too.