Diagnosing Silent Reactivity in SolidJS: Signals, Memos, and Effects That Won’t Trigger

Problem Statement

In a SolidJS application you update a signal (e.g., count()), click a button, but the DOM does not reflect the new value. The component renders once and then appears frozen. This article provides a diagnostic workflow to pinpoint why reactivity is silent, covering signals, memos, effects, batching, and common pitfalls.

Recognizable Condition

Typical symptoms include:

• A console.log inside an onMount or createEffect runs only once.
• The UI shows the initial value forever, even after state changes.
• Solid DevTools shows the signal but no effect or memo is subscribed.
• Updating a signal inside an event handler or async callback has no visible impact.

Short Cause & Diagnostic Table

Cause	Diagnostic Check	Fix
Signal read outside a tracking scope	Locate count() outside JSX, createEffect, or createMemo	Move the read into a reactive context or call count() inside the handler body.
Stale closure in event handler	Handler defined as a component method or arrow that captures old signal value	Read the signal inside the handler or use useCallback‑style binding.
Missing dependency in createMemo	Memo body references a signal but never reads it at runtime	Ensure the memo reads the signal or expose it via a computed property.
Batching boundary mis‑placement	Multiple set calls inside an async function without awaiting	Wrap updates in createRoot or use await flushSync() (v1.8+).
Non‑reactive property access in createStore	Direct array mutation (e.g., push) on a raw array	Use the store’s mutable API or produce from solid-js/store.
SSR hydration mismatch	Server‑rendered HTML differs from client initial state	Serialize initial signal values and use createResource for async data.
Third‑party DOM manipulation	jQuery or D3 modifies DOM outside Solid’s render tree	Trigger a signal write after DOM changes or use onMount to re‑hydrate.

Ordered Checks & Fixes

1. Confirm the signal updates. In the component, add:

   const [count, setCount] = createSignal(0);
   createEffect(() => {
     console.log('Signal value:', count());
   });
   

   Run the app and click the button that calls setCount. The console should log a new value each click. If it does not, the signal is not being updated or the effect is not subscribed.
2. Inspect the reactive graph. Install the Solid DevTools browser extension. Open the “Reactivity” panel, locate the signal, and check if any effects or memos are attached. An empty dependency list indicates a stale read.
3. Verify signal reads inside reactive scopes. Search the component for count() calls. They must reside inside JSX, createEffect, createMemo, or an event handler that runs during a render cycle. If a read occurs in a plain setTimeout callback or after await, the read is outside a tracking scope and will not register.
4. Check for stale closures. If you have an event handler defined as:

   const handleClick = () => {
     setCount(count() + 1);
   };
   

   and the handler is passed to a component that memoizes props, the closure may capture the old count value. Move the read inside the handler body or bind the handler with useCallback‑style syntax:

   const handleClick = () => {
     setCount(c => c + 1);
   };
   

5. Audit memo dependencies. A createMemo that never reads a signal will never recompute. Ensure the memo body includes a call to the signal:

   const double = createMemo(() => count() * 2);
   

   If count() is omitted, add it or expose the memo via a computed property.
6. Examine batching boundaries. Solid batches synchronous updates. If you perform multiple set calls inside an async function, the batch may flush before subsequent writes. Wrap updates in createRoot or call await flushSync() (v1.8+). Example:

   import { flushSync } from 'solid-js';
   async function updateAll() {
     setA(1);
     setB(2);
     await flushSync(); // forces immediate render
   }
   

7. Validate store mutations. With createStore, direct array mutations bypass reactivity. Use the store’s mutable API:

   const [state, setState] = createStore({ users: [] });
   setState('users', users => {
     users.push({ name: 'Alice' });
   });
   

8. Check SSR hydration. In a solid-start project, run:

   npm run dev
   

   Open the page, view source, and compare the HTML for count with the client‑side rendered value. Mismatches indicate a hydration issue.
9. Inspect third‑party DOM changes. If you use jQuery or D3 to modify the DOM, call setCount after the manipulation or wrap the code in onMount and onCleanup to ensure re‑render.
10. Run unit tests with real timers. In vitest or jest, avoid fake timers when testing reactivity. Use await flushPromises() after signal writes and then query the DOM.

Practical Verification Checklist

• Signal updates: console log shows new value on each click.
• Effect or memo: Solid DevTools shows a dependency edge from the signal.
• Batching: after a set of updates, the DOM reflects all changes before the next event loop tick.
• Store: UI updates after mutating nested arrays via the store API.
• SSR: Server HTML matches client initial state; no hydration warnings in console.

Limitations & Escalation Criteria

These checks cover the majority of silent reactivity bugs in SolidJS. However:

• Complex third‑party integrations may introduce subtle DOM mutations that are hard to track.
• Version‑specific changes (e.g., batching behavior in Solid 1.8) may require consulting the changelog.
• Asynchronous data loading via createResource can delay updates if the resource resolves after the initial render.

If, after following all steps, the UI still does not update, consider:

• Creating a minimal reproduction on CodeSandbox and sharing it with the Solid community.
• Reviewing the component tree for deeply nested stores or context providers that may shadow signals.
• Checking for custom createEffect wrappers that might suppress updates.

Conclusion

SolidJS’s fine‑grained reactivity is powerful but requires careful placement of signal reads, awareness of batching boundaries, and correct store mutations. By systematically checking the conditions above, you can quickly restore predictable UI updates and avoid silent bugs that frustrate developers and users alike.