Yet another named blocks/yields RFC

[sclaxton]

Rendered

[joukevandermaas]

Regarding the drawback related to else, it could be resolved by making {{else}} and {{:else}} equivalent, and {{yield to="inverse"}} and {{yield:else}} equivalent as a special case.

[sclaxton]

@joukevandermaas For sure. I don't think it's technical drawback really. I see it as more of a teaching/understanding drawback, since having two ways of doing the exact same thing is always undesirable.

[bendemboski]

I like where this is going! I have some feedback/questions:

1. Block names?

I don't quite understand why in their declaration the blocks have the string arguments ('B' and 'A'). What is the motivation for allowing the component to provide a string-name of the blocks that the invoking component can reference? It seems to just make it more confusing, although perhaps there's some value it provides that I'm not gleaning.

2. hasBlock?

I think we also need to extend the hasBlock functionality so components can determine which blocks were and weren't specified. Perhaps hasBlock:block-a? So a dialog component with an optional header and optional footer might look like this:

{{#if hasBlock:header}}
  <div class="dialog-header">
    {{yield:header}}
  </div>
{{/if}}
{{#if hasBlock}}
  <div class="dialog-body">
    {{yield}}
  </div>
{{/if}}
{{#if hasBlock:footer}}
  <div class="dialog-footer">
    {{yield:footer}}
  </div>
{{/if}}

In this particular case, the hasBlock check for the unnamed block is kinda silly, but I put it for illustration purposes.

3. Block ordering

The fact that when invoking, the default block content has to come first is restrictive. For example, if I'm invoking the dialog above with both the header and footer, with the current syntax, it would look like this:

{{#my-dialog}}
  This dialog illustrates how requiring the default block to be first is not always ideal.
{{:header}}
  Yo, read this!
{{:footer}}
  <button onclick={{action 'close'}}>Hmm...</button>
{{/my-dialog}}

I'd really like to be able to put my header content above my body content so it's more DOM-intuitive. One option for achieving this would be to allow (but not require) explicit declaration of the unnamed block -- something like:

{{#my-dialog:header}}
  Yo, read this!
{{:}}
  This dialog illustrates flexible block ordering.
{{:footer}}
  <button onclick={{action 'close'}}>Hmm...</button>
{{/my-dialog}}

[sclaxton]

@bendemboski I'll respond to your feedback by number:

1. The string arguments to the name yields were meant to just be an example of yielding block parameters. They are certainly not required.
2. Definitely! I honestly hadn't thought of extending hasBlock but it certainly makes sense and would be necessary to fully extend the current API. I'll add this to proposal when I get the chance!
3. Hmm this is an interesting point. I definitely agree in spirit. Ordering is important for readability. Not sure how I feel about the lone colon though, tbh haha. I'll think about syntax a little more and either add this as an open question or to the proposal proper.

[simonihmig]

I strongly support the need for this kind of functionality! It adds something that just using contextual components cannot give you, like the ability to specify where in the components template the blocks should be rendered to. Have been missing this very much...

A bit unsure about the syntax of it though. But maybe one just has to get accustomed to it a bit...

To underpin the need for it a little bit more:

• There are addons for the same purpose:
  • https://github.com/ciena-blueplanet/ember-block-slots
  • https://github.com/knownasilya/ember-named-yields
• Some recent discussion based on this tweet by @samselikoff: https://twitter.com/samselikoff/status/801526548079771648

[csantero]

👍 for this. My team has been using a combination of contextual components and the ember-block-slots addon to construct some of our more complex components. If this RFC is implemented, we'll be able to refactor those components to provide a much more intuitive and fool-proof developer experience.

Regarding the syntax, I think both : and @ work. The @ sign has the advantage of meaning "at", so {{@footer}} can be read as "The following content will be inserted AT the footer".

[machty]

Sorry to do this, but here's yet another yet another RFC that solves a similar problem: #199

[machty]

Superseded by the now-merged Named Blocks RFC.