VueJS cheat sheet
medium.com
VueJS cheat sheet
1–10 of 13 posts
Re: VueJS cheat sheet
#2Consider contributing this to https://learnxinyminutes.com
Re: VueJS cheat sheet
#3Yikes, stay away from directives if it's possible unless you really need that functionality. I wouldn't add that as a `cheat sheet` as that should be a rare use case / component extension.
Re: VueJS cheat sheet
#4Yikes, stay away from directives if it's possible unless you really need that functionality. I wouldn't add that as a `cheat sheet` as that should be a rare use case / component extension.
i’m currently learning vue : why do you recommend not using things like v-if ? what do you use instead ?
Re: VueJS cheat sheet
#5Yikes, stay away from directives if it's possible unless you really need that functionality. I wouldn't add that as a `cheat sheet` as that should be a rare use case / component extension.
Directives like "v-if" and "v-model" are core to Vue and used regularly in every Vue project I've seen. What's your reasoning for avoiding them and what would you use instead?
Re: VueJS cheat sheet
#6Hard to represent certain ideas in a cheat sheet.
One thing I saw was showing how on a button click you can pass an object as an argument. I’ve personally trended away from that pattern and towards always avoiding method calls with arguments in template code. This means creating a sub component which takes in the object in question.
One ends up with a lot more components, but code is really well isolated and it’s incredibly easy to reason about what’s happening.
Re: VueJS cheat sheet
#7Hard to represent certain ideas in a cheat sheet. One thing I saw was showing how on a button click you can pass an object as an argument. I’ve personally trended away from that pattern and towards always avoiding method calls with arguments in template code. This means creating a sub component which takes in the object in question. One ends up with a lot more components, but code is really well isolated and it’s inc…
I built my first site in Vue over the past few weeks and found myself with the same conclusion. But I had to build it the "wrong" way first before I realized how much easier the code is to write using the sub-components.
Re: VueJS cheat sheet
#8Hard to represent certain ideas in a cheat sheet. One thing I saw was showing how on a button click you can pass an object as an argument. I’ve personally trended away from that pattern and towards always avoiding method calls with arguments in template code. This means creating a sub component which takes in the object in question. One ends up with a lot more components, but code is really well isolated and it’s inc…
I'm having a hard time wrapping my head around the problem. Could you elaborate with some examples of how it looks before and afterwards? Wondering whether I'm doing this stuff for my own projects.
Re: VueJS cheat sheet
#9Yikes, stay away from directives if it's possible unless you really need that functionality. I wouldn't add that as a `cheat sheet` as that should be a rare use case / component extension.
Directives like "v-if" and "v-model" are core to Vue and used regularly in every Vue project I've seen. What's your reasoning for avoiding them and what would you use instead?
Ah, let me clarify. I meant creating new directives. Using the core directives is needed the best use of Vue directives. Creating new ones should be used sparsely as it obfuscates your code.
We have 1 directive in our entire application and it's pretty complicated however the use of it is pretty amazing it allows our app to have a straight forward approach to permission allowing to hide/disable elements with good performance.
Honestly I must be super tired since I just re-read it and I see that it's using existing directives instead of creating new ones...
Re: VueJS cheat sheet
#10Hard to represent certain ideas in a cheat sheet. One thing I saw was showing how on a button click you can pass an object as an argument. I’ve personally trended away from that pattern and towards always avoiding method calls with arguments in template code. This means creating a sub component which takes in the object in question. One ends up with a lot more components, but code is really well isolated and it’s inc…
I'm having a hard time wrapping my head around the problem. Could you elaborate with some examples of how it looks before and afterwards? Wondering whether I'm doing this stuff for my own projects.
I put all the code in a single gist to make it easier to reason. This example (b/c it's basic) looks like more-code that's just generally unnecessary. In practice though, I've found those-sub components, even when it's just a button, tend to benefit from splitting out. You end up doing some styling to them, having them inherit from a parent button component, etc.
https://gist.github.com/wjossey/0d7ca1a3c2040e1c376a914941b8...