-
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
Targeted Slots - passing and mixing attributes and styles to component, access the slotted element from inside the component #68
Conversation
To me this feels like the culmination of the discussion about this topic. I think the use of I think this supercedes my RFC in every way. I won't close it for a while since there might be some more discussion over there that's doesn't fit in this RFC. I digress... Giving my 2 cents on some of the unanswered questions:
I don't think it should. It would make slots more cumbersome to work with. You don't know what your getting. It stops being consistent.
I can't come up with a use case either. I feel like unless we can find a use case, it's hard to think about advantages and drawbacks, so we shouldn't add it, just because it is added complexity.
Is this a problem? Targeted slots are a superset of slots anyway. They can use it as a simple slot. It's literally a "1 child slot". |
`svelte:selector` attribute for `<svelte:element slot="name"/>` and `<svelte:fragment slot="name"/>`. Usage `<svelte:fragment slot="name"/>`.
Very interesting proposal here. A couple pushbacks:
|
|
That does help, thanks for pointing that out.
In my original use case, I was thinking about how much more naturally something like a material-design button is composable functionality, not a reusable component. So, with Declarative Actions-like syntax (in a contrived example), the consumer markup would look something like this: <script>
import { matRaisedButton, matOutlinedButton } from 'some-lib';
</script>
<div class="actions">
<button use:matOutlinedButton class="custom-class">Cancel</button>
<a href="#" use:matRaisedButton class="custom-class">Save</a>
</div> Whereas targeted actions (as I understand it) would be something like: <script>
import { MatRaisedButton, MatOutlinedButton } from 'some-lib';
</script>
<div class="actions">
<MatOutlinedButton><svelte:element slot="button" class="custom-class" />Cancel</MatOutlinedButton>
<MatRaisedButton><svelte:element slot="button" this="a" href="#" class="custom-class" />Save</MatRaisedButton>
</div> So, yes, more keystrokes, but that's not actually what I don't like. In the first example, it's transparently obvious what the markup will be. The second is a lot more cognitive load. |
Minor additions - `<svelte:target>`. Minor additions - style order method. Formatting fix in one place.
@mimbrown The problem To make it simpler in Targeted Slots, you could still allow the use of any element, not just Then the example with <MatRaisedButton><a slot="link" href="#" class="custom-class">Save</a></MatRaisedButton> And as for the amount of code in Parent - It's because of the universality of Targeted Slots - that you can use more than one slot. You can think about the syntax (exception) - a shortcut: <svelte:element slot={MatOutlinedButton} class="custom-class">Cancel</svelte:element> This would be a literal shortcut, you could handle it with a preprocessor that simply converts this code, to the target code: <MatOutlinedButton><svelte:element slot="default" class="custom-class">Cancel</svelte:element></MatOutlinedButton> That this preprocessor would have to name Note1: This syntax would be very similar to You could also build such an exception into the normal behavior of Targeted Slots, but that complicates the proposal. The syntax
This is something I didn't describe in "Rejected at this time," because it has too many ambiguities and complicates the proposal. I only wrote about "cross-mix attributes (between Component and element)", which I reject at this point. Using any element <a slot={MatRaisedButton} href="#" class="custom-class">Save</a> ...is nice, but I don't know if technically possible and some problems need to be solved. It may be possible, but I'm waiting for some SvelteJS member to say something. |
My thoughts are clarifying on this. At first I thought the difference here was just a difference in mental model, but that's not true. This proposal is about a svelte component that provides targeted access to its elements. This is a very worthy goal. I see some really good applications, for example solving the long-standing problem that reusable form elements generally have the underlying But the Declarative Actions proposal is about defining a reusable action (or composable) that the consumer can use however they wish, including by "composing" multiple actions with an element that they create. That means the consumer can do this: <script>
import dropTarget from './dropTarget.svelte';
import matRaisedButton from './matRaisedButton.svelte';
</script>
<button use:matRaisedButton use:dropTarget class="custom-class">Click or drop</button> Unless I'm very much mistaken, this is functionality that targeted slots can't do. I'm trying to say I don't think targeted slots is a superset solution to declarative actions, they're different proposals. |
@mimbrown Inside Child you can refer to the button element, using <!-- Child.svelte -->
<script>
let target
</script>
<svelte:element targeted:name bind:this={target}/> In this code, But the equivalent of many Nothing prevents you from using I don't know if it will work for me, but I will try to think of something. |
@lukaszpolowczyk I don't think it should be included, because I think it's a separate issue. Declarative Actions is a proposal for allowing declarative, composable pieces of functionality to be defined. Targeted slots is a proposal for giving consumers insight and "targetability" into a custom svelte component. Two separate possible solutions to two different problems. |
@mimbrown But my inspiration was Declarative Actions, among other things. I see no reason to separate it. At this point I have no idea, so there is nothing to talk about. If something comes to mind, I will just describe it. |
@Zizico2 Do you have any desire to weigh in on this? |
@mimbrown @Zizico2 I have a simple idea for a replacement for a lot of <!-- Parent.svelte -->
<svelte:component bind:these={[ Child1, Child2 ]}>
<svelte:element slot="name"/>
</svelte:component> The The issue that this requires the same slot name is rather a problem, you would need to be able to set the slot name under each What do you guys think? I am not adding this to the description of this rfc for now. EDIT: Eventually, this should only work if there are unnamed slots inside Child1 and Child2. Then there is no problem. |
Snippets will replace slots (they are still around but deprecated) in Svelte 5 and will have a lot more flexibility with regarding to passing things around. Therefore closing this RFC - thank you. |
Rendered.
People who might like it (and my inspirations):
@Tropix126 @Zizico2 @ghughes