[Feature request] Whitelisting which components can render within a block component about rfcs HOT 12 CLOSED

What is the actual use case here? It seems odd to attempt to limit the consumer of your component like this...

from rfcs.

To reply to @rwjblue comment on emberjs/ember.js#12968 (comment)

Here are a few examples I think could have benefited from this pattern:

A "navBar" component, that can only have "button" and "title" components. As the component's developer being able to only whitelist btn and title makes sure I have an integral control on the component's render state (ie. styles).

{{#nav-bar as |btn title|}}
  {{btn icon="hamburger"}}
  {{title}}Hello World{{title}}
  {{btn icon="paper-plane"}}
  {{btn icon="search"}}
  Hello World. <-- This should not render!
{{/nav-bar}}

While this example demonstrate a purely "aesthetic" consideration, I've encountered multiple cases where I wanted to whitelist the elements being render for functional purposes.

For example: a horizontal-item-scroller component. In my specific case I'm using an external library to align elements within a carousel. These elements require specific class and tag names to work correctly. Therefore I'm introducing composable components that abstract setting these attributes on the element.

Adding an element that doesn't follow this API actually brakes the whole carousel (it's no better than not showing it)

{{#horizontal-item-scroller as |item big-item|}}
  {{#item}}Render this{{/item}}
  {{#big-item}}Render this{{/big-item}}
  {{#whatever}}Don't render this{{/whatever}}
{{/horizontal-item-scroller}}

from rfcs.

I don't think it makes sense to add this to the core framework, but I am definitely interested in exposing the hooks necessary to make this possible from an addon.

from rfcs.

@tomdale do you have a vague idea of which hooks could be leveraged to achieve this result? Even if they're private - for research purposes.

from rfcs.

If you really want that level of control, I would suggest not yielding. Yielding implies giving up control over what goes inside, and is why it's called "yield".

A nav bar that wants to define a restricted API can do so via it's own arguments, including taking components (with bound arguments and everything) as arguments, like:

{{nav-bar items=items button=(component "fancy-button" mode="wonderful") }}

from rfcs.

@ef4 I think attributes works OK when the number of arguments can be kept at a minimum level. It's not always possible. Imagine a jQuery.masonry wrapper that requires children elements to be wrapped inside specific elements (as that's the only way for them to be positioned correctly).

{{#masonry
  as |masonry-item|
}}
  {{!-- can have many, many, many of them !--}}
  {{#masonry-item}}
    Hello World.
  {{/masonry-item}}
{{/masonry}}

While I understands what yield does and why it was called like that, I don't think it's a strong enough argument against challenging its limits. It's not because it's named one way that we should never attempt to touch it nor question it.

Composable components are offering developers a great way to define declarative API. I'm sure they're only going to grow in popularity (especially when you see what the guys achieved with https://github.com/reactjs/react-router) and new patterns will emerge. I think exposing the relevant hooks for developers to be able to build upon it is a step in the right direction.

from rfcs.

Contextual handling of HTML/components has been anticipated by Glimmer, but still needs a long time to bake and it's not clear we want the feature at all as it complicates the mental model. The idea is to enable things like

<super-layout>
  <row> ... </row>
  <row> ... </row>
  <div> </div>     {{! this could throw a compile time error }}
  foo              {{! so could this }}
</super-layout>

The feature would have a similar spirit to the <table> element in HTML and its contextual handling of <thead>, <tbody>, etc.

from rfcs.

@mmun where is it possible to follow the progress on this one?

from rfcs.

It should be possible to do this sort of assertion today via at least two mechanisms (possibly more):

• check the DOM in didInsertElement for development builds (via Ember.runInDebug), and throwing/asserting if you find malformed contents (this is public API)
• write an AST transform that runs at template compile time, and asserts when invalid content exists (AST transforms are private API)

from rfcs.

@rwjblue thanks

from rfcs.

@olivierlesnicki I think this is superseded by #454 ?

from rfcs.

Closing!

from rfcs.