1. Treating Everything as Reactive
Vue's ref
is an excellent way to manage reactive state, but not everything should be reactive. When using Vue, developers often mistakenly treat all variables as reactive. For values that will remain static and never change, define them using const
. Reserve ref
or reactive
exclusively for state that truly needs to update the view.
Incorrect:
const createdBy = ref('JohnDoe'); // If username never changes, this is unnecessary.
Correct:
const createdBy = 'JohnDoe';
2. Using watch()
Without Understanding State Flow
It's easy to misuse watchers (watch()
) when you don’t fully grasp how your application's data flow works. Watchers can create hidden side-effects and subtle race conditions if logic is scattered and improperly managed.
❌
const comments = ref([]);
const article = ref({});
fetchArticle().then((data) => article.value = data.article);
watch(article, () => {
fetchComments(article.value.id).then((data) => { comments.value = data.comments });
});
✅
const comments = ref([]);
const article = ref({});
const fetchArticleAndComments = async () => {
const { article: articleData } = await fetchArticle();
article.value = articleData;
const { comments: commentsData } = await fetchComments(articleData.id);
comments.value = commentsData;
};
fetchArticleAndComments();
Use watchers only as escape hatches, not as the default approach.
3. Using v-if
Where v-show
Fits
Many Vue developers use v-if
unnecessarily. v-if
mounts and destroys elements or components, making it ideal for one-time, conditional rendering. However, frequent toggles should use v-show
, as it simply toggles CSS display, making it much more efficient.
Use v-show
when:
- Elements toggle frequently.
- The cost of mounting/destroying elements repeatedly is high.
❌
<div v-if="isVisible">Toggle me frequently!</div>
✅
<div v-show="isVisible">Toggle me frequently!</div>
4. Computed Properties Mutating State
Computed properties in Vue should always be pure and free from side effects. A common subtle mistake is directly mutating state within computed properties, especially with array methods like reverse()
or sort()
.
❌
const reversedNumbers = computed(() => numbers.reverse()) // This mutates the original array!
✅
const reversedNumbers = computed(() => [...numbers].reverse()) // Creates a new array, maintaining purity
5. Overusing Pinia/Vuex Store
State management libraries like Pinia or Vuex are powerful, but it's important not to overuse them. As Dan Abramov says, "Flux libraries are like glasses: you'll know when you need them."
Initially, manage state with props, emits, and local state. Consider using a store when you have deeply nested components or need shared state across multiple component branches. Excessive reliance on stores can lead to unintended complexity and side effects.
Guidelines for using a store wisely:
- Use local state or component props/emits first.
- Consider a store when dealing with shared state across unrelated components.
- Avoid overloading the store with local, component-specific state.
- Avoid circular dependencies - store A in store B and store B in store A
Thanks for reading
If you liked it leave some ❤️
Top comments (0)