Editor’s note: This article was last reviewed and updated by David Omotayo in January 2025 to offer a brief comparison between the v-show
and v-if
directives, which you can read more about in our guide to conditional rendering in Vue, as well as to cover popular methods for watching route changes in the Composition API, such as the route watcher and navigation guard methods.
Vue is a versatile and incrementally adoptable JavaScript UI framework. With its distinctive architecture and reactivity system, Vue updates the DOM whenever the JavaScript state changes. However, in certain scenarios, this approach isn’t sufficient, and we need to re-render individual components.
In this article, we’ll review the practical use cases for forcing updates and some best practices for re-rendering Vue components efficiently and avoiding reloading the entire page. The following four basic practices apply to both Vue 2 and Vue 3. Let’s get started!
When should you force an update in Vue?
Sometimes, forcing an update in Vue is necessary to ensure the UI reflects the most recent data or state changes. While Vue’s reactivity system automatically updates the UI in most cases, there are specific scenarios where forcing an update becomes appropriate. Common use cases include:
External events
When you have components that rely on external events or changes that occur outside of Vue’s reactivity system, you may need to manually trigger an update. For example, if you have a component that listens for browser events like window resize, you may need to force an update to re-render the component based on the new dimensions.
Custom watchers
Vue provides watchers that you can use to monitor changes in data properties. If you have a custom watcher that performs some additional logic or has side effects, you may need to manually trigger an update when the watcher’s condition is met.
Third-party integration
When integrating with third-party libraries or plugins that directly manipulate the DOM, Vue’s reactivity system may fail to detect changes. In such cases, forcing an update can help ensure that the component reflects the correct state.
Dynamic styling
Vue’s reactivity system excels at handling dynamic data and updating the UI as needed. However, if you use dynamic styles on elements that rely on calculations, measurements, or other external factors, you may need to force an update to ensure that the styles are applied correctly.
Changes to non-reactive data
Vue’s reactivity system primarily monitors changes to reactive data properties. Vue will not detect changes to non-reactive data that affect the component’s rendering or behavior, like plain JavaScript objects or variables. In such cases, you may have to perform a manual update using forceUpdate
to reflect the changes, which we’ll cover later.
Performance optimization
Vue optimizes performance by updating only the necessary parts of the DOM through intelligent diffing and re-rendering. However, in certain complex scenarios, the automatic diffing algorithm may fail to detect changes accurately, resulting in incorrect rendering. Forcing an update in such cases can help ensure that the component is rendered correctly.
Legacy codebase
When integrating Vue with external libraries or legacy code that doesn’t play well with Vue’s reactivity system, you may encounter situations where changes made outside of Vue aren’t reflected in the UI. Forcing an update is a viable solution for synchronizing the component’s state with external changes.
Direct DOM manipulation
If you manipulate the DOM directly outside of Vue’s reactivity system, like with vanilla JavaScript or third-party libraries, Vue may be unaware of the changes. In such cases, forcing an update can assist Vue in recognizing and reflecting the UI changes.
Now that we understand the scenarios where forcing an update may be appropriate, let’s discuss four options for forcing a Vue component to re-render, comparing their pros and cons.
Hot reload
Hot reload involves more than just reloading a page whenever we update a file. When we modify a component in a *.vue
file with hot reload enabled, Vue will swap all instances of that component without refreshing the page. Therefore, it preserves the present state of our app as well as the swapped components, thereby improving the developer experience whenever you significantly modify the templates or styling of components.
Using hot reload
Whenever you scaffold a project with the Vue CLI, hot reload will be enabled out-of-the-box. Also, when you set up a new project manually, hot reload is enabled automatically when you serve your project with webpack-dev-server --hot
.
For advanced use cases, I recommend checking out vue-hot-reload-api, which is used internally by Vue Loader.
Disabling hot reload
Hot reload is always enabled automatically, except under the following circumstances:
- webpack
target
isnode
(SSR) - webpack minifies the codeprocess.env.NODE_ENV === ‘production’
To specifically disable hot reload, use the hotReload: false
option:
module: { rules: [ { test: /.vue$/, loader: 'vue-loader', options: { hotReload: false // disables Hot Reload } } ] }
State preservation rules
When re-rendering components, the hot reloading process follows a set of state preservation rules.
If you edit the <template>
of a component, instances of the edited component will re-render in place, maintaining all existing private states. This is made possible by combining templates to create new render functions with no side effects.
When a component’s <script>
section is changed, instances of the modified component will be destroyed and re-created in place. This is due to the possibility of side effects from lifecycle hooks in <script>
, necessitating a reload rather than a re-render to maintain consistency.
Therefore, one should exercise caution when using timers or other global side effects inside component lifecycle hooks. Sometimes, if a component has global side effects, we must reload the entire page.
Keep in mind that the application state is unaffected by <style>
hot reload because it runs independently via vue-style-loader
.
The Vue v-if
hack
The v-if
directive, which is included with the Vue library, only renders a component when a given condition is true
. If v-if
evaluates to false
, the component won’t appear in the DOM. Therefore, the creative use of the v-if
directive might be a better solution.
In this template, let’s set up a v-if
directive:
<template> <MyComponent v-if="renderComponent" /> </template>
In the script
section, we’ll add a method called forceRender
, which uses nextTick
, a utility for waiting for the next DOM update flush:
import { nextTick, ref } from 'vue'; const renderComponent = ref(true); const forceRender = async () => { // Here, we'll remove MyComponent renderComponent.value = false; // Then, wait for the change to get flushed to the DOM await nextTick(); // Add MyComponent back in renderComponent.value = true; };
In a scenario where we use the Options API instead of the Composition API, our script
will look more like the following code:
export default { data() { return { renderComponent: true, }; }, methods: { async forceRender() { // Remove MyComponent from the DOM this.renderComponent = false; // Then, wait for the change to get flushed to the DOM await this.$nextTick(); // Add MyComponent back in this.renderComponent = true; } } };
In the code snippet above, renderComponent
is initially set to true
, rendering MyComponent
. Whenever we call forceRender
, renderComponent
is set to false
. Doing so stops rendering MyComponent
because the v-if
directive now evaluates to false
.
Immediately after MyComponent
stops rendering, we wait for a tick and then set renderComponent
back to true
. This also sets the v-if
directive to true
, which renders a refreshed instance of MyComponent
.
Two elements are crucial to deciphering how nextTick()
operates. First, we must wait until the next tick, unless our updates to renderComponent
will cancel themselves out, and we won’t notice any changes.
In Vue, you can use nextTick()
immediately after a state change to wait for the DOM updates to complete. We can either pass a callback as an argument or await the returned promise.
Vue will destroy the previous component because it creates an entirely new component when we render it for the second time. As a result, our new MyComponent
will go through all of its typical lifecycles, created
, mounted
, and so on.
Comparing v-if
and v-show
directives
Vue.js’ flexibility in problem-solving might make it tempting to use the v-show
directive instead of v-if
; after all, they both conditionally render elements or components based on specific conditions. However, unlike v-if
, the v-show
directive does not entirely remove the element from the DOM. Instead, it toggles the element’s visibility using CSS properties, leaving the DOM structure intact.
As a result, Vue does not trigger a re-render because the component remains in the DOM and does not re-enter its lifecycle stages during state toggles. While this minimizes performance overhead, it can be a limitation in scenarios where a re-render or component refresh is necessary.
So, if you’re planning to use the conditional rendering hack to force a component to re-render, avoid using v-show
simply because it functions similarly to v-if
. Each directive has distinct use cases, and choosing the wrong directive might lead to unintended behavior.
For a detailed comparison and guidance on when to use each directive, check out our article on conditional rendering in Vue.js.
Vue’s built-in forceUpdate
method
As recommended by the official Vue documentation, the built-in forceUpdate
method is one of the best ways to manually update a component.
Typically, Vue will update the view in response to changes in dependencies. Even though none of the dependencies have changed, we can still force that update to happen by calling the forceUpdate
method, which forces the component instance to re-render.
However, this defeats the purpose of the entire reactivity system; therefore, it is not suggested as a fix in these situations. We mistakenly believe that Vue will respond to changes to a particular property or variable, but that isn’t always how the reactivity system works.
The code below demonstrates how to call the forceUpdate
method using the Vue Options API:
export default { methods: { ForcesUpdateComponent() { // our code this.$forceUpdate(); // Notice we have to use a $ here // our code } } }
This method only exists on the component instance, so we need to get a bit creative to call it using Vue 3’s Composition API:
import { getCurrentInstance } from 'vue'; const methodThatForcesUpdate = () => { // our code const instance = getCurrentInstance(); instance.proxy.forceUpdate(); // our code };
The only case where we may want to use the forceUpdate
method is when we have explicitly created a non-reactive component state using advanced reactivity APIs. However, given Vue’s fully automatic reactivity system, this is optional.
The key-changing technique
Using the key-changing technique, we provide a key
attribute to inform Vue that a particular component is connected to a particular piece of data. If the key
remains the same, the component won’t change. But, if the key
changes, Vue understands that it needs to delete the previous component and generate a new one.
Why does Vue require a key
?
Let’s delve further into what a key
attribute does specifically and why we need it. Let’s assume we’re rendering a list of components that includes one or more of the following:
- A local state
- An initialization process, either with Vue 3’s
setup
function or in thecreated
andmounted
hooks when using the Options API - Non-reactive DOM manipulation achieved through jQuery or Vanilla APIs
When sorting or updating that list, we don’t want to re-render everything on the list; we only want to re-render the parts of the list that we updated. To achieve this, we’ll provide a key
property to help Vue keep track of what has changed and what hasn’t. Since the index of an array is unrelated to specific items on our list, using it in this situation wouldn’t do anything.
The key-changing technique is considered the best way to force Vue to re-render a component. Below is a fundamental way to illustrate it:
<template> <MyComponent :key="componentKey" /> </template> <script> import { ref } from 'vue'; const componentKey = ref(0); const forceRender = () => { componentKey.value += 1; }; </script>
In the code snippet above, we’ll add a key
attribute to MyComponent
, and then change that key
whenever we need MyComponent
to be re-rendered.
Using the Options API instead of Vue 3 or the Composition API, it’ll look like the following:
export default { data() { return { componentKey: 0, }; }, methods: { forceRender() { this.componentKey += 1; } } }
Whenever forceRender
is called, the value of componentKey
will change. When this occurs, Vue will be aware that it must destroy the component and initialize a new one. We’ll also end up with a child component that will reset its state and re-initialize itself.
Route change method
When a route changes in Vue, components associated with that route are naturally re-rendered. However, due to Vue’s optimization and reuse of component instances, the component’s data might not update as expected.
Now, you can use any of the solutions we’ve discussed previously to force the update, but if you only want the component to update during route changes, you can monitor and respond to those changes directly.
There are several ways to watch route changes in both the Options API and the Composition API. However, the most commonly used and well-documented methods are:
- Watcher (
$route
watcher) - Navigation guard (
beforeRouteUpdate
)
While the navigation guard method offers more control over the navigation flow and is better for complex dependencies, the watcher method offers a simpler approach, which is enough for our use case.
Route watcher
The watcher method uses Vue’s reactivity system to observe the route
object or a specific route parameter for changes. When the watched property changes, Vue triggers the watcher function, and provides it with the new and old route values as arguments:
export default { watch: { // Watch entire route object '$route'(to, from) { // Triggers on any route change }, // Watch specific route parameter '$route.params.id'(newId, oldId) { // Triggers only when route parameter 'id' changes }, }, }
Using this approach, you can implement either the forceUpdate
or key-changing methods discussed earlier to re-render the component during route changes as demonstrated in the code below:
// UserDashboard.vue export default { data() { return { refreshKey: 0, } }, // Watch for route changes watch: { '$route'(to, from) { // Increment key to force re-render this.refreshKey += 1; }, // Watch specific route parameter '$route.params.id'(newId, oldId) { // Force update this.$forceUpdate(); }, { } <template> <MyComponent :key="refreshKey" /> </template>
Watching routes in the Composition API
Similar to the $forceUpdate
method, the $route
object is also tied to the component instance. Therefore, watching routes in Vue 3’s Composition API would be slightly different:
import { ref, watch, getCurrentInstance } from 'vue' import { useRoute } from 'vue-router' // Initialize router hooks const route = useRoute() // Component instance to access $forceUpdate const instance = getCurrentInstance() // Reactive state const refreshKey = ref(0) // Watch the route object watch(route, (to, from) => { // Increment key to force re-render refreshKey.value++ // using the Force update method instance.proxy.$forceUpdate() }) // Watch specific route parameter watch( () => route.params.userId, (newId, oldId) => { if (newId !== oldId) { refreshKey.value++ } } )
In this code, we use:
- The
useRoute
Hook fromvue-router
to access the current route - The
getCurrentInstance()
method to get the component’s instance and access$forceUpdate
- The
watch
function from Vue to observe changes in the route object
Note: As emphasized earlier, the forceUpdate
method is optional and primarily intended for use with non-reactive components. It’s recommended to prioritize the key-changing method for forcing re-renders. This approach is generally more efficient and aligns better with Vue’s reactive principles.
Conclusion
Ideally, we should be able to utilize Vue’s robust reactivity system, but there are instances where we must force a component to re-render to complete the task at hand.
In this article, we covered four different ways to force a Vue component to re-render, including hot reload, the v-if
hack, the forceUpdate
method, and finally, the key-changing technique. The right one will ultimately depend on the situation you find yourself in, but the key-changing technique is usually a safe bet.
If you have to manually force an update, you should do so sparingly and carefully because Vue’s reactivity system is designed to automatically handle most scenarios. I’d recommend that you take advantage of Vue’s reactive nature and rely on its built-in mechanisms rather than relying on manual updates whenever possible.
I hope you enjoyed this article! Be sure to leave a comment if you have any questions. Happy coding!
The post How to correctly force a Vue component to re-render appeared first on LogRocket Blog.
Source: Read More