A tiny signal: automatic tracking, then a bridge into React
Nobody listed dependencies: each effect subscribed to exactly the signals it read while running. Click the button: effect B logs again, because the React handler sets the same signal. Real libraries (Preact Signals, SolidJS) add batching, computed values, cleanup and glitch-free ordering on top of this idea.
Besides one big store, state can be split into tiny independent atoms (Jotai, Recoil), tracked automatically with signals or observables (Preact Signals, MobX), or modelled as a state machine (XState); each model trades React's simple re-render rule for a different kind of precision.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Using the hand-made atom from the live example, add a discountAtom (0 to 1) and make totalAtom apply it. Which components re-render when the discount changes?
Write a transition table for a traffic light (green → yellow → red → green on TIMER, and any state → flashing on FAULT, flashing → red on RESET) and a reducer that uses it.
Explain it without notes
How does an atom-based library like Jotai differ from a single-store library like Zustand or Redux?
What are signals, and why doesn't React use them for state?
How does MobX decide which components to re-render?
What problem do state machines solve in UI code, and when would you reach for XState?
Preview
Console
Nothing logged yet.Expected console output
effect A: full name = Asha Rao
effect B: clicks = 0
-- set last
effect A: full name = Asha Kumar
-- set clicks
effect B: clicks = 1
-- set clicks to the same value