Explain render, commit, effects, and transitions

Use a small trace to show exactly how sync work, microtasks, timers, and render opportunities interact.

function traceRuntimeOrder() {
  const events: string[] = [];
  events.push('sync: render work starts');

  queueMicrotask(() => events.push('microtask: promise continuation'));
  Promise.resolve().then(() => events.push('microtask: resolved promise'));
  setTimeout(() => events.push('timer: later task'), 0);

  events.push('sync: render work ends');
  return events;
}

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

test('synchronous work finishes before queued microtasks', async () => {
  const events = traceRuntimeOrder();
  expect(events).toEqual(['sync: render work starts', 'sync: render work ends']);

  await Promise.resolve();
  expect(events).toContain('microtask: promise continuation');
  expect(events).not.toContain('timer: later task');
});

Mention when derived state belongs in render versus effect.

• Keep local, backend, wallet, chain, and user-visible state distinct.
• Name the product risk before naming the component.
• Tie the answer back to testing or rollout safety.

• Trace what happens when a user edits an amount, validation runs, and a non-urgent quote refresh starts.
• Use explicit ownership boundaries for state, data, and user intent.
• Describe how the UI prevents misleading certainty during pending or failed operations.

• Finance-grade UI should be conservative about certainty and optimistic about continuity.
• Local state improves recovery but must not pretend to be canonical business truth.

• Refresh during pending work.
• Duplicate user intent.
• Backend, wallet, and chain disagree temporarily.

• State transition test.
• Reload recovery scenario.
• Accessible status and copy review.

• What would you log for support?
• How would you roll this out behind a flag?