Generic Component binding feature parity

[dangodai]

Hi, I have a problem that I've spent the past week thinking about/working on that I cannot find a solution for. I've asked a few parts of this piecemeal in the Discord, but haven't gotten responses or a complete solution.

The problem

I have built a component layout manager library that deals with generic components. A simplified example of how I am handling components is as follows:

interface ComponentContainer<T extends Component<any> = Component<any>> {
    component: T;
    props: ComponentProps<T>;
}

let components: ComponentContainer[] = $state([
    { component: Foo, props: { a: 1, b: 2, c: 3 }},
    { component: Bar, props: { a: 1, b: 2, c: 3 }},
    { component: Baz, props: { a: 1, b: 2, c: 3 }},
]);

And rendered as

{#each components as c}
    <c.component {...c.props} />
{/each}

The problem I'm running into is the inability to support two way binding. My library supports persisting layouts, which provides unexpected results when bindable props aren't propagated back to the root layout structure.

Approach 1 (Unsupported)

The ideal approach to solving this problem is unsupported: Supporting the bind: directive for prop spreads. I've seen this discussion goes back years without much movement so I'm not expecting it to be a viable solution.

On top of the lack of movement, the discussion I've seen also seems be lacking any way to selectively bind props - it's all or nothing. The proposals also seem to be mostly concerned with ergonomics, rather than enabling feature parity for generic components. Unlike with concrete components, this is no alternative to spreading with generic components.

Approach 2

The second approach is to bypass the svelte template syntax and use the imperative component API. The approach I've come it with for this is

1. Pull out the bindable properties from the Component<T> type

type ComponentBindables<Comp extends Component<any, any, any>> =
	Comp extends Component<any, any, infer Bindable> ? Bindable : never;

2. Accept an array of properties to bind

interface ComponentContainer<T extends Component<any> = Component<any>> {
	component: T;
	props: ComponentProps<T>;
+	bindings?: ComponentBindables<T>[];
}

3. Mimic the bind: behaviour by transforming each bound property into a { get; set; } pair.
4. Render/mount/hydrate the component with our { get; set; } pairs as needed.

I have tested, in the most basic case, that this approach can work. However I have some issues, some minor and some blockers:

• Minor: This is kind of a gross approach.
  • It really feels like I'm doing something wrong, but I can't see an alternative.
  • It feels brittle, with things like async svelte being able to break previously working code
• Minor-ish: The documentation for the imperative component API provides no explanation on how to use it. From what I have managed to figure out: mount is basically inferior to hydrate and doesn't really have a use. From that, render should be called on the server and inserted into the component anchor with {@html ...}. And then hydrate should be called on the client inside of the parent components onMount callback.
• Major: I can't figure out how to support async svelte
  • I know this is brand new and experimental so I don't exactly expect docs, but the docs make no mention of async
  • For render() it seems I can simply await it
    • Side note: I think the return type RenderOutput may be incorrect, and also is not exported
  • hydrate() I can't figure it out. When there is server rendered HTML inside of the anchor then hydrate will throw for async components.
  • I'm not really sure how to handle the fact that async svelte is experimental and consumers of my library may or may not have it turned on and be giving me async components
• Major: Mimicking the behaviour of bind:, despite being common from what I've gathered in other issues, is internal behaviour and not a publicly guaranteed contract that I would like to be depending on

---

Have a missed a better approach? Or is this something that svelte just doesn't really support at the moment? Any help is appreciated.

I'm happy to provide more information or playground reproductions if it helps in any way.

[dangodai]

2025-09-25.03-05-56.mp4

Just to provide an example of what I'm trying to do, here is a quick demo I made when I tried asking in the discord.

In the recording, I add 3 "Pokemon" components to my layout. I re-arrange the layout nodes and resize nodes. I also update the Pokemon that is selected in each component which updates a bindable prop (i.e. pokemonId). The layout and props are persisted to storage. When I refresh you will notice that the Pokemon IDs all reset because the props were not bound, while the rest of the layout persisted correctly.