v2.0.0 Beta - The <Suspense> is Over

[ryansolid]

I know you all probably weren't expecting this announcement next. But after reviewing the roadmap, we spent so long iterating in the Experimental phase, most of the goalposts within Alpha don't appear relevant enough to warrant their own phase. Instead, I'm happy to announce today that Solid 2.0 effort enters the beta stage. There will be bugs and rough edges we need to work through with the ecosystem. The focus will be on building documentation, and strategies for migration while we work through extending 2.0 into the wider ecosystem.

The Big Ideas

• Async is first‑class: computations can return Promises (or async iterables) and the graph knows how to suspend/resume work.
• <Loading> is for initial readiness: show a fallback while a subtree can’t produce UI yet — then keep the UI stable while background work happens.
• Pending UI is an expression, not a flag: isPending(() => expr) tells you when “refreshing…” work is in flight without tearing down the UI.
• Mutations have a home: action(...) + optimistic primitives (createOptimistic, createOptimisticStore) let you write “optimistic → await → refresh” as one coherent flow.
• Derived state is a primitive: function forms like createSignal(fn) and createStore(fn) make derived-but-writable patterns explicit and composable.
• A more predictable scheduler: updates are microtask‑batched, and reads don’t update until the batch flushes (use flush() only when you truly need “settle now”).
• Dev guardrails: dev warnings catch accidental “top-level reads” in components and writes in reactive scopes before they become async bugs.
• DOM model cleanup: use: directives are replaced by ref directive factories (with array composition), and classList is folded into class.

Tiny Examples

Stable async UI: <Loading> for first render, isPending for revalidation

const users = createMemo(() => api.listUsers());
const refreshing = () => isPending(() => users());

<>
  <Show when={refreshing()}>{/* subtle "refreshing…" UI */}</Show>
  <Loading fallback={<Spinner />}>
    <UserList users={users()} />
  </Loading>
</>

Mutations that read clearly: action + optimistic store + refresh

const [todos, setOptimisticTodos] = createOptimisticStore(() => api.getTodos(), []);

const addTodo = action(function* (todo) {
  setOptimisticTodos(todos => {
    todos.push(todo)
  }); // optimistic UI
  yield api.addTodo(todo);                   // server write
  refresh(todos);                            // recompute derived reads
});

Batching that’s deterministic: reads update after flush()

const [count, setCount] = createSignal(0);
setCount(1);
count(); // still 0
flush();
count(); // now 1

Breaking changes you’ll notice quickly

• List rendering: Index is replaced by <For keyed={false}>, and For children receive accessors (item() / i()).
• Effects & lifecycle: createEffect is split (compute → apply), and onMount is replaced by onSettled (which can return cleanup).
• Stores: setters are draft-first by default; storePath(...) exists as an opt-in helper if you want the old path-style ergonomics.
• DOM: use: directives are removed; use ref directive factories (and arrays) instead.

Try the beta

Start with the migration guide:

• Beta tester guide: documentation/solid-2.0/MIGRATION.md

Then dive into specific topics when you need details:

• Reactivity & effects: documentation/solid-2.0/01-reactivity-batching-effects.md
• Ownership & context: documentation/solid-2.0/02-signals-derived-ownership.md
• Control flow: documentation/solid-2.0/03-control-flow.md
• Stores: documentation/solid-2.0/04-stores.md
• Async data: documentation/solid-2.0/05-async-data.md
• Actions & optimistic: documentation/solid-2.0/06-actions-optimistic.md
• DOM: documentation/solid-2.0/07-dom.md

Conclusion

Today we have an overview of what has changed and 7 RFCs to describe each area in more detail. Noticeably absent are features marked as experimental in 1.0 like enableExternalSource and SuspenseList. These will be fleshed out during the beta phase but does not block us on core mechanics. Similarly the 2.0 is missing dev hooks to enable dev tools at this point because the signals implementation has been rewritten from the ground up.

We have also updated Vite Plugin Solid which will find on npm under the next tag. Over the next several days I expect to see more 1st party updates following a similar patterns. This has been a long time coming but I couldn't be more excited to finally put in your hands what we've been working on for the last couple years.

Best Regards,
@ryansolid

---

This discussion was created from the release v2.0.0 Beta - The is Over.

[doeixd]

Congrats! 🎉

[sanguogege]

what a lovely day,You finally decided to test the version.

[donnysim]

Am I missing something or I cannot install the web @solid-js/web package? It says there's only @solidjs/web@2.0.0-experimental.0 available which is incompatible with solid-js@2.0.0-beta.0

[donnysim]

Nevermind, worked after explicitly specifying npm i @solidjs/web@2.0.0-beta.0

[guillaumebrunerie]

Congrats!
I'm wondering what happened to the project to separate the UI code and the reactive core, which I think was planned for Solid 2.0 but doesn't seem to be mentioned here. Did it happen? Or is it still planned for the future?

[lkwr]

Looks like the separation has happened. There is now a dedicated @solidjs/signals package used by solid-js.

[guillaumebrunerie]

Looks like the separation has happened. There is now a dedicated @solidjs/signals package used by solid-js.

Is it being used by solid-js? I have seen @solidjs/signals, but it also says that it's "pre-alpha" and "completely experimental", and has very few stars and issues and so on.

[guillaumebrunerie]

I'm actually mostly interested in using @solidjs/signals (or similar) outside of Solid, hence my question.

[lkwr]

You can see a bunch of exports from @solidjs/signals in solid-js here:

solid/packages/solid/src/index.ts

Lines 1 to 58 in ed3d5af

	export {
	$PROXY,
	$TRACK,
	action,
	createOwner,
	createReaction,
	createRoot,
	createTrackedEffect,
	deep,
	flatten,
	flush,
	getNextChildId,
	getObserver,
	getOwner,
	isEqual,
	isRefreshing,
	isPending,
	isWrappable,
	mapArray,
	merge,
	omit,
	onCleanup,
	onSettled,
	latest,
	reconcile,
	refresh,
	repeat,
	resolve,
	NotReadyError,
	runWithOwner,
	snapshot,
	storePath,
	untrack
	} from "@solidjs/signals";
	export type {
	Accessor,
	ComputeFunction,
	EffectFunction,
	EffectOptions,
	Merge,
	NoInfer,
	NotWrappable,
	Omit,
	Owner,
	Signal,
	SignalOptions,
	Setter,
	Store,
	SolidStore,
	StoreNode,
	StoreSetter,
	StorePathRange,
	ArrayFilterFn,
	CustomPartial,
	Part,
	PathSetter
	} from "@solidjs/signals";

I guess the README of @solidjs/signals will be updated in the future.

[DmitryOlkhovoi]

Can you get rid of this stupid React-like syntax where you need two variables for one reactive value?
const [count, setCount] = createSignal(0);
I don't understand why you need this.

[ryansolid]

https://dev.to/playfulprogramming/thinking-locally-with-signals-3b7h

[doeixd]

Try using something like this. However, after a while I think you'll start to see the advantages of the segregated approach! Solid is powerful enough for you to create your own primitives, if you prefer!

import { createSignal } from 'solid-js'

type Atom<T> = {
  (): T
  (value: T): T
  (updater: (prev: T) => T): T
}

export function createAtom<T>(initial: T): Atom<T> {
  const [get, set] = createSignal<T>(initial)

  function atom(): T
  function atom(value: T): T
  function atom(updater: (prev: T) => T): T
  function atom(valueOrUpdater?: T | ((prev: T) => T)): T {
    if (arguments.length === 0) {
      return get()
    }

    set(valueOrUpdater as T | ((prev: T) => T))
    return get()
  }

  return atom as Atom<T>
}

or

import { createSignal } from 'solid-js'
import type { Setter, Accessor } from 'solid-js'

export interface Atom<T> {
  get: Accessor<T>
  set: Setter<T>
}

export function createAtom<T>(initial: T): Atom<T> {
  const [get, set] = createSignal<T>(initial)
  return { get, set }
}

[DmitryOlkhovoi]

@doeixd Thanks, will try