Product 1 publisher3 min readPublished September 22, 2026 at 2:30 PM PDT

Solid 2.0 lets a component ask the data whether it is pending

A walkthrough at brenelz.com shows Solid 2.0's isPending reading pending state off a memo or an expression, while the React version of the same screen splits into two components and reports on the transition.

The Product Desk · Product desk

Illustration accompanying Solid 2.0 lets a component ask the data whether it is pending

What happened

Solid 2.0 adds isPending. It takes a function that reads reactive state, either an accessor or an expression, and reports whether that expression depends on an in-flight change.
In the React version of the same screen shown in the walkthrough, the work splits across a parent holding useState and useTransition and a child that calls use() on a promise inside a Suspense boundary.
Solid's createOptimisticStore derives its value from the API call itself, so getMessages() supplies the server truth and optimistic changes are written on top as mutations such as m.push(message).
Solid's action is written as a generator so its runner can restore context after a yield, where React currently needs another startTransition to mark state updates made after an await.
The walkthrough names six small touches in Solid 2.0, and works through the first two before breaking off mid-sentence in the optimistic-updates section.

Compiled by The Product DeskSomething wrong?How this is made

Why it matters

capability A component can put the spinner next to the value that is actually waiting, without a parent threading a transition flag down to the child that owns the data.
decision A team weighing the 2.0 upgrade can price two of the six additions against its existing code; the remaining four come with no code yet.
cost Generator-based actions are a new authoring habit for application developers, and the teams that adopt them pay for it in code review before they save anything.
constraint The pitch is about how the framework feels, so an engineer asking a manager for upgrade time is arguing feel, without a measured retention, time-to-value or bundle figure to bring.

The spinner beside a user's name is the small version of this problem. Someone clicks, an id changes, a fetch goes out, and the component has to work out which part of the screen is now stale. The Solid example prints isPending(user) and isPending(id) next to each other. The component can ask whether the user is pending, or whether the write to id is still waiting on downstream async work ^[12].

The React version in the same post answers a different question. Its flag comes from useTransition in the parent, and the value itself arrives in a child through use(getUserPromise(id)) under a Suspense boundary ^[8]. "Notice we can't really ask if the user is pending," the author wrote ^[1].

The import counts are the wrong place to look for the saving. Both snippets pull four framework APIs, createSignal, createMemo, isPending and Loading on one side, Suspense, use, useState and useTransition on the other. The React file adds an import from a data module and a second function component ^[1].

On the optimistic side, the wiring that moves is the fetch. React's useOptimistic also takes an existing value as its source of truth, but it does not manage the API call that produced that value. Fetching and refreshing are connected by hand, and the initial data arrives from a parent as initialMessages ^[5]. In the Solid version the store owns that call. When the action finishes, the optimistic layer is removed and refreshed server data becomes authoritative; if that data reconciles to values already displayed, Solid can avoid further DOM updates ^[4]. Expressing the change as m.push(message) also lets the store track the write granularly and update the parts of the UI that depend on what changed ^[11]. Across the two optimistic snippets, React's addMessage nests startTransition twice and Solid's action uses it zero times ^[2].

The claim the post makes for the whole set is about feel. "Individually, they might seem small. Together, they make a real difference in how the framework feels to use," the author wrote ^[2]. The text measures nothing, and the case rests on the two worked examples. Derived state you can override, choosing where each value is computed, server reads as function calls and a runtime that explains itself are list entries in the material available ^[9]^[10].

A team on Solid 1.x can price this from its own repo. Count the booleans that exist only to report that a request is in flight, then count how many of those get read next to a value they do not actually track. The second number is what isPending replaces. If it is small, two worked examples do not pay for a major-version upgrade.

What to watch

Whether worked code appears for the four touches the post only names, starting with overridable derived state and per-value computation placement.
Whether the SolidJS project ships a migration guide mapping Solid 1.x patterns onto isPending and createOptimisticStore.
Reports from teams that replaced hand-rolled pending helpers with isPending in production, with before-and-after component counts.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[10]
The text available covers the first two of the six touches with code, and breaks off mid-sentence in the optimistic-updates section while describing the React refresh path.
ReportedSupported2 sources— sign in to open View cited source
[1]
In Solid 2.0, isPending takes a function that reads reactive state and reports whether that expression depends on an in-flight change.
ReportedSupportedSource: brenelz.com post on Solid 2.0View cited source
[2]
isPending accepts an accessor directly, like isPending(user), or an expression, like isPending(() => user().name).
ReportedSupportedView cited source
[12]
The Solid example renders isPending(user) and isPending(id) side by side, and the author notes that pending state can be queried from the data itself: whether user is pending, or whether the write to id is still waiting on downstream async work.
ReportedSupportedView cited source
[13]
The Solid isPending example imports createSignal, createMemo, isPending and Loading from solid-js, and all of it sits in a single function component named Example.
ReportedSupportedView cited source
[8]
The React equivalent in the post imports Suspense, use, useState and useTransition from react plus getUserPromise from ./data, and splits into two function components: Example, which holds useState and useTransition and the Suspense boundary, and UserDetails, which calls use(getUserPromise(id)).
ReportedSupportedView cited source
[cq1]
"Notice we can't really ask if the user is pending. We might not even know the setting of the id triggered it."
ReportedSupportedSource: author of the Solid 2.0 walkthrough at brenelz.comView cited source
[cq2]
"Individually, they might seem small. Together, they make a real difference in how the framework feels to use."
ReportedSupportedSource: author of the Solid 2.0 walkthrough at brenelz.comView cited source
[3]
Solid's createOptimisticStore derives the optimistic value straight from an API call, in the example () => getMessages(), which is treated as the truth from the server; its initial value is the messages it got, and optimistic updates are mutated on top, such as a push to the end.
ReportedSupportedView cited source
[5]
React's useOptimistic also takes an existing value as its source of truth, but it does not manage the API call that produces that value, so the fetching and refreshing must be connected manually; in the post's example the initial data comes from a parent through initialMessages.
ReportedSupportedView cited source
[14]
In the post's React optimistic example, addMessage wraps its work in startTransition(async () => ...), calls setOptimisticMessages, awaits saveMessage(message), awaits getMessages(), and then nests a second startTransition(() => setMessages(refreshedMessages)).
ReportedSupportedView cited source
[15]
In the post's Solid optimistic example, addMessage is action(function* (message) { setMessages(m => { m.push(message); }); yield saveMessage(message); refresh(messages); }), with no transition wrapper.
ReportedSupportedView cited source
[9]
The post lists six small touches in Solid 2.0: Ask Your Data What's Pending; Optimistic Updates with Less Wiring; Derived State You Can Override; Choose Where Each Value Is Computed; Server Reads as Function Calls; A Runtime That Explains Itself.
ReportedSupportedView cited source
[d1]
Both isPending snippets import four framework APIs; the React file additionally imports one data-module function and declares a second function component.
DerivedSupported1 source— sign in to open
[d2]
In the two optimistic examples, the React version uses startTransition twice and the Solid version uses it zero times.
DerivedSupported1 source— sign in to open
[4]
When the Solid action finishes, the optimistic layer is removed and the refreshed server data becomes authoritative; if that data reconciles to the same values already being displayed, Solid can avoid further DOM updates.
ReportedInsufficientView cited source
[11]
Solid's store tracks mutation writes such as m.push(message) at a granular level, so it can update the parts of the UI that depend on what changed; the author says he has come to appreciate expressing the change as a mutation instead of [...current, message].
ReportedInsufficientView cited source
[6]
In Solid, function* creates a generator, allowing Solid's action runner to restore its context when execution resumes after a yield.
ReportedInsufficientView cited source
[7]
React currently requires another startTransition to mark state updates after an await as transition updates.
ReportedInsufficientView cited source

Sources

Publishers with included, body-backed reporting in this cluster.

brenelz.com
1 article · September 22, 2026
Solid 2.0: It's the Little Things

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

The useful part of this post is that every claim arrives with the code. isPending takes a function that reads reactive state, so isPending(user) and isPending(() => user().name) both work, and the example prints the pending state of the memo and of the signal write on the same screen. The React version of that screen splits into two components, imports a promise-returning helper, and reports the transition instead; "Notice we can't really ask if the user is pending," the author writes. In the optimistic pair, React's addMessage calls startTransition twice and Solid's action calls it not once, because the generator lets Solid's runner pick its context back up after the yield. Before building on any of it, note that the post never says what state Solid 2.0 is in, and that granular write tracking and skipped DOM updates are the author's description of behaviour he does not measure here.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence45

0100

Quoted code, one author

Every API in this story comes with the code that calls it, and the snippets are short enough to verify by reading: the import lists, the component split and the startTransition counts are all on the page. What sits behind them is one developer's post on his own site, with no Solid documentation or release note to check the described behaviour against. The copy also stops mid-sentence in the fourth section.

AdoptionInsufficient

No usage or release signal

The post is written as a tour of APIs a reader can write against, and it does not say whether Solid 2.0 has shipped or who is using it. Nothing else in our coverage fills that in.

Hype gap+5

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

build
With CRA out of React's docs, the new project default is a rendering decision
1 publisher
build
Paying 0.30 coins per decision compresses a 13x difficulty spread into a 4.4x payout
1 publisher
build
Two stable references took a 4,000-row table's slowest keystroke from 166ms to 47ms
1 publisher
build
A build-tool swap that took 70 days and 166 files, and the build was the easy part
1 publisher

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources