,
22 tweets,
7 min read
Read on Twitter
A Vue.js project, just like any other piece of code, can get messy with time. Here's a short list of some common ways to deal with it, showing different options that often get discussed on chat.vuejs.org. This #vuejs best practice thread is inspired by @m9hmood.
Before we start, remember that verbosity is not necessarily a bad thing, it can help you and the others to see what's going on in the code. Don't try to abstract the boilerplate just because. Do so when you're sure it doesn't provide you an advantage in particular case.
Remember also that there's no clear set of ultimate best practices. Some of them are widely used across the community, some others are more of a matter of individual preferences. Stick to those that you personally feel make sense to you or can prove right in the long run.
If you want to keep your application more structured, check out the default structure of a @nuxt_js or @vuesion1 project or the vue-enterprise-boilerplate by @chrisvfritz. Browse the official styleguide in the docs too, as it comes with many good advices. github.com/chrisvfritz/vu…
You don't have to necessarily rewrite whole project from scratch. If possible, try to limit yourself to an internal refactor of the existing application, unless you want to make significant changes to the boilerplate itself, f.e. switch to @nuxt_js.
The best starting point is to make your main.js (or adequate file in your boilerplate of choice) clean - abstract all the plugins into separate files, leaving inside just the root Vue instance and the basic router or Vuex registration.
Rather than complicating your components folder structure, keep it as flat as possible (other than the router views) and differentiate them with filenames. This will not only let you take advantage of IDE search features, but also make it easier to refactor at a later point.
Stick to local component registration, perhaps making an exception for the most reusable, base components. It will help you with tracking your structure later and allow to use some performance optimizations such as lazy loading.
When refactoring, look for what can be made into its own components, functions or modules. Keep them short and if possible, reusable. A good example are wrapper components with a slot, holding HTML that's commonly used as a basic layout for a specific feature.
If you need more variations of your component, use slots rather then infinitely increasing the number of props. It may feel verbose at first, but it's also more flexible. @DamianDulisz provides a good tutorial on that, make sure to read it. dulisz.com/blog/composing…
If you pass countless events or props through more than 2-3 tree levels, write a reusable event handler or pass props as an object, so that you only have to validate them where needed or refactor it without affecting the whole hierarchy. v-bind="" and v-on="" are your friends.
If you keep using computed properties or methods with similar logic in a lot of components, abstract them. You can opt for:
- a standard JS helper kept in /utils
- a Vuex action
- a mixin
- a renderless component with scoped slot
- new composition API
- a standard JS helper kept in /utils
- a Vuex action
- a mixin
- a renderless component with scoped slot
- new composition API
Mixins are cool and easy, but they make it difficult to track where specific properties come from and how they're being used across the project, especially if you let them grow beyond measures. Use them with care and if you find yourself in a tricky situation, refactor.
Renderless or higher order components with scoped slots are cool too, but they won't allow you to use their data in the script. If you do need it, chose another option rather than passing the data through methods (it's still fine when you do it occasionally though).
If you use a lot of similar logic inside of one component and you feel it shouldn't be split, try making it a v-for loop, possibly iterating over an array of objects to keep track of some small variations. Just make sure not to end up with an even more messy structure.
If your v-for gets bulky and you end up passing the index or whole item objects to more and more methods to process the data, abstract it to a child component and make use of computed properties. Same if you have multiple nested v-for and each of them has its own logic.
If you find it difficult to track your global state or events and you use an event bus or root instance, go for Vuex. Keep related actions, state and getters in namespaced modules, but don't try to create a separate module for every small thing.
Don't be afraid to use Vuex getters for any values derived from the state. They can keep a lot of reusable logic that you'd otherwise have to store in the components as computed properties or methods anyways.
If your Vuex modules contain a lot of logic that can be reused, abstract it with reusable helper functions or write a Vuex plugin to dynamically generate the code. On the other hand, it can also be a sign that you've split your store to too many modules.
If (and only if) you feel that the mapping helpers that come with Vuex are a bother and force you to look up your Vuex structure too often, consider using a simplified solution like Vuex-Pathify by @dave_stewart. github.com/davestewart/vu…
It's up to you if you keep the client-server logic and data from the server at the components or Vuex level. In both cases, the most important is to keep your logic reusable. You can also give a try to one of libraries such as Vuex-ORM by @KiaKing85. github.com/vuex-orm/vuex-…
This is of course not a fully comprehensive resource - reach out to dedicated articles to know more and don't be afraid the experiment with your own patterns. Perhaps one day you'll find one of them mentioned in another thread like this one. Good luck!
