chore: more slot/snippet interop #11619
Conversation
…should be booleans)
|
|
@dummdidumm what's the story with this PR, is it still something we want to pursue, or should we close it? |
|
I'm still in favor of landing this because I think it could make it easier to migrate one side of the component but not the other, but IIRC you (maybe others as well?) were against it, which is why it has gone stale. I also would need to investigate what this means for language tools if we would agree to continue. |
|
Given the discussion in #13406 and the fact that people may end up in temporary mismatches (slots on one side, snippets on the other) a lot during migration I'm in favor of landing this. |
This allows people to use snippets to fill slots. It is implemented in the same way the default slot interop is already implemented, by passing a boolean to the hidden `$$slots` object, and using that at runtime to determine the correct outcome. The impact on bundle size is neglible. By enabling this, we can enhance our migration script to always transform slot usages (including `let:x` etc) to snippets. This wasn't possible before because we couldn't be sure if the other side was transformed to using render tags at the same time. This will be part of #13419. This is important because currently the migration script is transforming `<slot />` creations inside components, but since it's not touching its usage points the migration will make your app end up in a broken state which you have to finish by hand. This is a reduced alternative to, and closes #11619, which was also enabling the other way around, but that is a) not as necessary and b) more likely to confuse people / break, because it only works if your render function has 0-1 arguments.
This builds on top of #10800 and explores what it takes to make slots and snippets interoperable. It allows you to use render tags already when your consumers still pass slots, or pass snippets already when the component you pass it to still uses slots. From my guess the latter is likely more common (you're depending on some third party library which hasn't updated yet).
Implementation-wise it passes
{ $$slots: { foo: true } }for a snippet prop namedfoo, and the render functions for snippets/slots were adjusted to check both locations for content, and react accordingly.The drawback is that it's a bit more runtime code, and it's somewhat brittle, because it will only work for render tags with 0 or 1 argument (
<slot {foo} {bar} />===@render children({foo, bar})) which could be a bit confusing. It's very nice that it "just works" in the common case though.Putting this up for completeness even if it's unlikely that we land this.
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint