Render and commit in code
setOpen(true);
// React schedules a render, then commits the dialog to the DOM.Read the example from data and control flow to the resulting UI. Keep the component boundary small.
Back to week 1
Topic
Render and commit
Definition
React rendering calculates a new element tree; committing applies the necessary changes to the browser DOM.
In simpler words
React first figures out what the UI should be, then updates only the browser parts that changed.
Triggering updates, rendering, reconciliation, and commit work.
After this you can
- Explain why state changes do not mutate the DOM immediately in your function.
- Explain the trade-off to a teammate using a small example.
- Name at least one common bug pattern for this topic.
Understand Render and commit
Triggering updates, rendering, reconciliation, and commit work.
Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.
Apply Render and commit
Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.
Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.
Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?
Where bugs hide
Definition
High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.
In simpler words
Each mistake below shows Wrong vs Right code — compare them side by side.
When something misbehaves, match the symptom to a pattern below before rewriting the feature.
Prefer fixing the ownership or update path over adding another Effect or sync step.
Mistake: Read DOM right after setState
// Wrong
setOpen(true);
console.log(dialogRef.current); // still closed
// Right
useEffect(() => {
if (open) dialogRef.current?.focus();
}, [open]);Commit happens after the function returns — use an Effect for DOM after paint.
Mistake: Heavy work without measuring
// Wrong
// Premature memo on every child "for performance"
// Right
// Measure first; memoize the proven hot pathOptimize with evidence, not fear.
Mistake: Wrong Effect for layout measure
// Wrong
useEffect(() => measure()); // may flicker
// Right
useLayoutEffect(() => measure()); // before paint when neededLayout measurements sometimes need layout Effects.
Live playground
Render and commit sandbox
Change one input at a time and predict the next render.
setState schedules a render, then React commits DOM updates. The preview updates after the click handler finishes.
Panel is closed
setOpen(true); // 1) render calculates new tree // 2) commit applies DOM changes
Keep in mind
- Keep the formal definition in mind; it explains which tool belongs where.
- Prefer one source of truth over synchronized copies of the same value.
- When behavior surprises you, trace: input → update → render → committed UI.
- Study the Wrong vs Right examples in “Where bugs hide” before you merge.
Test
Check your understanding
At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥ 80% (enforced by the API) to save progress.
Checking your session…
10 questions · concept 3 · syntax 3 · practical 2 · logic 2