SolidJS 2.0 Beta: Async, Suspense, Batching Revolution

SolidJS 2.0: A Reactive Leap Forward

The SolidJS 2.0 Beta release marks a pivotal moment for the framework, primarily driven by its ambitious overhaul of asynchronous operations and state management. The introduction of first-class async support, where computations can directly return Promises and the reactive graph intelligently handles suspension and resumption, promises to significantly simplify complex asynchronous workflows. This eliminates much of the boilerplate and manual orchestration previously required, directly addressing a common pain point in modern web development. The reworked Suspense mechanism, focusing on initial readiness and stable UI during updates, along with dedicated primitives for mutations like action() and createOptimisticStore, further enhances the developer experience by providing more coherent patterns for data fetching and state manipulation. The deterministic batching of updates, where reads only occur after a flush() call, aims to resolve subtle race conditions and provide a more predictable execution model, a critical aspect for robust applications. The author's defense of these changes, emphasizing their necessity for consistent async behavior and a more concise design, highlights the deliberate architectural decisions made to elevate SolidJS's capabilities. Developers seeking a highly performant, fine-grained reactive framework will find these advancements compelling, particularly those who have struggled with managing async states in other frameworks.

However, the transition to SolidJS 2.0 is not without its challenges, as evidenced by the community feedback. The shift from the single-function createEffect to a split-phase API, and the delayed updates after flush(), have raised concerns about expressiveness and potential inconsistencies. The argument that automatic dependency tracking in createEffect is more intuitive and covers more use cases resonates with developers accustomed to similar patterns in Vue.js and Svelte. The worry about inconsistent state reads due to values updating after flush() could indeed break the intuitive mental model of Solid 1.x, forcing developers to adopt a different approach to reactive data. While Ryan Carniato's explanation points to these as necessary trade-offs for consistent async, the practical implications for developer workflows and learning curves need careful consideration. The removal of the use: directive system in favor of ref directive factories also represents a breaking change that will require migration effort. For existing SolidJS developers, the migration guide will be crucial, and for newcomers, understanding these new paradigms will be paramount. The success of this beta hinges on how well the community adapts to these fundamental changes and whether the promised benefits of a more coherent and performant async model outweigh the initial friction.

Key Points

• SolidJS 2.0 Beta introduces first-class async handling, allowing computations to return Promises and automatically managing suspension/resumption.
• Suspense has been redesigned for initial readiness, maintaining UI stability during subsequent updates.
• New primitives like action() and createOptimisticStore streamline optimistic updates, server writes, and data revalidation.
• Derived state is now a first-class primitive with functions like createSignal(fn) and createStore(fn).
• Updates are microtask-batched with deterministic scheduling, ensuring reads only occur after a flush() call.
• Breaking changes include replacing Index with <For keyed={false}>, splitting createEffect, replacing onMount with onSettled, and removing the use: directive system.
• Community feedback highlights positivity towards async improvements but raises concerns about the complexity and potential inconsistency of the new createEffect and delayed update model.

---

📖 Source: SolidJS 2.0 Beta: First-Class Async, Reworked Suspense and Deterministic Batching