Open davidm-public opened 6 years ago
just looking in the codebase, basically you are using a Vue vm as a store, correct? if so, quality should be high, no?
Yeah, that's just how Vuex works.
Not sure if it's production ready since I haven't tried it in production
btw what changes do you want Vuex to make? maybe we can improve Vuex directly 😄
problems with Vuex:
1) way too much boilerplate. most of which seems to serve no purpose other than to comply with data binding abstractions de jeur (Flux, Elm, etc.).
2) not typesafe, too many strings, not easy to leverage Typescript.
3) critical bugs, unresolved for 3 years, e.g: 'Uncaught TypeError: Cannot read property 'getters' of undefined', see: e.g: https://github.com/vuejs/vuex/issues/264
4) problems with hot-reloading, especially with namespaced modules, probably related to #3 above.
Watching Evan's talk in Amsterdam this year, it's clear that Vue originated from the suggestion for single file components that I made on the Ractive project:
https://github.com/ractivejs/ractive/issues/366 https://github.com/ractivejs/ractive/issues/299
So I'm thinking maybe I should help contribute a better data binding abstraction, with these features:
1) type safety: maximal leverage of Typescript features. 2) simple 'getter' and 'setter' api, ideally using simple decorators on plain objects and/or classes. 3) class-based - should be posible to add a decorator to a class to make it reactive. 4) one-way synchronous data-binding as the default ('mutations'), 5) optional async with a simple decorator. 6) devtool compatible.
Probably the next step i'd take is to enumerate all of the reactive data-binding models and frameworks of relevance, see what's out there.
Not sure how you would like it, but this is my new idea for this library: https://github.com/egoist/zerotwo/pull/10
@egoist very nice, with one suggestion - see my comment in that issue. David
hi, really interesting project, wondering if it's production ready?