They say, "the more the merrier", and I like to be merry*, so here are some more tips.
* I'm sure you enjoy merriment as well.
* Also, not the hobbit.
— Michael
When a function does more than just return a value, it makes your code more complicated.
These are called side effects, and you should never have them inside of a computed prop:
export default {computed: {fullName() {this.fetchUserInformation(); // Side effectreturn `${this.firstName} ${this.lastName}`;},},};
However, fixing this is quite straightforward. We can just move that side effect into a watcher that is triggered whenever the computed prop updates:
export default {computed: {fullName() {return `${this.firstName} ${this.lastName}`;},},watch: {fullName() {this.fetchUserInformation(); // Side effect},},};
This applies equally to the composition API, although the syntax is slightly different.
At first glance, this may seem like we made the code more complicated. But actually, we've made it a lot simpler.
This concept is expanded on in my course, Clean Components.
The <picture>
element lets us provide many image options for the browser, which will then decide what the best choice is:
<picture><!-- You can have as many source tags as you want --><!-- (or none at all!) --><source srcset="big-image.png" media="(min-width: 1024px)"><source srcset="bigger-image.png" media="(min-width: 1440px)"><source srcset="biggest-image.png" media="(min-width: 2048px)"><!-- One img tag is required to actually display the image --><!-- and is used as the default choice --><img src="regular-image.png"></picture>
You can provide different options based on screen size, resolution, and supported image formats.
The mdn docs have a lot more info on this element.
It seems that every week there's a new JS framework, or a new and better way to write CSS (which is just the old way again).
Just as you get comfortable writing unit tests you learn that integration tests are actually the way to go. Oh, and the way you've been writing your tests is completely wrong.
Ugh 🤦‍♂️
It would be so much simpler if we could ignore everything, but hidden among all these new tools are amazing gems that can transform the way we work.
But keeping up with all of them is impossible.
That's why my long time friend, Anthony Gore (who also created Vue.js Developers), created DevTrends.io
He does all of the research on new tech and tools for you, and then teaches you the most important details in short, informative videos.
Click here to check out some recent videos
React has hooks, Vue has composables. It's a term you maybe haven't heard before, but composables are the functions built using the composition API.
It's not an "official" term, but most of the community has settled on using this term. This is how open source works, right?
In this article, Markus goes through some common patterns for building composables with the composition API.
Read it here: Vue Composition API: Composables
We have four incredible conferences coming up in the next 3 months, all accessible online and two offering (limited) in-person experiences:
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." — Tom Cargill
The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬
Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.
Named slots also have a shorthand syntax, one that's much nicer to look at.
Instead of writing this:
<DataTable><template v-slot:header><TableHeader /></template></DataTable>
We can write this:
<DataTable><template #header><TableHeader /></template></DataTable>
Not a huge difference, but a little cleaner for sure. I think the #
character is easier to pick out than v-slot
when reading code.
p.s. I also have two courses: Reusable Components and Clean Components