You do not need to memorize [React](/courses/reactjs)'s internal implementation to reason correctly about rendering. A few core rules explain most real-world behavior. ### 1. Rendering and DOM Updates Are Different This: ```text Component rendered again ``` does not mean: ```text DOM was rebuilt ``` [React](/courses/reactjs) can render a component, compare its result with the previous one, and make no DOM changes if nothing relevant changed. ### 2. React Preserves State by Component Identity Consider: ```jsx {loggedIn ? ( ) : ( )} ``` Switching between `Dashboard` and `Login` changes the component type at that position. Their local state does not represent the same component identity. ### 3. Same Component at the Same Position Usually Preserves State ```jsx ``` changing to: ```jsx ``` still leaves a `Counter` at the same position. Its props changed, but React can preserve its local state. If the state should reset when the user changes, a key can [express](/courses/expressjs) the new identity: ```jsx ``` ### 4. Component Definitions Should Not Be Recreated Inside Other Components Without a Reason Avoid patterns such as: ```jsx function Parent() { function Child() { const [count, setCount] = useState(0); return

{count}

; } return ; } ``` Every time `Parent` runs, a new `Child` [function](/javascript/functions-in-javascript) definition is created. React may treat it as a different component type, which can cause state to reset unexpectedly. Prefer: ```jsx function Child() { const [count, setCount] = useState(0); return

{count}

; } function Parent() { return ; } ``` ### 5. Stable Keys Matter in Dynamic Lists Prefer: ```jsx key={user.id} ``` rather than: ```jsx key={index} ``` when items can be inserted, removed, filtered, or reordered. Keys tell React which logical item should keep its identity. ### 6. Do Not Use Random Keys Avoid: ```jsx key={Math.random()} ``` because the key changes every render. Conceptually React sees: ```text old component disappeared new component appeared ``` which can cause unnecessary recreation and loss of local state. ### 7. Rendering Should Stay Pure Avoid performing side effects directly while rendering: ```jsx function Profile() { localStorage.setItem("visited", "true"); return

Profile

; } ``` Rendering should primarily calculate UI. User-triggered actions belong in event handlers, while synchronization with external systems may belong in Effects. ### 8. Do Not Confuse Reconciliation with Performance Memoization Reconciliation happens as part of React's normal update process. APIs such as: ```text memo useMemo useCallback ``` are performance tools that can sometimes reduce repeated work. They are not required for reconciliation to work correctly. ### 9. Do Not Depend on Exact Internal Diffing Implementation Application correctness should depend on React's documented concepts such as: ```text state props component identity keys rendering ``` not assumptions about undocumented implementation details. ### Practical Mental Model ```text State/props/context changes ↓ React renders ↓ Creates next UI description ↓ Reconciliation compares identity/structure ↓ Necessary changes identified ↓ Commit updates host DOM ``` ### Interview-Ready Answer The most important reconciliation rules are that rendering does not automatically mean DOM mutation, React preserves state based on component identity, element and component types matter, and keys provide identity among siblings. Stable component definitions and stable keys help React preserve the correct state, while changing type or key can intentionally create a new component identity.