Referential Equality
Slap yourself if
You think two objects with the same values are equal in JavaScript or that referential equality is an implementation detail you can ignore.
Why this exists
Referential equality exists as a fast, reliable way to detect whether something actually changed. In UI systems, it enables cheap comparisons, memoization, and predictable rendering behavior without deep checks.
Mental model
Referential equality answers one question: are these two variables pointing to the exact same object in memory? If the reference is the same, nothing changed. If the reference is different, something changed — regardless of whether the values look identical.
- Objects and arrays are compared by reference, not by value.
- If two variables point to the same object, they are referentially equal.
- Creating a new object always produces a new reference.
- Shallow comparisons rely entirely on referential equality.
- Frameworks use reference checks to decide whether to skip work.
- Recreating objects on every render and breaking memoization.
- Mutating objects in place and keeping the same reference while values change.
- Assuming deep equality checks are cheap or automatic.
- Using referential equality without structural sharing guarantees.
Referential equality means two variables point to the same object in memory. UI frameworks rely on it for fast change detection, so stable references signal 'no change' while new references signal updates.
- Two objects with the same values are equal.
- React compares objects deeply.
- Referential equality is just a JavaScript quirk.
Deep dive
Premium deep dives include more internals, more scars.
Why referential equality is so cheap
How broken references break rendering guarantees
Referential equality only works if you respect its contract.
Reference checks vs deep equality
Fast checks come with strict rules.
Why referential equality matters for performance
Nearly every performance optimization in modern UI depends on stable references.
Interview landmines
- Confusing referential equality with deep equality
- Ignoring immutability requirements
- Not connecting it to memoization or rendering behavior
Related terms
Structural Sharing
You think structural sharing means copying objects less or that immutability always means deep cloning.
Immutable Data Patterns
You think immutability just means using spread syntax or that it’s only about avoiding bugs.
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.