A screen that scrolls smoothly at sixty frames on an emulator can still stutter badly on a mid-range Android phone the moment a list grows past a few hundred rows, and the cause is almost never the device — it is a component tree that re-renders far more often, and far more widely, than the state change actually requires. React Native inherits React's rendering model wholesale: a state update anywhere in the tree schedules a re-render of that component and, by default, every descendant beneath it, whether or not that descendant's output would actually change. On the web this is often invisible because the browser's paint pipeline absorbs the waste. On a phone, every unnecessary re-render is JavaScript-thread work competing with gesture handling, animation callbacks, and list scrolling on the same thread, and it shows up as dropped frames a user can feel with their thumb.
This lesson is about the discipline that keeps that from happening: knowing precisely which values are props and which are state, knowing exactly what triggers React to re-render a component, and knowing when — and only when — reaching for `React.memo`, `useCallback`, or `useMemo` actually helps rather than adding indirection with no payoff. Getting this wrong in either direction is expensive: under-memoizing produces the jank described above, and over-memoizing produces a codebase full of dependency arrays nobody trusts, chasing stale-closure bugs that are harder to debug than the re-renders they were meant to prevent.
Analogy🏏Cricket
🏏 Think of it like cricket: A television broadcast's on-screen scorecard graphic does not redraw the entire panel — team names, ground, weather, both batsmen's stats, the bowler's figures, the required run rate — every time a single run is scored. The graphics operator's system is built so that a single ball's outcome updates only the specific fields that actually changed: the striker's score ticks up, the total ticks up, and the run-rate figure recalculates, while the ground name, the toss result, and the non-striker's untouched figures stay exactly as they were, because redrawing the whole panel for every ball would flicker constantly and cost render time the broadcast cannot spare during a fast T20 innings. When Jos Buttler hits a boundary, the system does not also repaint Rashid Khan's bowling figures if Rashid did not bowl that ball — only what the ball actually changed gets touched. Just as the broadcast graphic isolates exactly which fields a single ball's outcome affects, a React Native component tree should isolate exactly which components a single state update affects, rather than letting an update anywhere cascade into redrawing everything beneath it. Just as the operator's system was engineered in advance to know which fields depend on which events, a well-structured component tree is engineered so state lives close to where it changes and does not force distant, unrelated components to re-render just because they happen to sit beneath it. The insight is that a fast, professional broadcast and a fast, professional app share the same rule: update only what actually changed, because touching everything on every event is what turns a smooth production into a flickering, dropped-frame mess.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.