5 ms·
> Two way data binding [...] is a very good option for small applications or POC. But for very complex UI you should consider using one way data binding and exp
by teleclimber 9y ago
> Two way data binding [...] is a very good option for small applications or POC. But for very complex UI you should consider using one way data binding and explicit state updates/mutations.
I don't agree with this. Two-way data binding is a powerful tool that can make composing components very effective when used correctly in any size application.
If you have a number of custom generic input components (sliders, color pickers, value inputs with popup sliders, etc...). Being able to compose them into a custom ui just by binding with v-model is remarkably efficient for the developer.
Having said that this is only good when you compose dumb or generic inputs. Once you are in a component that is a bit more high level then yes, absolutely Vuex is the right way to manage your state.
The problem is that to bind components with v-model you have to deep-clone your data, and watch it. This is far from ideal. I raised an issue related to this because I think Vue is kind of missing something here.
https://github.com/vuejs/vue/issues/4373 https://github.com/vuejs/vue/issues/4373
- vyrotek 9y agoDoes v2.3 bringing back sync help with any of these concerns? https://github.com/vuejs/vue/releases/tag/v2.3.0 https://github.com/vuejs/vue/releases/tag/v2.3.0
- Fire-Dragon-DoL 9y agoI work with angular and I'm scared badly of two-way data binding. I moved it to only work with simple fields as you described, but even in that case ended up being a problem. Once the bug was detected, in the end you need some kind of local variable (local to the component) to avoid the two-way data binding change causing weird behavior outside (things change from down to up, urgh.) Be careful, long term two way databinding bites badly. The best idea is still a simple event when the value change, and trigger the change from top to bottom, not bottom-top