|
1 | | -Solutions for Rune-Based Reactive State Sharing |
| 1 | +# ([Solutions for Rune-Based Reactive State Sharing |
2 | 2 |
|
3 | | -Solution 1: Reactive Context Injection |
| 3 | +The fundamental problem is that Svelte 5 runes create reactive references that lose their reactivity when serialized across compilation boundaries. |
4 | 4 |
|
5 | | -Modify the factory function to accept reactive context objects that get injected into the |
6 | | -component's compilation scope. Instead of passing static values, pass rune references directly |
7 | | -through the compilation process. |
| 5 | +## The Core Issue |
8 | 6 |
|
9 | | -Approach: |
10 | | -- Extend ComponentCompiler.render() to accept a reactiveContext parameter containing rune |
11 | | -objects |
12 | | -- Modify transformCompiledCode() to inject these runes as imports/globals in the compiled |
13 | | -component |
14 | | -- The dynamic component accesses parent runes directly via injected context |
| 7 | +When we have `let count = $state(123)` in our parent component, we're creating a reactive reference. |
15 | 8 |
|
16 | | -Solution 2: Rune Reference Passing |
| 9 | +However, when we try to pass this to a dynamically compiled component, several things break the reactivity chain: |
| 10 | + |
| 11 | +### 1. **Value** vs **Reference** Passing |
| 12 | + |
| 13 | +Parent component: |
| 14 | + |
| 15 | +```ts |
| 16 | +let count = $state(123); |
| 17 | +``` |
| 18 | + |
| 19 | +What you're actually passing to the dynamic component: |
| 20 | + |
| 21 | +```ts |
| 22 | +const props = { count }; // This passes the VALUE (123), not the reactive reference |
| 23 | +``` |
| 24 | + |
| 25 | +The `$state(123)` creates a reactive proxy/reference, but when you put count in the props object, you're passing the current value (`123`), not the reactive reference itself. |
| 26 | + |
| 27 | +### 2. Compilation Boundary Isolation |
| 28 | + |
| 29 | +Parent component (compiled at build time): |
| 30 | + |
| 31 | +```ts |
| 32 | +let count = $state(123); |
| 33 | +``` |
| 34 | + |
| 35 | +Dynamic component (compiled at runtime): |
| 36 | + |
| 37 | +```ts |
| 38 | +let { count } = $props(); // This creates a NEW local variable, disconnected from parent |
| 39 | +``` |
| 40 | + |
| 41 | +Each Svelte compilation creates its own reactive scope. The dynamically compiled component has no knowledge of the parent's reactive system - **it's essentially a _separate_ "universe" of reactivity**. |
| 42 | + |
| 43 | +### 3. Svelte's Internal Reactivity System |
| 44 | + |
| 45 | +Svelte 5 runes work through: |
| 46 | + |
| 47 | ++ Reactive proxies that track dependencies. |
| 48 | ++ Effect scheduling that runs when dependencies change. |
| 49 | ++ Component boundaries that isolate reactive scopes |
| 50 | + |
| 51 | +When you pass count as a prop, the dynamic component receives a **snapshot** _value_, **not** a reactive subscription. |
| 52 | + |
| 53 | +### 4. The Mount/Unmount API Limitation |
| 54 | + |
| 55 | +```ts |
| 56 | +const component = mount(DynamicComponent, { target, props: { count: 123 } }); |
| 57 | +``` |
| 58 | + |
| 59 | +Svelte's `mount()` API expects static props at mount time. It doesn't have a built-in mechanism to pass ongoing reactive references that update the component after mounting. |
| 60 | + |
| 61 | +### Why The Original Approach Didn't Work |
| 62 | + |
| 63 | +Parent component: |
| 64 | + |
| 65 | +```ts |
| 66 | +let count = $state(123); |
| 67 | +``` |
| 68 | + |
| 69 | +Dynamic component template: |
| 70 | + |
| 71 | +```ts |
| 72 | +let { count = $bindable(0) } = $props(); |
| 73 | +``` |
| 74 | + |
| 75 | +This creates two separate reactive variables with the same name but no connection between them. |
| 76 | + |
| 77 | +The `$bindable()` in the dynamic component creates its own reactive reference, completely isolated from the parent's `$state()`. |
| 78 | + |
| 79 | +### The Real Solution Would Require |
| 80 | + |
| 81 | +1) Passing reactive references (not values) across compilation boundaries. |
| 82 | +2) Shared reactive context that both components can access. |
| 83 | +3) Live prop updates after component mounting. |
| 84 | +4) Cross-compilation reactive dependency tracking. |
| 85 | + |
| 86 | +This is why the `SharedRuneStore` solution works (see [/src/shared-rune-store.ts](../src/shared-rune-store.ts)) - it creates a shared reactive context that both the parent and dynamic components can subscribe to, bypassing the compilation boundary limitations. |
| 87 | + |
| 88 | +## Potential Solutions |
| 89 | + |
| 90 | +### Solution 1: Reactive Context Injection |
| 91 | + |
| 92 | +Modify the factory function to accept reactive context objects that get injected into the component's compilation scope. |
| 93 | + |
| 94 | +Instead of passing static values, pass rune references directly through the compilation process. |
| 95 | + |
| 96 | +**Approach**: |
| 97 | + |
| 98 | ++ Extend `ComponentCompiler.render()` to accept a reactiveContext parameter containing rune objects. |
| 99 | ++ Modify transformCompiledCode() to inject these runes as imports/globals in the compiled component. |
| 100 | ++ The dynamic component accesses parent runes directly via injected context. |
| 101 | + |
| 102 | +### Solution 2: Rune Reference Passing |
17 | 103 |
|
18 | 104 | Create a mechanism to pass actual rune references (not their values) through the mount system by |
19 | | - serializing rune getters/setters and reconstructing them in the dynamic component. |
20 | 105 |
|
21 | | -Approach: |
22 | | -- Extend the factory function to accept rune descriptors ({ get: () => value, set: (v) => {...} |
23 | | -}) |
24 | | -- Transform the compiled code to wire these descriptors to local rune state |
25 | | -- Dynamic components get direct access to parent runes through the descriptor interface |
| 106 | +serializing rune getters/setters and reconstructing them in the dynamic component. |
| 107 | + |
| 108 | +**Approach**: |
| 109 | + |
| 110 | ++ Extend the factory function to accept rune descriptors `({ get: () => value, set: (v) => {...} })`. |
| 111 | ++ Transform the compiled code to wire these descriptors to local rune state. |
| 112 | ++ Dynamic components get direct access to parent runes through the descriptor interface. |
| 113 | + |
| 114 | +### Solution 3: Shared Rune Store |
| 115 | + |
| 116 | +Implement a global rune store that both parent and dynamic components can subscribe to, using Svelte 5's $state() with a singleton pattern. |
26 | 117 |
|
27 | | -Solution 3: Shared Rune Store |
| 118 | +**Approach**: |
28 | 119 |
|
29 | | -Implement a global rune store that both parent and dynamic components can subscribe to, using |
30 | | -Svelte 5's $state() with a singleton pattern. |
| 120 | ++ Create a `SharedRuneStore` class with `$state()` values. |
| 121 | ++ Parent components register their runes in the store. |
| 122 | ++ Dynamic components access the same rune references from the store. |
| 123 | ++ No wrapper/proxy - direct rune access through shared state container. |
31 | 124 |
|
32 | | -Approach: |
33 | | -- Create a SharedRuneStore class with $state() values |
34 | | -- Parent components register their runes in the store |
35 | | -- Dynamic components access the same rune references from the store |
36 | | -- No wrapper/proxy - direct rune access through shared state container |
| 125 | +### Solution 4: Compilation-Time Rune Binding |
37 | 126 |
|
38 | | -Solution 4: Compilation-Time Rune Binding |
| 127 | +Modify the source transformation to replace rune references in the dynamic component with bindings to externally provided rune objects. |
39 | 128 |
|
40 | | -Modify the source transformation to replace rune references in the dynamic component with |
41 | | -bindings to externally provided rune objects. |
| 129 | +**Approach**: |
42 | 130 |
|
43 | | -Approach: |
44 | | -- Parse the dynamic component source for rune usage patterns |
45 | | -- Replace let { count = $bindable(0) } = $props() with direct external rune bindings |
46 | | -- Inject the actual parent runes as module-level imports during compilation |
47 | | -- Component uses parent runes as if they were its own |
| 131 | ++ Parse the dynamic component source for rune usage patterns. |
| 132 | ++ Replace `let { count = $bindable(0) } = $props()` with direct external rune bindings. |
| 133 | ++ Inject the actual parent runes as module-level imports during compilation. |
| 134 | ++ Component uses parent runes as if they were its own. |
0 commit comments