Skip to main content

Demo 50

MutationObserver timing

MutationObserver callbacks run before timers after DOM changes are observed.

fully simulatedcurated scenariodoes not execute real code
Short answer

The key output order is sync -> observer -> timer. Observer delivery is closer to microtask timing than timer timing.

Real-world bug this helps solve

A production symptom appears first: flaky tests, stale state, slow UI, late cleanup, or growing memory. This matters in component libraries, rich text editors, analytics trackers, test utilities, and DOM measurement code.

Common wrong assumption

Assuming DOM observers behave like setTimeout callbacks.

Fix direction

Fix the root scheduling, cleanup, or concurrency pattern instead of adding arbitrary waits.

Fixed code pattern
try {
  await operation();
} finally {
  cleanup();
}
Visual proof

The console lane proves the visible order: sync -> observer -> timer. The active line and queues show why source order changed.

How to verify in a real app

Reproduce the symptom with a small test, apply the safer pattern, then verify the flaky, slow, or leaking behavior disappears.

Share
Loading visual timeline...

Related cases

Continue with nearby confusion while the mental model is fresh.

Recommended next

Was this clear?

This stays local for now. It helps you track where the product still needs sharper cases.

Send detail