Solid vs React: the Mental Model
A direct comparison of how Solid and React handle rendering, state, and updates, for developers translating knowledge between the two.
읽는 데 3분
By this point in the course you've seen each piece individually — signals instead of useState, no re-renders, props that must stay unwrapped, stores for nested state. This lesson pulls those threads together into one side-by-side comparison, because the clearest way to really internalize Solid is against the framework most readers already know.
Rendering: one-time setup vs repeated execution
// React: this function body re-runs on every state change
function Counter() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>{count}</button>;
}
// Solid: this function body runs exactly once
function Counter() {
const [count, setCount] = createSignal(0);
return <button onClick={() => setCount(count() + 1)}>{count()}</button>;
}In React, the mental model is "state changes cause a re-render, which produces a new tree, which gets diffed against the old one." In Solid, there is no re-render step at all — the component function is setup code that runs once, and updates happen directly at the DOM binding level, wherever a signal is read.
Why memoization hooks disappear
React's useMemo and useCallback exist to avoid redoing expensive work (or creating new function references) on every re-render. Solid has no re-renders to protect against, so those specific hooks have no equivalent — createMemo exists, but for a different reason (caching a genuinely expensive derived computation), not as a defense against re-execution that doesn't happen in the first place.
Why the dependency array disappears
React's useEffect needs a dependency array because React can't automatically know what a function "depends on" — you have to declare it, and a missing entry is a silent bug. Solid's createEffect tracks dependencies by literally recording which signals were read during execution, so there's nothing to declare and nothing to get wrong by omission.
State shape: signals and stores vs useState/useReducer
| Concern | React | Solid |
|---|---|---|
| Single value | useState | createSignal |
| Derived value | recomputed each render, or useMemo | plain function, or createMemo for caching |
| Side effect | useEffect + dependency array | createEffect, dependencies auto-tracked |
| Nested/structured state | useState + spreading, or useReducer | createStore with path-based updates |
| Shared state | Context + useContext | createContext + useContext (nearly identical) |
The props rule has no React equivalent
There's no React parallel to "destructuring props breaks reactivity," because React re-renders the whole function on every prop change anyway — a destructured { name } gets a fresh, correct value every render, by design. In Solid, that same destructuring only happens once, so it silently freezes. This is the single biggest source of subtle bugs for React developers learning Solid, precisely because the code that's wrong in Solid looks completely idiomatic in React.
The one-sentence summary
React re-renders and diffs; Solid tracks and updates directly. Nearly every other difference in this course — no dependency arrays, no useMemo/useCallback, the props gotcha, stores instead of nested useState — is a direct consequence of that one structural choice.