Vue nextTick Explained: How DOM Updates Are Batched

You click a button. It increments a ref. On the very next line, you read the element that's supposed to show that number — and it still says the old value. You didn't await anything wrong. You didn't forget a .value. Vue's reactivity did exactly what it was supposed to do, and the DOM is still lying to you for a few more microseconds.

That gap between the data changed and the DOM caught up is not a bug to work around — it's a deliberate design decision, and understanding it explains a whole category of "why isn't my DOM updated yet" questions that nextTick() exists to answer.

This is the second episode of Vue Deep Dive. The first one covered how Vue tracks a dependency when an effect reads a reactive property. This one picks up exactly where that left off: once a dependency changes, what does Vue actually do with it, and when?

By the end of this article you'll be able to:

You've built Vue components with <script setup> and used ref(), watch(), or watchEffect(). You don't need to know how the scheduler is implemented — we'll build the mental model from the read-time subscription this series already covered.

This article is written against Vue 3.5.x (verified August 2026; Vue 3.6 is in release candidate as this goes out, and the scheduling behavior described here is the stable, documented one).

Here's the naive version — the one that looks like it should obviously work:

The push happens. items.value really does have three elements the instant push returns — that part is ordinary, synchronous JavaScript. But document.querySelector('li:last-child') still finds the old last <li>, because the new one hasn't been rendered yet. Scroll to a list of two items and this either scrolls to the wrong element or, on an empty list, returns null and throws.

The usual first fix is a setTimeout:

It "works" — most of the time, on most machines, which is exactly what makes it a bad fix. It's a delay chosen by superstition, not by a guarantee. Understanding why the DOM was stale tells you the actual guarantee to wait for.

A write to reactive state doesn't update the DOM. It marks a render job dirty and adds it to a queue. Vue flushes that queue once, on a microtask — after your current synchronous code finishes, and before the browser paints.

Walk through what actually happens when items.value.push('c') runs:

Key concept: "the effect ran" and "you read the result" are two different events, separated by a microtask boundary you have to explicitly wait past.

This is not laziness on Vue's part — it's the entire point. If Vue re-rendered synchronously on every single reactive write, changing ten properties in one function would trigger ten renders. Batching collapses that into one.

Here's a watchEffect standing in for "a render" — it reads a ref, so it depends on it, and it prints every time it runs:

Five writes to count, all synchronous, no await between them. If Vue reacted per write, runs would be 5 by the time the loop finished — but the loop finishes before the microtask queue gets a turn, so none of the five writes have caused a re-run yet. Once the flush does happen, it happens exactly once, because the second, third, fourth, and fifth writes just re-mark the same already-queued job dirty. There's one job per effect per flush cycle, not one job per write.

Key concept: batching isn't about which writes "count" — every one of them lands in the data. It's about deduping how many times the effect reruns per flush.

The interactive playground below runs this exact experiment against the real Vue runtime, plus the DOM-read-timing experiment from the previous section — you can watch the effect count stay at 1 no matter how many synchronous writes you make.

nextTick() is how you wait for the flush explicitly instead of guessing with a timer:

nextTick() returns a promise. Awaiting it doesn't add an arbitrary delay — it resolves at the specific point where Vue's own pending flush has run, so every write made before the call is guaranteed to be reflected in the DOM by the time execution continues. That's a real contract, not a best guess about how long a render "usually" takes.

It also accepts an old-style callback, if you're not in an async context:

Both forms wait for the same thing. The promise form composes better with the rest of modern async code, so prefer it in <script setup>.

watch() and watchEffect() take a flush option that decides when relative to the component's own DOM update their callback runs. There are three values, and the middle one is the default:

{ flush: 'post' } here is doing the same job await nextTick() does inline — it's the declarative version, for when the "wait for the DOM" logic belongs inside a watcher rather than an event handler.

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

Because the write queues a render job instead of running it synchronously. Vue flushes the queue on a microtask, which runs only after your current synchronous code finishes — so code on the next line still sees the pre-update DOM.

No. nextTick is backed by the microtask queue, which the browser drains before it paints and before it processes timers. setTimeout(fn, 0) runs later, after at least one paint, and isn't a documented contract about when Vue's flush completes — it usually works by coincidence, not by guarantee.

No. Vue batches: multiple synchronous writes to the same or different pieces of state before the next flush collapse into one render pass, not one per write.

Not for that specific update — { flush: 'post' } gives the watcher the same "DOM is current" guarantee await nextTick() gives inline code. Use whichever fits the shape of the logic: a watcher for "whenever this changes," nextTick for "right after this one action."

No. It resolves once the DOM has the updated content, not once any transition or animation on it has visually completed. For "after the transition," listen for the transition's own end event.

The <li> you couldn't find with document.querySelector right after push() wasn't missing — it just hadn't been built yet. The array had already changed; the render job for it was sitting in a queue, one microtask away from running. await nextTick() is the line that waits for that queue to empty before you touch the DOM again.

Once you see the write and the paint as two separate, queued events instead of one instantaneous one, "why isn't the DOM updated yet" stops being mysterious — it's just a question of which side of the flush your code is running on.

Have you shipped a setTimeout(fn, 0) to work around this before you knew what nextTick actually guaranteed? What finally made the batching click for you?

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected: