Common Mistakes in Vue js and How to Avoid Them - Daniel Kelly

Подписаться 9 тыс.

Просмотров 7 тыс.

50% 1

Building apps with Vue is a delight, but there are some common gotchas you should look out for! In this talk, let’s take a look at some common mistakes that lead to bugs, wasted time, and frustration for Vue.js developers. Topics include: - the v-for key attribute, - replacing reactive state the wrong way - failing to clean up event listeners - watching arrays the wrong way - Unintentionally mutating props - Deconstructing reactive objects - Using composables in the wrong place - and more! Many of these mistakes you’ve probably been guilty of yourself (I know I have!). Learn strategies for avoiding the same mistake twice. If you’re lucky enough not to have made some of these, definitely learn from my own mistakes and the mistakes of others from the community.

Опубликовано:

30 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 18

@apglazkov 2 месяца назад

20:37 - "Hydration mismatch" - even in a single file tutorial example 😅 If a developer can make a mistake so easily, it means there is something wrong with the platform itself. Meanwhile, Vue.js developers still can't stop smiling in all their videos, feigning happiness 😂 "This is fine" 🔥🐶🔥

@MrJloa Месяц назад

Just to point out. The most ugly thing done bad in vue3 is refs which reference the dom. I got no idea why evan made it so bad, whereas the perfect solution was so obvious -- just introduce $ref() for dom refs. Why? const foo = ref(null). What is foo at runtime? A number? Boolean? Collection? U never know. U need to check the template part to be sure. And if that's a dom element, u now can't use the name 'foo' coz it's reserved coz of the ref name. Looks like bs. A proper implementation would be: const notFoo = $ref('foo') const foo = ref(1) Now i see that notFoo is a dom reference, which references a ref=foo element, moreover that attribute doesn't pollute my code (doesn't restrict me from naming smth foo in my code) It seems like evan was drunk while he was implementing dom refs in vue3

@MrJloa Месяц назад

It gets even worse when u review a lot of code on the browser (gitlab/github). This really pisses me off. We even made conventions addressing this annoying vue3 thing. Btw vue2 had a much better implementation

@andredasilva6807 8 дней назад

whats the vscode theme? look great

@tropicaljupiter Месяц назад

I use reactive like const state = reactive({ thing1: ‘defaultValue’, thing2: -1 )}; In other words, I use it to group state together. Don’t show me 10 lines of individual refs for a small form, just make a reactive formState object.

@MrJloa Месяц назад

Yep. That's what i do. Always use reactive and make a context like reactive({ posts:[], pageId:1 }) U can now easily reassign posts, also u can pass around the reactive context and u don't have those zillions of refs defined and that crappy ".value" which just looks ugly af.😂

@dannjohnrem 2 месяца назад

Wow, you’re amazing! How can I be as incredible as you?

@Figurum 4 месяца назад

awesome🎉

@jored56 5 месяцев назад

In that last mutating props example, wouldn't _data be initialized only once, so once u pass that object up to the parent (and the parent doesn't clone it), you'll end up still mutating the same object? 23:59

@praveshishere 4 месяца назад

yes, _data would only be initialized once and in order to overcome that you would have to watch data prop and update _data correspondingly (which would also result in either losing all the changes child component made or patching those changes on the new data received from parent based on your design), when we emit _data to parent, if the parent has used a ref, it would be easily updated no issues with that, though I am not sure what would happen in case if was created using reactive (since I only use refs)