Covalent: Query: Why few children of layout container are custom elements & few are directives

[thekalinga]

Currently, The td-layout-nav-list & in other layouts, some of the children like td-layout-footer-inner are custom elements, where as few other children needs to marked via custom attribute td-sidenav-content.

I'm not sure why one has to be a custom element, where as the other has to be an attribute. This creates unnecessary confusion for anyone who is writing the code.

If you look at md-content of md-card (or) md-sidenav, they are explicitly made them elements instead of making them attributes. The problem with having both elements & attributes is that it is not very easy to identify whether a given custom element's child should be an element (or) we should trigger it via an attribute.

Would you mind sharing the reason why you chose to go with this approach.

[emoralesb05]

As you have said. They are just tag attrs being used as selectors so this creates less overhead in the DOM while giving the flexibility to use any component, but there are a few more reasons for this also.

Same approach done here:
https://github.com/angular/material2/blob/master/src/lib/list/list-item.html#L2-L4
and in other places.

The reason md-card-content and md-sidenav are components is because they have a specific purpose and display in md-card and md-layout-container.. same as td-footer.

For all the other ones, we try to keep it flexible so anybody can use any type of element or component.

The reason footer is different (following the same reasoning for md-card-content).. we wanted to keep footer simple and make people use it as part of the layout component, instead of something injected in the layout at a certain place + to avoid certain situations like this <a td-footer></a>.

[thekalinga]

Tho your explanation seems somewhat reasonable on the surface, I cant avoid thinking about lack of clearly defined guidelines which can help developer identify when he can expect an attribute & when he can expect an element.

For e.g, If we apply your last statement to the existing design, td-sidenav-content should be an element instead of attribute (currently it is attribute), as user can specify <a td-sidenav-content></a> instead of <div td-sidenav-content></div>

[emoralesb05]

And thats allowed because its already inside the inner md-sidenav context, so at that point we dont care if its div or a.. hence the we try to keep it flexible so anybody can use any type of element or component.. which is my point. (but for td-footer we do care)

[emoralesb05]

Think about it this way..

If you dont use td-layout-footer, then nothing gets rendered because the component is not part of the layout.. you include it on demand.

If you dont use [td-sidenav-content] or [td-toolbar-content].. the inner md-sidenav and md-toolbar will still render because they are the components (whatever you inject is part of them).. thus the naming of content and why we make them flexible so you can add any element.

[thekalinga]

Looks like the API exposed is dependent on the implementation rather than the end user (which is what I consider as a major problem with bootstrap).

IMO, unless we are talking about cases where performance matters significantly (such as massive tables/choices), having an extra div in the DOM should be an acceptable tradeoff if the API can be clean & intuitive.

[kyleledbetter]

Some of this is just a semantics debate at this point.
Another thing we consider is encapsulation. Sometimes you want totally control and scss bundled with an element, and in the layout specifically we need control over markup and scss encapsulation. We use content where we want to allow flexibility

[emoralesb05]

I think the issue in particular is the comparison point.

Trying to compare td-layout to md-card (or md-sidenav) is not possible.. when md-card has a single responsibility and its a smaller component.. and td-layout (and the other layouts) have multiple responsibilities and connect multiple components.. thus the need for both approaches.

We might add later on extra layout add-on components like td-navigation-drawer that leverage all that was stated before, and can collab with the attr selectors.

From this discussion, what i can see is the need for maybe a [td-footer] and/or [td-footer-inner] selectors (so everything is semantically the same), but i wouldn't say its not intuitive or that td-layout-footer is not needed.

There are times when there is a need for both like this: https://material.angular.io/components/component/dialog
and there is always a need to read docs.

[thekalinga]

@kyleledbetter Yes the question is about rationale, which certainly involves semantics. Your explanation sound very much like my earlier comment "API being affected by implementation, not to the component's API"

@emoralesb05 I agree that there is no standard pattern for choosing element over attribute. The only thing I was looking for was, having a consistent pattern that's well defined (with corner cases documented), so that user can predict whether he can expect a child element/an attribute depending on the component, rather than its implementation.

Agreed there is no substitute to reading docs, but intuition can eliminate a significant portion of docs lookup.

Thanks

[thekalinga]

I too am trying to find this pattern within material components aswell. Not yet figured that.

Will continue to document it. If I find my hypothesis about element vs attribute in material seems reasonable enough, I'll share it here.

[thekalinga]

Just published an IntellIJ/WebStrom plugin to ease my life & other developers life easy when working with

1. Angular Material 2
2. Angular Flex Layout
3. Covalent

This should ease the documentation lookup problem

[thekalinga]

Now published a vscode extension aswell

[emoralesb05]

Adding as a FAQ just in case it comes out again later, and closing issue.