Figured I might as well explain why these Solid v2 features are exciting
Fine grained async
Currently when something reads from an async signal, everything being rendered under Suspense is thrown away, fallback is shown, after the async fetch finishes, everything under Suspense is rendered again. Solid v2 will ensure that only the nodes (effects) that depend on the async values will rerun, and nothing will ever need to rerun under Suspense.
Mutable derivations
Currently derived primitives (createMemo) are immutable, and deeply reactive primitives (createStore) cannot be used in a derived way. Solid v2 will introduce a new primitive that is derived and deeply reactive, combining the best of both worlds.
Split effects and Flush boundaries
Currently Solid has no way to know what a render effect depends on without running it, and no way to prevent side-effects once the render effect starts running. Split effects in Solid v2 let effects define pure reactive logic and effectful logic separately, and flush boundaries allow effects in a tree to compute all reactive logic without committing any side effects.
The underlying capability that enables Suspense, Offscreen, and other features that defer rendering part of the UI to a later time.
Derived signals
Currently a signal can only be derived (createMemo) or only be settable (createSignal). Creating a signal that's both settable and derived (e.g. optimistic state) requires breaking the dependency graph. Solid v2 allows createSignal to be both settable and derived to allow use cases like optimistic state a first-class citizen.
Lazy memos
Currently, `createMemo` computations are run immediately on creation and update. Solid v2 changes memos to run only when read. This improves efficiency by only evaluating what is needed, enables global store patterns that declare derived state upfront, and lets nodes automatically garbage collect when not being used.
Global batching
Currently when a value is set into a signal, Solid immediately updates the dependency graph and executes side effects before returning to the caller. While updates can be batched manually, Solid v2 makes batching the default and provides a way to manually force an update and render using the current state. This improves efficiency in certain cases where manual batching was not applied, makes for overall better developer ergonomics.
Concurrent transitions (mostly theoretical)
Currently only one global transition can be created, any newly created transition simply gets rolled into the existing one. Solid v2 is looking at enabling multiple independent transitions that only get merged if their update graph overlaps.
I’m way too excited for the coming updates to
@solid_js in 2025
- Fine grained async
- Mutable derivations
- Flush boundaries
- Derived signals
- Lazy memos
- Global batching
- Concurrent transitions? Maybe?