-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slot Attributes #15
Slot Attributes #15
Conversation
Would sveltejs/svelte#2106 solve this? Something like
|
Being able to detect slot existence would, yes, but IIRC there was hesitation around this – I think due to implementation hurdles? Can't really remember the details |
I don't think there are implementation hurdles - this is already sort of available as |
Thanks, missed the part where So then here's what I have so far: https://svelte.dev/repl/69ca92e3995540a4a0a1865e6fc6b957?version=3.16.7 Then this RFC basically serves as a consolidation for the above while also adding ability to add additional props/attributes to each slot (sveltejs/svelte#2106 (comment)) In the process, we'd hopefully be able to remove the whitespace-only trigger for |
Sorry if I misread the RFC but there is stuff I'm sceptical about. What happens when a slot doesn't have a unique child? Will all top level children get assigned the attributes? Could we wrap the contents of the slot in a I wrote an RFC (Declarative Actions) where I mentioned adding a What happens when the attributes specified in the One solution could be to (I'm gonna use Something like:
Would only allow a single And something like:
Wouldn't compile right off the bat since a You could even do:
This would allow one of those Elements as the root element and Svelte would be smart enough to allow the interception of their attributes list. If you want to allow all don't include the As in:
And, again, Svelte would be smart enough too allow you to use the right attributes. You could even allow/deny specific Svelte Components (which could be useful for design systems) or only allow or only deny all Svelte Components: Ex 1:
This would deny any Svelte Component and would mean roughly the same as:
Ex 2:
This would only allow those 2 Svelte Components as children and, once more, Svelte could be able (this doesn't seem as black and white as HTMLElements since 2 Components having props with the same name doesn't mean they have the same semantics) to allow the props in common. I can see this being written off as too convoluted but I think it's a decent way to go about the problem. Other questions: How would directives, specifically style directives work? How would style properties work? How would actions work? How would Svelte scope styles since the slot's content would need access the class selectors in its parent, or any selector for that matter? |
Slot variables is now available in Svelte, which is more general a solution than this proposal. |
Snippets will replace slots (they are still around but deprecated) in Svelte 5 and have the capabilities that are wanted. The |
Rendered