|
|
|
|
|
by onsclom
995 days ago
|
|
Most of this I really love. One thing seems a bit strange though... Let's compare Svelte's and Solid's approach to nested reactivity. Both of them implement the same nested reactivity todo example: Svelte: https://svelte-5-preview.vercel.app/docs/fine-grained-reacti... Solid: https://www.solidjs.com/tutorial/stores_nested_reactivity?so... In Solid, converting something to use nested reactivity is one step. In Svelte, it is two steps. And that second step is really verbose and annoying: todos = [...todos, {
get done() { return done },
set done(value) { done = value },
get text() { return text },
set text(value) { text = value }
}];
Solid makes read and write segregation very simple and obvious. You don't need to manually make all these getters and setters.It is nice that runes allows nested reactivity in Svelte, but it feels nicer to use in Solid. |
|
function createSignal(initial) { let value = $state(initial); return [() => value, (v) => value = $state(v)]; }
Note that the Solid change is _not_ 'one step' — the `completed` property is being turned from a property to a function, which means you must update all the usage sites as well. Using getters and setters also allows you to use Svelte's convenient `bind:value` approach, which is much less verbose than using the equivalent event handler code. And don't get me started on the [type narrowing issues](https://www.typescriptlang.org/play?#code/C4TwDgpgBA4hzAgJwD...).
There's nothing _wrong_ with the Solid approach, but the ergonomics aren't to our liking. If we need to take a hit in terms of verbosity, we'd rather do it once at the declaration site than n times at every usage site.