Before or After the Screen Changes: Understanding Flush Timing in Vue Watchers

At some point, you write a watcher that looks completely reasonable.

It reacts to state.

It runs when something changes.

And yet… something feels off.

Maybe the DOM isn’t updated yet.

Maybe it updates twice.

Maybe something runs “too early” or “too late.”

It’s subtle.

And the reason sits in a place we rarely think about:

Not what runs—but when it runs.

Not All Reactions Happen at the Same Time

When you change state in Vue:

count.value++

It doesn’t immediately update everything.

Instead, Vue begins a process:

• mark components as needing updates
• schedule re-renders
• queue watchers

There’s a timeline forming behind the scenes.

And your watcher has to exist somewhere inside that timeline.

That “somewhere” is what Vue calls flush timing.

The Default: Before the World Updates

By default, watchers run with:

flush: 'pre'

Which means:

Run before the DOM updates

So the sequence becomes:

• state changes
• watcher runs
• DOM updates

At first, this feels natural.

You’re reacting to data, not the UI.

But there’s a deeper benefit here.

When you update other reactive state inside the watcher, Vue can batch everything together and render only once.

You’re not chasing the UI.

You’re preparing it.

When the DOM Matters More Than Data

Now consider a different situation.

You don’t just care about state.

You care about what’s already rendered.

watch(count, () => {
  console.log(el.value.offsetHeight)
}, { flush: 'post' })

Here, timing becomes critical.

Because if the watcher runs too early:

• the DOM still reflects the old state
• measurements are wrong

So Vue offers another position in the timeline:

flush: 'post'

Now the sequence becomes:

• state changes
• DOM updates
• watcher runs

You’re no longer preparing the UI.

You’re reacting to what already exists.

A Third Option: Ignore the Timeline

There is one more mode:

flush: 'sync'

This one doesn’t wait.

It doesn’t schedule.

It doesn’t batch.

It runs immediately.

The moment state changes, your watcher executes.

No queue.

No delay.

At first, this feels powerful.

But it comes with a cost.

You lose Vue’s optimization.

If something changes repeatedly, your watcher runs repeatedly—without mercy.

So this mode exists less as a default choice, and more as an escape hatch.

The Same Change, Different Worlds

Take a single update:

count.value++

Depending on flush timing, the world rearranges itself.

With pre:

• watcher runs
• then DOM updates

With post:

• DOM updates
• then watcher runs

With sync:

• watcher runs immediately
• DOM updates later

The same line of code.

Three different timelines.

Why This Distinction Exists

Because Vue separates two things:

• reactivity (data changes)
• rendering (DOM updates)

And once those are separate, timing becomes a real question.

Not everything should run at the same moment.

Some logic belongs before rendering.

Some belongs after.

Some bypasses the system entirely.

Choosing Without Memorizing

You don’t need to remember all the rules.

You can ask a simpler question.

If your logic depends on data:

Run before rendering → pre

If your logic depends on the DOM:

Run after rendering → post

If you need immediate execution and accept the cost:

Run instantly → sync

The choice isn’t technical.

It’s about what your logic cares about.

A Subtle Source of Bugs

Sometimes, watchers don’t behave strangely because they are wrong.

They behave strangely because they are early.

Or late.

A measurement happens before the DOM updates.

A state change triggers an extra render.

A side effect runs too often.

And the fix is not rewriting the logic—

but moving it to the right moment in time.

A Final Thought

Reactivity often feels like:

“When something changes, something else runs.”

But Vue is doing something more careful than that.

It’s not just deciding what should react.

It’s deciding when that reaction belongs.

And sometimes, that timing—

more than the logic itself—

is what makes everything finally make sense.