We don’t need to know every intrinsic detail, who has time for that? Maybe if we worked for a company that gave us 20% off to work on self-learning. If you have any suggestions or questions to make this better let me know, or if I messed up on something or something has changed which never happens in development, am I right?
I’m for hire, if you know anyone who needs a full stack developer with 8 years experience using laravel, 2+years on vue, send them my way! Currently I’m learning GraphQL(Hasura), and React Native Web trying to replace backend w/ a postgres database schema for rapid development. Resume | Github | Email
Tip#1: Nested objects are NOT reactive (by default).
That method looks like it should work, say you have an input that matches somevar.level1.level2.level3, if you ran this method it would not update the model. Instead you need to use Vue.set or in a SPC (Single Page Component) you’d just use this.$set. See the syntax below:
Tip#2: Learn and use Vuex from the start
This could start a flame war, some Vue aficionado's will tell you to start with an event bus and work your way up, but Vuex is modular enough that you can use it on small and large apps alike. If you’re building a single page application there’s no chance you’ll have fun without Vuex, you’re going to be trying to implement a lot of the same functionality in your event bus, and making any other developer who works on the project’s life a living hell.
A good primer on vuex can be found here: WTF is Vuex? A Beginner’s Guide To Vue’s Application Data Store
Someone mentioned that I should have more detail on this one, so here’s my take.
What is Vuex?
Vuex is basically a single source of truth for data. If you’re building a single page application for instance you might have a list of users, or recipes, and different scenarios might update that list, like adding a new recipe then fetching the updated list. Keeping track of changes across multiple tabs and/or pages can get complicated especially if there’s no refresh (where a lot of data initially is fed into an app).
Vuex makes it so every time something updates, you can update it at a core location, basically the data is central to all other things going on, on the page.
There are two other ways to do this, one is an event bus. An event bus is essentially a separate Vue instance that all other components pass messages back and forth to. This basically notifies them of changes, then your components listen to changes on this bus, and act accordingly when an event that affects it is triggered.
It works well enough, but it can become hard to manage, and I’ve found myself trying to be clever with event buses, and by the end of the project I’ve swapped it out completely for vuex.
So that’s my take on what and why you’d want to use vuex, I won’t go into how to implement a Vuex store, but I will say you might also want to look into one of the vuex-persistence modules out there, this will save your state if the page refreshes or gets disconnected or anything. It just saves it all to local storage.
Tip#3: When in doubt, re-render.
Here’s a simple use case, say you have an order form that pops up. If for some reason the user closes the order form and reopens it you might find some of the fields won’t allow edits, or they have stale data, or if you’re triggering the popup via a select box it might not work right. Honestly it’s a major headache.
One trick is to re-render your components. The easiest method I’ve found to do that is whenever a modal or some other component is registered on the DOM pass it a key, or on mount make it generate a random one. A good key could just be to generate a UTC timestamp and use that, as that would be unique in most cases, or you can just have a key that autoincrements whenever it’s called via a computer or watcher.
The key tells Vue that this is a NEW instance, forget about the old one, trash and regrab all the data associated with it, and let’s rerender in case any data is still controlling things.
Tip#4: Don’t use a watcher until you can explain in detail the difference between a watcher and a computed property.
Watchers and computed props are very important and needed in the common Vue.js developers workflow, but if you use them incorrectly you’ll run into headaches.
Nine times out of ten a computed property is what you REALLY want and if you’re not sure, you should probably try to devise a way to make a computed property instead of watcher.
Tip #5: Learn the difference between props and data.
Essentially a prop is data that you pass INTO the component from a parent component or on initializing the root component for the first time.
Data is the reactive properties defined on the instance. I find it to be a good practice if you ever think you’ll need to update the value or use it re-actively to create a new value on mount that is a duplicate of the prop. So say you have a prop called colorProp, you might have value in data called just color, then in your mount() method have this.color set to colorProp.
Tip #6: Have a plan for loading elements.
You may start out just letting users wait without knowing what’s going on but this is going to get dirty fast. Especially when you bring Vuex and multiple data points into the mix. It’s best to have a single global ‘loader’ setup that triggers whenever the global ‘loading’ property from Vuex is updated. This way you can always toggle it properly and make sure to un-toggle it.
One caveat is though — be sure you catch all errors — especially when using axios and promises and be sure to end the loading message on errors so users can go back, fix things and resubmit the form.
Tip #7: Use filters for common to reuse format methods.
See the example below:
The above example works great on something small, but why not make it a global filter? See below:
These are just a few common Vue.js pitfalls I’ve been met with along my journey, I’m sure there are others. Is there something I forgot that I should add to the list? Please share in the comments!