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
Any snippet declared under a component is automatically passed as a prop. This is great when this is what you want, but that's not always the case. There are 2 main issues with this:
When the tree is mostly components, you are forced to put all helper snippets at the root level, which is not ideal (no sorting, scoping breaks, becomes cluttered)
It is difficult & a bit boilerplate-y (also the same issue as above) to pass a snippet conditionally
Now, suppose you want to extract the common list item to a snippet. Ideally, you'd place this snippet right above itemEven and itemOdd, but this is not possible, as it will become a prop. Since this tree is all components, you have no other choice than to place it at the root level:
The more complex the component, the more root-level snippets you'll need, which becomes hard to keep track of. Additionally, snippet scoping, a great feature, breaks: a snippet only meant for use in AlternateList now pollutes the entire file and can potentially be missused.
This feels a bit boilerplate-y when done multiple times, and not very idiomatic (if snippet is passed as prop, why is it not right under the receiving component?). It also breaks the scoping of the code, just like in the earlier example; content that exclusively belongs to the AppBar is now globally present.
Describe the proposed solution
Provide a way control how snippets automatically become props. This should not restrict the scope of the snippet, and fix issues (1) and (2) above. At first sight I feel like borrowing the syntax for keyed each is a decent starting point:
<AppBar>
{#snippethelper() (false)}
this is not passed as a prop
{/snippet}
{#snippettoolbar()}
<!-- but can be used here -->
{@renderhelper()}
{/snippet}
{#snippetheadline() (condition)}
<!-- the {#if headline}...{/if} in the AppBar correctly applies depending on condition -->
...content...
{/snippet}
</AppBar>
...but of course, the actual syntax/approach here should be decided by the core maintainers.
Importance
would make my life easier
The text was updated successfully, but these errors were encountered:
Examples 1 and 2 might be contrived but using snippets for styling purpose is usually overkill, here :nth-child(odd) and :nth-child(even) are more suited for this job.
Example 2 can't you have commonItem declared in AlternateList ?
Example 3 as per the docs snippets turned into props is an authoring convenience, when it stops to be convenient you can just switch back to regular syntax : <AppBar display_headline={condition}> or {#if headline}{@render headline()}
Describe the problem
Any snippet declared under a component is automatically passed as a prop. This is great when this is what you want, but that's not always the case. There are 2 main issues with this:
As an example for (1), consider this tree:
Now, suppose you want to extract the common list item to a snippet. Ideally, you'd place this snippet right above
itemEven
anditemOdd
, but this is not possible, as it will become a prop. Since this tree is all components, you have no other choice than to place it at the root level:The more complex the component, the more root-level snippets you'll need, which becomes hard to keep track of. Additionally, snippet scoping, a great feature, breaks: a snippet only meant for use in AlternateList now pollutes the entire file and can potentially be missused.
For (2), consider this:
If you want to conditionally display the headline, this is the solution:
This feels a bit boilerplate-y when done multiple times, and not very idiomatic (if snippet is passed as prop, why is it not right under the receiving component?). It also breaks the scoping of the code, just like in the earlier example; content that exclusively belongs to the AppBar is now globally present.
Describe the proposed solution
Provide a way control how snippets automatically become props. This should not restrict the scope of the snippet, and fix issues (1) and (2) above. At first sight I feel like borrowing the syntax for keyed each is a decent starting point:
...but of course, the actual syntax/approach here should be decided by the core maintainers.
Importance
would make my life easier
The text was updated successfully, but these errors were encountered: