How should a stateful component library layer its own writable state over a user's createOptimisticStore?

[thedanchez]

I maintain Solid Flow (a node-graph/canvas library on 2.0.0-rc.3). Like most stateful component libraries — tables, editors, canvases — we accept a user-owned store as a prop and maintain library-owned interactive state on top of it: selection flags, in-gesture drag positions, measurements. Users own membership and data; the library writes the ephemera.

With plain stores this composes cleanly. The pattern outlined in the "Write Sync, Run Async" blog is that a user upgrades createStore to createOptimisticStore and wraps mutations in action without consumers changing. For a component library consumer, we haven't found a composition that survives that upgrade:

1. Sharing the store (library writes into the user's store): library writes necessarily happen outside any user action, and an optimistic write outside an action reverts as soon as its (synchronous, empty) transaction completes. Every library write — a selection flag, a drag position — is silently inert. Minimal shape, no library involved:

const [rows, setRows] = createOptimisticStore(async () => api.list(), []);
// after first settle, outside any action:
setRows((d) => { d[0].selected = true; });
flush();
rows[0].selected; // undefined — reverted immediately

2. Copying into a library-owned store and syncing from the user's store: the library then needs to observe user mutations, but the canonical action shape mutates rows in place (d[i].completed = v), which changes neither array length nor row identity — so any sync that isn't per-field-tracking misses it, and per-field tracking of the whole graph is what fine-grained architectures exist to avoid.

3. Branching on store kind isn't possible: there's no isOptimisticStore-style predicate, so a raw optimistic store passed to a library is indistinguishable from a plain store until its writes vanish.

Our best current design is a per-row mirror projection (library-owned rows, user fields derived fine-grained per row, library fields layered on top), entered through tagged factory functions so we can detect the optimistic case at all. Before building it:

• Is there an intended pattern here — e.g. deriving a writable store from an optimistic source, or a supported way to write "non-speculative" state adjacent to an overlay?
• Is the instant revert of out-of-action optimistic writes settled semantics, or is a warning (like [SERVER_WRITE]) planned? Today the write is dropped with no signal, which is how this surfaced.
• Would core consider exposing optimistic-store detection, or is requiring library-specific factory entry points the expected shape?

Happy to share the full compat test suite if useful.

[thedanchez]

Would love to get your insight @ryansolid if you have any time to spare 🙏🏾

[ryansolid]

Good questions — and validating them shook out a real engine bug (#3089, fixed on next) that was making mid-action reads through derived stores look torn, so thanks for pushing on this.

The composition that survives the optimistic upgrade: don't mirror the collection at all. Render membership from the user's store directly, and keep your ephemera in a library-owned store keyed by row id, joined at read time:

// library-owned, keyed sidecar — no membership mirror, no syncing
const [lib, setLib] = createStore({} as Record<Id, { selected?: boolean; dragX?: number }>);

// render path: the user's store drives membership AND fields,
// ephemera joined per row by key
<For each={props.nodes}>
  {(node) => <Node data={node} selected={lib[node.id]?.selected ?? false} />}
</For>

// library writes are plain writes on your own store
setLib((d) => { (d[node.id] ??= {}).selected = true; });

This composes identically over plain and optimistic sources, which dissolves each of your three failure modes:

• Your writes never touch the user's store, so they never enter an optimistic overlay — no reverts, no inert selection flags. Plain writes on the sidecar persist before, during, and after the user's actions.
• There's nothing to sync. In-place field mutations (d[i].completed = v) flow because you read the user's rows directly; you never copied anything, so per-field tracking of the graph never comes up.
• Because reads compose the same either way, you don't need to detect the store's kind.

Critically, this keeps the optimistic UX intact through your library: an optimistic membership edit (user's action pushes a node) renders immediately — the new node appears mid-action, your ephemera on existing rows stay put, and you can even write ephemera for the optimistic row while its action is in flight. At settle the overlay resolves and your sidecar is untouched. We verified this exact sequence in a test against next, now pinned in the repo's regression suite.

A caution on the per-row mirror projection you're planning: a derived store's output is settle-scoped by design — a projection recomputing from uncommitted inputs is speculative, so committed-visibility readers hold the pre-transaction view until the transaction settles. (The engine can revert an overlay; it can't un-bake an overlay that a recompute already folded into someone else's committed state — so the quarantine is the price of a derive being a store rather than a read.) Concretely: fields you derive into library-owned rows will not show the user's optimistic edits mid-action, and derived membership won't show an optimistically-added node until the server responds. For a canvas where optimistic add/drag is the point, the mirror hides exactly what the user upgraded to see. A derived writable store is the right tool only when you need a transformed collection you own (a sorted/filtered layout array) — and if you do build one, hold the user's row proxies by reference inside your rows rather than copying fields (reads through the proxy pierce to the overlay; copies don't), and accept that membership changes surface at settle.

On the silent revert (your question 2): the instant revert of an out-of-action optimistic write is settled semantics — optimistic writes are transaction-scoped by definition, and outside an action there is no transaction to scope to. The write vanishing with no dev-mode signal is fair feedback, though; that's how this cost you time.

On detection (your question 3): no predicate planned. With the composition above it's load-bearing that you don't branch on store kind — the library that needs to know is usually the library that's about to write into a store it doesn't own. Tagged factory entry points also shouldn't be necessary for the same reason.

[thedanchez]

Report-back: we implemented the composition exactly as you described and it shipped this week in @dschz/solid-flow@1.0.0-next.11 — keyed sidecars for library ephemera (selection, in-gesture drag positions, measurements) joined with the user's rows at read time, with membership rendered from the user's store directly. Our acceptance suite is green over createOptimisticStore inputs: an optimistic add renders mid-action, a rejected action reverts the canvas cleanly, flow commands work inside open action transactions, and library state survives refresh() reconciles. One unbranched code path over plain and optimistic sources, no store-kind detection — all three of our original questions dissolved, as you predicted.

Two findings from the implementation that may be useful data points:

1. On rc.3 we did not hit settle-scoping for keyed reads through a derived record — individual key access pierced the overlay mid-action throughout our pipeline. The one read that held the committed view was the record's enumeration (Object.keys on a derived keyed store). Rendering membership from the user's store, per your model, resolved it.

2. Adopting the composition pushed us to profile our gesture paths, which surfaced a pre-existing drag-start cost we then cut ~6.5× at 10k nodes. The remaining slice is a marking wave when a keyed derived store with many per-key subscribers is pulled inside a write flush — we have CPU profiles isolating it; happy to file it separately with a repro if that's useful signal for the engine.

Thanks again — marking this as the answer.