Coder Legion - Recent posts tagged solidjs

SolidJS 2.0 for React Developers: A First Look

Sat, 18 Jul 2026 22:31:47 +0000

I've shipped React for the better part of a decade. Hooks, Suspense, Server Components, the whole tour. So when the SolidJS 2.0 beta showed up in my feed with the tagline "The <Suspense> is Over," I rolled my eyes a little and then clicked anyway.

I'm glad I did. Solid has been the framework React people admire from a distance for years, and 2.0 is the release that finally made me install it and poke at the reactivity model instead of just reading about it. This post is my honest first look: what's new, what a React developer will recognize, and where Solid quietly does something React can't.

What is SolidJS 2.0?

SolidJS is a UI library with React-like JSX and a completely different engine underneath. Instead of re-rendering components and diffing a virtual DOM, it uses fine-grained reactivity: your component runs once, and updates flow directly to the exact DOM nodes that depend on a piece of state.

The 2.0 line is currently in beta. The first public build, v2.0.0-beta.0, landed on March 3, 2026, and the team skipped the alpha phase entirely because the milestones planned for it stopped feeling worth their own release. You can try it today:

pnpm add solid-js@next

The headline of the whole release is async. Solid's reactive graph now understands promises natively, and a lot of the API changes fall out of that one decision.

Fine-grained reactivity, from a React brain

Here's the mental model shift, and it's the thing to internalize before anything else makes sense.

In React, state changes re-run your component function. React then builds a new virtual DOM tree and diffs it against the old one to figure out what actually changed. useMemo, useCallback, and dependency arrays exist to keep that re-render machine from doing too much work. The React Compiler automates a lot of that memoization now, but the underlying model is the same: the component re-runs and React diffs the result.

In Solid, the component body is setup code. It runs a single time. When you read a signal in your JSX, Solid records that specific dependency and wires it straight to the DOM. Change the signal later and only that text node or attribute updates. No component re-render, and no dependency array to keep honest.

function Counter() {
  const [count, setCount] = createSignal(0);

  // This whole function runs ONCE. Only the text node updates on click.
  return <button onClick={() => setCount(count() + 1)}>{count()}</button>;
}

The tell for a React dev: count is a function, not a value. You call count() to read it. That call is what subscribes the surrounding computation to changes. Once it clicks, the absence of a dependency array stops feeling like something is missing and starts feeling like a bug class that no longer exists.

Why async is the real story of SolidJS 2.0

This is where 2.0 earns its version bump. In Solid 1.x, async data meant createResource and wrapping things in <Suspense>. In 2.0, a derived computation can just return a promise, and the graph handles suspending and resuming for you.

// Solid 1.x
const [data] = createResource(userId, fetchUser);

// Solid 2.0: the promise flows through the reactive graph
const data = createMemo(() => fetchUser(userId()));

Suspense gets replaced by <Loading>, and the semantics are the part I actually care about. <Loading> is scoped to initial readiness. It shows a fallback while the subtree can't render anything yet, and then it stays out of your way. When userId() changes and the data refetches, the UI doesn't tear itself down and flash a spinner. It holds the old content until the new content is ready.

To show that a refresh is in flight, you reach for isPending, which reports on pending reactive work without unmounting anything:

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

<>
  <Show when={refreshing()}>
    <RefreshIndicator />
  </Show>
  <Loading fallback={<Spinner />}>
    <UserList users={users()} />
  </Loading>
</>;

React 19 gets you most of the way here: put the update in a transition with useTransition, and Suspense holds the old content on screen instead of flashing its fallback, with isPending reporting the refresh. The difference is that React makes you opt into that at each call site, while Solid bakes the distinction between "we have nothing to show yet" and "we're refreshing what's already on screen" into the primitives themselves. I take this apart properly in a follow-up deep dive on Solid 2.0's async data.

How do mutations work in SolidJS 2.0?

For a long time React had no blessed way to do writes, so you rolled your own or reached for a data library. React 19 changed that with Actions and the useOptimistic hook, so this is a spot where the two frameworks have converged. Solid 2.0's version is action for mutations, plus createOptimistic and createOptimisticStore for optimistic updates, with refresh to revalidate afterward.

const [messages, setMessages] = createOptimisticStore(() => chatServer.loadMessages(), []);

const sendMessage = action(function* (next) {
  setMessages((m) => {
    m.push(next); // optimistic: show it instantly
  });
  yield chatServer.sendMessage(next); // await the server
  refresh(messages); // reconcile with the source of truth
});

The generator function is doing real work here. Each yield is a point where the action awaits, and the reactive system tracks the optimistic state until the real value lands and reconciles. Solid has been circling this for a while: @solidjs/router already shipped createAsync and action for data loading and mutations. 2.0 takes that thinking and builds async and actions into the core reactive graph, so the patterns aren't router-specific anymore.

Deterministic batching, and a gotcha

One behavioral change will trip you up if you're not ready for it. Writes are batched on a microtask, and reads don't reflect a write until the batch flushes.

const [count, setCount] = createSignal(0);

setCount(1);
count(); // still 0: the update is queued on the microtask
flush(); // apply queued updates synchronously
count(); // now 1

flush() forces the queue to apply right away when you need to read the result immediately, like focusing an input after a state change. Coming from React's synchronous batching it takes a moment to adjust, but the model is predictable, and that matters once async is woven through everything.

The renames a React developer should know

Solid 2.0 is a major version, so it cleans house. Since this is beta, some of these identifiers could still shift before stable, but the direction is set, and the migration guide tracks where things stand today. The changes that matter most coming from React:

<Suspense> → <Loading>, with the initial-readiness semantics above. <SuspenseList> becomes <Reveal>.
createEffect is split into a compute phase (what to track) and an apply phase (what to run with the result). Instead of reading signals inside one callback, you pass the two separately:
```
// Solid 1.x
createEffect(() => apiCall(signalB()));

// Solid 2.0
createEffect(signalB, apiCall);
createEffect(
  () => [signalA(), signalB()],
  ([a, b]) => a && apiCall(b),
);
```
If you've ever shipped a bug because a value was in a useEffect body but missing from the dependency array, separating the two is a direct answer to that. And in practice you reach for createEffect far less than you did in 1.x, since async and derived state now cover a lot of what used to send you to an effect.
onMount → onSettled (the closest replacement rather than a straight rename), reflecting the async-aware lifecycle.
<Index> → <For keyed={false}>; in that non-keyed mode the row is passed as an accessor, matching the old <Index> stability model.
Store setters are draft-first by default. You mutate a draft instead of threading a path. This is 1.x's produce behavior promoted to the default, so you no longer wrap the callback, with a storePath helper as the opt-in escape hatch for the old path style:
```
// 2.0 default: mutate the draft
setStore((s) => {
  s.todos[id].done = true;
});
// Legacy path style, opt-in
setStore(storePath("todos", id, "done", true));
```
classList is folded into class, which now takes strings, arrays, and objects.
use: directives are removed in favor of ref directive factories.
Context is simpler. The context is directly usable as the provider, so Context.Provider is gone. A context created without a default is typed as its value instead of T | undefined, and useContext throws ContextNotFoundError when there's no provider above it; a context created with a default still returns that default:
```
const Theme = createContext(); // no default
// 2.0: the context is its own provider
<Theme value="dark">{/* ... */}</Theme>;
```

Signals are heading toward the standard

The word "signals" is everywhere now, and it's worth knowing why. There's a TC39 Signals proposal at Stage 1, with design input from the people behind Angular, Vue, Svelte, Preact, Qwik, MobX, and Solid, among others. Solid's creator Ryan Carniato has written about fine-grained reactivity for years (his evolution of signals in JavaScript piece is a good entry point), and Solid is one of the frameworks feeding into the proposal.

Worth being precise here, because it's easy to overstate: Solid 2.0 does not ship the TC39 API as its core. The proposal is synchronous, and Solid 2.0's whole thing is async reactivity, which goes further than what's currently on the table. Solid influences and tracks the standard rather than implementing it. But the fact that the primitive Solid has bet on for years is now a serious effort to fold it into the JavaScript language itself tells you the industry is drifting toward the model React chose not to adopt. It's the same trajectory TypeScript's Go rewrite just traced: a bet on a different model that looked niche until it wasn't. Svelte 5 already rebuilt its reactivity around signals with its runes API, and it's unlikely to be the last framework to make the jump.

Should you drop React? No. But watch this closely

I'm not migrating my day job to Solid this quarter, and I don't think you should either. It's a beta, the ecosystem is smaller than React's, and API names are still moving. That's the honest read.

But 2.0 is the most interesting frontend release I've looked at in a while, precisely because it isn't chasing React. It takes fine-grained reactivity seriously and follows the idea all the way through to async, and the result is a set of primitives that make the hard parts of React (stale closures, dependency arrays, Suspense re-triggering, figuring out where mutations should live) feel like problems you can just stop having.

If you write React and you've never actually run Solid, this is the release to spend a weekend on. Spin up a project with solid-js@next, build something small with createSignal and <Loading>, and pay attention to how much of your usual React vigilance you can put down.

The beta is live at github.com/solidjs/solid, and the announcement discussion is worth reading in full if any of this piqued your interest.

SolidJS 2.0 Async Data: A Deep Dive for React Devs

Sat, 18 Jul 2026 22:31:40 +0000

In my first look at SolidJS 2.0 I said first-class async was the real story, then barely opened the box. This post opens it.

Here's the short version. In Solid 2.0 a promise is just another value the reactive graph knows how to wait for. A computation can return one, anything that reads it suspends until it resolves, and a <Loading> boundary shows a fallback only until the first real value lands. There's no createResource, no manual await in your components, and no re-render. If you write React, this is the part that behaves least like what you're used to, so it's worth slowing down on.

Everything below is from the 2.0.0-beta.18 line (npm install solid-js@next). It's a beta, and some of these names will still move before stable, so I've flagged the parts that are rougher.

How does async data fetching work in Solid 2.0?

A derived computation can return a promise, and the reactive graph treats the pending state as "not ready" until it settles. createResource is gone; a plain createMemo that returns a promise does the job, as the async RFC puts it: async is "a first-class capability of computations."

// Solid 1.x
const [user] = createResource(userId, fetchUser);

// Solid 2.0: the memo returns a promise, the graph waits on it
const user = createMemo(() => fetchUser(userId()));

Read user() anywhere and you get the resolved value. While the promise is in flight the read throws a NotReadyError internally, which propagates up the graph to the nearest boundary rather than crashing. You never catch it yourself; it's the mechanism that lets <Loading> and error boundaries work without a dedicated suspense primitive.

When userId() changes, the memo re-runs, returns a new promise, and the graph waits again. Same accessor, no dependency array, no effect wired up to refetch.

If you need the value imperatively outside a reactive scope (a route loader, an event handler), resolve hands you a real promise that settles once the expression is ready:

const currentUser = await resolve(() => user());

One correction to a thing you'll see repeated: there is no createAsync in core 2.0. createAsync is a @solidjs/router API, and its 2.0 shape isn't settled in the sources I could find, so don't reach for it as the core data primitive. The core primitive is the async createMemo above.

What replaced `<Suspense>`? The `<Loading>` boundary

<Loading> is the direct replacement for 1.x's <Suspense>, and the semantics are the reason the release was titled "The <Suspense> is Over." <Loading> covers initial readiness only. It shows its fallback while the subtree has nothing to render yet, and once real content is on screen it gets out of the way.

<Loading fallback={<Spinner />}>
  <Profile user={user()} />
</Loading>

This is the behavior React's Suspense makes you fight for. In React, when a value a Suspense boundary depends on changes, the boundary can rip the rendered content down and flash the fallback again unless you wrap the update in useTransition. That's also why router-driven navigations, which wrap their updates in transitions by default, keep the stale content visible instead and need a key to reset the boundary. Solid inverts the default: after the first paint, a refetch holds the old content on screen. It won't kick you back to the spinner.

When you do want the fallback to reappear on a specific change (say the whole record is being swapped, not refreshed), the new on prop opts into that:

<Loading on={userId()} fallback={<Spinner />}>
  <Profile user={user()} />
</Loading>

Now a change to userId() while data is pending re-shows the fallback; other pending work doesn't.

How do you coordinate several boundaries? `<Reveal>`

<Reveal> replaces 1.x's <SuspenseList> and controls the order in which sibling <Loading> boundaries reveal their content. It takes an order prop of "sequential" (the default), "together", or "natural":

sequential reveals boundaries in DOM order; later ones stay on their fallbacks until every earlier one has resolved.
together holds every fallback until the whole group is ready, then reveals at once.
natural lets each boundary reveal as soon as its own data lands.

There's also a collapsed boolean, consulted only under order="sequential", that renders a single frontier fallback instead of one per boundary. The control-flow RFC is the only source documenting the fine-grained nesting rules here, so treat the exact <Reveal> semantics as provisional until stable.

How do you show a refresh without a spinner? `isPending`

isPending reports that a change to a specific read is in flight, so you can show a subtle indicator while the stale content stays put. It takes a thunk, and it actually performs the read, so where you place it matters.

const refreshing = () => isPending(() => user());

<Loading fallback={<Spinner />}>
  <Show when={refreshing()}>
    <RefreshBar />
  </Show>
  <Profile user={user()} />
</Loading>;

First load hits <Loading> and shows the spinner. A later refetch keeps <Profile> visible and flips refreshing() to true, so you render a thin bar instead of tearing the page down. Stale-while-revalidate comes built into the primitive, so you don't assemble it yourself.

The gotcha that will catch you: a bare refresh() reads as not pending. Re-asking the same question (a poll, a manual refresh, a confirming refetch after a mutation) is treated as silent by design. If you want that reload to register as pending, you declare it with affects:

// Silent: isPending stays false, no refresh UI
refresh(user);

// Declared: now the refresh reads as pending
affects(user);
refresh(user);

affects is one of the newer, rougher corners of the API (it lives in a single RFC family and is likely to move), but the underlying rule is worth knowing now: pending is about a changed input, not about work happening. There's also a latest(fn) helper that peeks at the in-flight value during a transition and falls back to stale if the next value isn't ready, for when you want to show the incoming id before its data lands.

Where do mutations live now? `action` and optimistic updates

Solid 2.0 gives writes a home in core with action, and the shape is unusual: action wraps a generator. Each yield is a point where the action awaits, which lets the reactive system track an optimistic value until the real one lands.

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

const addTodo = action(function* (todo) {
  setTodos((t) => {
    t.push(todo); // optimistic: show it immediately
  });
  yield api.addTodo(todo); // await the server
  refresh(todos); // reconcile with the source of truth
});

createOptimistic has the same surface as createSignal, but its writes are optimistic: they can be overridden during a transition and revert when the transition completes. createOptimisticStore is the store version. The RFCs document it as createOptimisticStore(fnOrValue, seed, options?) while the migration guide shows a single-object form, so the exact arity is still settling; the two-argument derived form above is the one that's fully specified.

refresh(x) asks a derived signal or store to recompute. It's imperative revalidation, not a piece of UI state, which is why the affects dance above exists for the cases where you want a refresh to be visible. An async-generator form of action also works, where a bare yield; resumes the action in the same transition context after an await.

If you've used React 19's Actions and useOptimistic, the intent is familiar. The difference is that Solid folds the optimistic write, the server call, and the revalidation into one generator instead of splitting them across a hook and an action.

Why is batching deterministic now?

Solid 2.0 batches updates on a microtask by default, so a setter queues the write and reads don't reflect it until the batch flushes. batch() is removed; flush() is how you apply pending updates synchronously when you need the result right away.

const [count, setCount] = createSignal(0);

setCount(1);
count(); // still 0: queued on the microtask
flush();
count(); // 1

I mentioned this in the first post as a gotcha; the reason it matters here is that it's what makes async reliable. Running the tracking (compute) half of every effect before any side-effecting half gives the graph a complete dependency picture before anything runs, which is exactly what <Loading> and error boundaries need to decide what's ready. flush(fn) also takes a callback and drains the writes inside it before returning, preserving the return value. Coming from React's synchronous batching it's an adjustment, but the model is predictable once async is threaded through everything.

What changed for transitions? They're built in

This one's aimed squarely at React developers: startTransition and useTransition are gone. Solid 2.0 treats transitions as a core scheduling concept, and multiple can be in flight at once. Pending UI is expressed through <Loading> and isPending rather than by wrapping updates. You don't opt in per call site; the framework does the bookkeeping.

Here's the async surface mapped against React 19:

Task	React 19	Solid 2.0
Fetch data	`use()` + Suspense, or a data library	`createMemo` returning a promise
Loading UI	`<Suspense fallback>` (can re-trigger)	`<Loading>` (initial readiness only)
Refresh without a flash	`useTransition` + `isPending`, opt-in per call	`isPending(fn)`, observe any read
Optimistic update	`useOptimistic`	`createOptimistic` / `createOptimisticStore`
Mutations	Actions / form actions	`action(function*)` + `refresh`
Batching	automatic sync batching	microtask batching + `flush()`

The pattern across that table: React exposes each capability as a hook you opt into, while Solid pushes the distinction between "nothing to show" and "refreshing what's shown" down into the primitives, so you get the good behavior by default. That reactivity model is the same shift toward signals happening across the whole ecosystem.

Should you build on this yet?

Not in production. It's beta.18, the same early-but-real stage pnpm v12's Rust rewrite is in. The async core (async createMemo, <Loading>, microtask batching with flush, generator actions) is stable enough to learn on, but the edges (affects, createOptimisticStore's arity, <Reveal>'s nesting rules) are still moving. The announcement is worth reading in full in the beta.0 discussion.

What I'd actually do, and what I'm doing: build a small data-heavy screen with solid-js@next, wire up a createMemo that fetches, drop a <Loading> around it, and trigger a refetch. Watch the old content stay on screen while the new content loads. That single behavior is the clearest argument for why fine-grained reactivity was worth following all the way to async.

SolidJS 2.0 Async Data: A Deep Dive for React Devs

Thu, 16 Jul 2026 06:40:00 +0000

In my first look at SolidJS 2.0 I said first-class async was the real story, then barely opened the box. This post opens it.

Everything below is from the 2.0.0-beta.18 line (npm install solid-js@next). It's a beta, and some of these names will still move before stable, so I've flagged the parts that are rougher.

How does async data fetching work in Solid 2.0?

// Solid 1.x
const [user] = createResource(userId, fetchUser);

// Solid 2.0: the memo returns a promise, the graph waits on it
const user = createMemo(() => fetchUser(userId()));

When userId() changes, the memo re-runs, returns a new promise, and the graph waits again. Same accessor, no dependency array, no effect wired up to refetch.

If you need the value imperatively outside a reactive scope (a route loader, an event handler), resolve hands you a real promise that settles once the expression is ready:

const currentUser = await resolve(() => user());

What replaced `<Suspense>`? The `<Loading>` boundary

<Loading fallback={<Spinner />}>
  <Profile user={user()} />
</Loading>

This is the behavior React's Suspense makes you fight for. In React, when a value a Suspense boundary depends on changes, the boundary can rip the rendered content down and flash the fallback again unless you wrap the update in useTransition. Solid inverts the default: after the first paint, a refetch holds the old content on screen. It won't kick you back to the spinner.

When you do want the fallback to reappear on a specific change (say the whole record is being swapped, not refreshed), the new on prop opts into that:

<Loading on={userId()} fallback={<Spinner />}>
  <Profile user={user()} />
</Loading>

Now a change to userId() while data is pending re-shows the fallback; other pending work doesn't.

How do you coordinate several boundaries? `<Reveal>`

sequential reveals boundaries in DOM order; later ones stay on their fallbacks until every earlier one has resolved.
together holds every fallback until the whole group is ready, then reveals at once.
natural lets each boundary reveal as soon as its own data lands.

How do you show a refresh without a spinner? `isPending`

const refreshing = () => isPending(() => user());

<Loading fallback={<Spinner />}>
  <Show when={refreshing()}>
    <RefreshBar />
  </Show>
  <Profile user={user()} />
</Loading>;

// Silent: isPending stays false, no refresh UI
refresh(user);

// Declared: now the refresh reads as pending
affects(user);
refresh(user);

Where do mutations live now? `action` and optimistic updates

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

const addTodo = action(function* (todo) {
  setTodos((t) => {
    t.push(todo); // optimistic: show it immediately
  });
  yield api.addTodo(todo); // await the server
  refresh(todos); // reconcile with the source of truth
});

Why is batching deterministic now?

const [count, setCount] = createSignal(0);

setCount(1);
count(); // still 0: queued on the microtask
flush();
count(); // 1

What changed for transitions? They're built in

Here's the async surface mapped against React 19:

Task	React 19	Solid 2.0
Fetch data	`use()` + Suspense, or a data library	`createMemo` returning a promise
Loading UI	`<Suspense fallback>` (can re-trigger)	`<Loading>` (initial readiness only)
Refresh without a flash	`useTransition` + `isPending`, opt-in per call	`isPending(fn)`, observe any read
Optimistic update	`useOptimistic`	`createOptimistic` / `createOptimisticStore`
Mutations	Actions / form actions	`action(function*)` + `refresh`
Batching	automatic sync batching	microtask batching + `flush()`

Should you build on this yet?

Not in production. It's beta.18, the async core (async createMemo, <Loading>, microtask batching with flush, generator actions) is stable enough to learn on, but the edges (affects, createOptimisticStore's arity, <Reveal>'s nesting rules) are still moving. The announcement is worth reading in full in the beta.0 discussion.

SolidJS 2.0: A React Developer's First Look at Signals and Async

Thu, 02 Jul 2026 20:12:29 +0000

What is SolidJS 2.0?

pnpm add solid-js@next

The headline of the whole release is async. Solid's reactive graph now understands promises natively, and a lot of the API changes fall out of that one decision.

Fine-grained reactivity, from a React brain

Here's the mental model shift, and it's the thing to internalize before anything else makes sense.

function Counter() {
  const [count, setCount] = createSignal(0);

  // This whole function runs ONCE. Only the text node updates on click.
  return <button onClick={() => setCount(count() + 1)}>{count()}</button>;
}

First-class async is the real story

// Solid 1.x
const [data] = createResource(userId, fetchUser);

// Solid 2.0: the promise flows through the reactive graph
const data = createMemo(() => fetchUser(userId()));

To show that a refresh is in flight, you reach for isPending, which reports on pending reactive work without unmounting anything:

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

<>
  <Show when={refreshing()}>
    <RefreshIndicator />
  </Show>
  <Loading fallback={<Spinner />}>
    <UserList users={users()} />
  </Loading>
</>;

Mutations have a home now

const [messages, setMessages] = createOptimisticStore(() => chatServer.loadMessages(), []);

const sendMessage = action(function* (next) {
  setMessages((m) => {
    m.push(next); // optimistic: show it instantly
  });
  yield chatServer.sendMessage(next); // await the server
  refresh(messages); // reconcile with the source of truth
});

Deterministic batching, and a gotcha

One behavioral change will trip you up if you're not ready for it. Writes are batched on a microtask, and reads don't reflect a write until the batch flushes.

const [count, setCount] = createSignal(0);

setCount(1);
count(); // still 0: the update is queued on the microtask
flush(); // apply queued updates synchronously
count(); // now 1

The renames a React developer should know

<Suspense> → <Loading>, with the initial-readiness semantics above. <SuspenseList> becomes <Reveal>.
createEffect is split into a compute phase (what to track) and an apply phase (what to run with the result). Instead of reading signals inside one callback, you pass the two separately:
```
// Solid 1.x
createEffect(() => apiCall(signalB()));

// Solid 2.0
createEffect(signalB, apiCall);
createEffect(
  () => [signalA(), signalB()],
  ([a, b]) => a && apiCall(b),
);
```
If you've ever shipped a bug because a value was in a useEffect body but missing from the dependency array, separating the two is a direct answer to that. Ryan Carniato has also said the idiomatic 2.0 code reaches for createEffect far less than 1.x did, since async and derived state now cover cases you used to handle with an effect.
onMount → onSettled, reflecting the async-aware lifecycle.
<Index> → <For keyed={false}>; in that non-keyed mode the row is passed as an accessor, matching the old <Index> stability model.
Store setters are draft-first by default. You mutate a draft instead of threading a path. This is 1.x's produce behavior promoted to the default, so you no longer wrap the callback, with a storePath helper as the opt-in escape hatch for the old path style:
```
// 2.0 default: mutate the draft
setStore((s) => {
  s.todos[id].done = true;
});
// Legacy path style, opt-in
setStore(storePath("todos", id, "done", true));
```
classList is folded into class, which now takes strings, arrays, and objects.
use: directives are removed in favor of ref directive factories.
Context is simpler. The context is directly usable as the provider, so Context.Provider is gone. A context created without a default is typed as its value instead of T | undefined, and useContext throws ContextNotFoundError when there's no provider above it; a context created with a default still returns that default:
```
const Theme = createContext(); // no default
// 2.0: the context is its own provider
<Theme value="dark">{/* ... */}</Theme>;
```

Signals are heading toward the standard

The word "signals" is everywhere now, and it's worth knowing why. There's a TC39 Signals proposal at Stage 1, with design input from the people behind Angular, Vue, Svelte, Preact, Qwik, MobX, and Solid. Ryan Carniato, Solid's creator, has been part of that conversation for years, and his writing on fine-grained reactivity helped push it onto the committee's radar.

Worth being precise here, because it's easy to overstate: Solid 2.0 does not ship the TC39 API as its core. The proposal is synchronous, and Solid 2.0's whole thing is async reactivity, which goes further than what's currently on the table. Solid influences and tracks the standard rather than implementing it. But the fact that the primitive Solid has bet on for years is now a serious standardization effort tells you the industry is drifting toward the model React chose not to adopt. Svelte 5 already rebuilt its reactivity around signals with its runes API, and it's unlikely to be the last framework to make the jump.

Should you drop React? No. But watch this closely.

I'm not migrating my day job to Solid this quarter, and I don't think you should either. It's a beta, the ecosystem is smaller than React's, and API names are still moving. That's the honest read.

The beta is live at github.com/solidjs/solid, and the announcement discussion is worth reading in full if any of this piqued your interest.

Coder Legion - Recent posts tagged solidjs

SolidJS 2.0 for React Developers: A First Look

What is SolidJS 2.0?

Fine-grained reactivity, from a React brain

Why async is the real story of SolidJS 2.0

How do mutations work in SolidJS 2.0?

Deterministic batching, and a gotcha

The renames a React developer should know

Signals are heading toward the standard

Should you drop React? No. But watch this closely

SolidJS 2.0 Async Data: A Deep Dive for React Devs

How does async data fetching work in Solid 2.0?

What replaced <Suspense>? The <Loading> boundary

How do you coordinate several boundaries? <Reveal>

How do you show a refresh without a spinner? isPending

Where do mutations live now? action and optimistic updates

Why is batching deterministic now?

What changed for transitions? They're built in

Should you build on this yet?

SolidJS 2.0 Async Data: A Deep Dive for React Devs

How does async data fetching work in Solid 2.0?

What replaced <Suspense>? The <Loading> boundary

How do you coordinate several boundaries? <Reveal>

How do you show a refresh without a spinner? isPending

Where do mutations live now? action and optimistic updates

Why is batching deterministic now?

What changed for transitions? They're built in

Should you build on this yet?

SolidJS 2.0: A React Developer's First Look at Signals and Async

What is SolidJS 2.0?

Fine-grained reactivity, from a React brain

First-class async is the real story

Mutations have a home now

Deterministic batching, and a gotcha

The renames a React developer should know

Signals are heading toward the standard

Should you drop React? No. But watch this closely.

What replaced `<Suspense>`? The `<Loading>` boundary

How do you coordinate several boundaries? `<Reveal>`

How do you show a refresh without a spinner? `isPending`

Where do mutations live now? `action` and optimistic updates

What replaced `<Suspense>`? The `<Loading>` boundary

How do you coordinate several boundaries? `<Reveal>`

How do you show a refresh without a spinner? `isPending`

Where do mutations live now? `action` and optimistic updates