Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

if this means no more Vuex, i'm all for that. that extra abstraction layer never proved useful to me.


Out of curiosity, how do you handle data needed by tons of components at different tree depths (info about the current user for example)?

I don’t always reach for Vuex, but when an app reaches a certain size it sure beats passing every bit of common data down through the entire tree, as I find you quickly hit a point where you’re passing data to components solely so it can pass it to it’s children.


It's funny I still have never really understood the case for Vuex. So far I have built decent complexity apps just by having a global reactive object that all components link to directly in their Vue data and I have yet to hit a problem. I see huge writeups and design patterns all suggesting I really need to use a state management library and I'm waiting for the day the penny drops and I realise what a mistake I've made but so far everything just keeps rocking along .... what am I missing?

(I get that there are some nice features like time travel debugging etc but none of them seem outweigh the giant additional complexity of routing every single state change through 1-2 extra layers.)


Not sure about Vue 3, but in Vue 2 you can simply use a Vue instance without a template as a reactive store. You can also share an object between Vue instances.

See: https://vuejs.org/v2/guide/state-management.html


Since the reactivity api is exposed it's very easy to write a file to hold whatever state you want.

Benefits: easy to create, type safety is simple.

Drawbacks: you don't get a serializable state log for free (that can be recorded and replayed when hitting bugs).


Vuex is still around. They just haven't finished integrating it into Vue Dev Tools, yet.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: