Structural Sharing
Slap yourself if
You think structural sharing means copying objects less or that immutability always means deep cloning.
Why this exists
Structural sharing exists to make immutable updates efficient by reusing unchanged parts of a data structure instead of copying everything, enabling fast updates, cheap comparisons, and predictable state management.
Mental model
Structural sharing means new versions of data reuse most of the old structure. Only the path that changed is new; everything else is shared by reference. This makes immutable updates practical at scale.
- You create a new version of a data structure after a change.
- Only the nodes on the path to the changed value are newly allocated.
- All unchanged branches are reused by reference.
- Old and new versions coexist safely without mutation.
- Reference equality reflects what actually changed.
- Assuming immutability requires deep cloning entire objects.
- Mutating nested data and breaking shared structure guarantees.
- Accidentally sharing mutable objects and causing hidden side effects.
- Expecting structural sharing without using libraries or patterns that provide it.
Structural sharing is an immutability technique where new versions of data reuse unchanged parts of the old structure by reference, so updates are efficient and comparisons can rely on reference equality.
- Immutable updates always require deep copies.
- Structural sharing is just a performance optimization.
- Sharing references is dangerous by default.
Deep dive
Premium deep dives include more internals, more scars.
How structural sharing works internally
How broken sharing causes subtle bugs
Once sharing assumptions break, bugs become invisible and hard to reason about.
Tradeoffs vs deep cloning and mutation
Structural sharing trades simplicity for safety and performance.
Why structural sharing matters for UI performance
Structural sharing is what makes memoization and selectors fast.
Interview landmines
- Equating immutability with deep cloning
- Ignoring reference equality benefits
- Not mentioning persistent data structures
Related terms
Immutable Data Patterns
You think immutability just means using spread syntax or that it’s only about avoiding bugs.
Referential Equality
You think two objects with the same values are equal in JavaScript or that referential equality is an implementation detail you can ignore.
Memoization Pitfalls
You think memoization automatically makes code faster or that using useMemo/useCallback is always a performance win.
Concurrent Rendering
You think concurrent rendering means React renders in parallel threads or it always makes apps faster.
Tearing in concurrent UI
You assume a render either fully happens or doesn’t happen at all.