You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The lack of this capability is a HUGE growing pain for the projects I'm working on and causes a lot of cruft and awkward APIs, and having this feature would simplify a ton of things.
For library / ui / design-system authors, having passable blocks would be an IMMENSE lift / relief -- and it feels very surprising that this wasn't talked about more during the original RFC (or maybe it was planned to be added later, and just no one has gotten around to it)
Related thoughts:
maybe there is a way to:
reference anything
pass anything
<SubComponent @myBlock={{:myBlock}}>
<:@myBlock>
</:@myBlock>
Example:
the first place this came up was our big table component wrapped with all the bells and whistles.
Here is a more generic, yet very related, example.
A table component
could yield to="header"
and yield to="body"
etc
A wrapper component cannot
optionally yield to="header" and also have that header block be within the table component's header block (and the same for any block).
Like,
<WrappedTable>
<:header>
<th></th>
</:header>
</WrappedTable>
and
<WrappedTable />
are not possible APIs.
You can hack around this, by, in the implementation of WrappedTable, put an if block around the entirety of Table, but that's 1. terrible, and 2. does not scale past 1 named block.
I have 7 named blocks in Table component
In order to provide a wrapper table (with nice defaults, optional blocks, etc), I cannot fathom (other than actually doing the math) the amount of code it would take to if-stamement my way through implementing that.
The text was updated successfully, but these errors were encountered:
NullVoxPopuli
changed the title
Reminder to myself to write an RFC for passing named blocks as arguments
Syntax/Feature Need: Passable Blocks (as args / other?)
Jun 17, 2022
with the exception that if a value passed to @: is falsey, the named block matching the identifier after the : is not present.
Alternatively (or maybe in addition to, because this is about to be way more typing than the above,
we could allow control-flow syntaxes outisde named-block space.
For example:
{{! the contents of "MyDemo" component }}
<ListItem @list={{@list}}>
{{#if (has-block"media")}}
<:media>
{{yieldto="media"}}
</:media>
{{/if}}
</ListItem>
e.g.: if <MyDemo> is rendered with a <:media> block, pass those contents to <ListItem>, otherwise render <ListItem> as if no :media block were used.
context: #460 (comment)
The lack of this capability is a HUGE growing pain for the projects I'm working on and causes a lot of cruft and awkward APIs, and having this feature would simplify a ton of things.
For library / ui / design-system authors, having passable blocks would be an IMMENSE lift / relief -- and it feels very surprising that this wasn't talked about more during the original RFC (or maybe it was planned to be added later, and just no one has gotten around to it)
Related thoughts:
Example:
the first place this came up was our big table component wrapped with all the bells and whistles.
Here is a more generic, yet very related, example.
A table component
A wrapper component cannot
Like,
are not possible APIs.
You can hack around this, by, in the implementation of
WrappedTable
, put anif
block around the entirety ofTable
, but that's 1. terrible, and 2. does not scale past 1 named block.I have 7 named blocks in Table component
In order to provide a wrapper table (with nice defaults, optional blocks, etc), I cannot fathom (other than actually doing the math) the amount of code it would take to if-stamement my way through implementing that.
The text was updated successfully, but these errors were encountered: