
VueJS – Two way data binding and state management with Vuex and strict mode - ypereirareis
https://ypereirareis.github.io/blog/2017/04/25/vuejs-two-way-data-binding-state-management-vuex-strict-mode/
======
teleclimber
> 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)

~~~
Fire-Dragon-DoL
I 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

------
IgorPartola
So just to be clear, you are not supposed to do two way data binding in a way
that would violate strict mode. Strict mode is a debug mode to help you catch
the errors that should not be there, whether it's on or off.

My preferred way to handle stuff like this is to have authoritative data in
Vuex (e.g.: a user object), and have a `formData` object attached to the Vue
instance. The `formData` will get modified directly with an `<input
v-model="formData.first_name">`, etc. and when the form's submit event fires
is when I tell Vuex to update the authoritative object.

The nice advantage of this method is that you can easily reset the form to its
initial values without having to store a copy of the original object. You also
don't update the authoritative object one field at a time, but all at once.
Lastly, it lets you do whole form validation (do the passwords match? Did the
user provide either a phone number or an email address, etc.)

~~~
scriptkiddy
That's exactly how I do it. Vuex makes this super simple due to the fact that
if you need the authoritative data in any component in the tree you can grab
it from the central store by using getters at negligible overhead.

Vue really got it right using the prototype extension model for plugins.

I use React+Redux at my day job and I have to say that it is an absolute pain
in the ass to do state management with Redux vs Vuex. Redux forces you to
split all of your logic out into separate tiny little functions and constants.
It even encourages you to split this all out into separate files.

Between the api functions, actions, reducers, connectors, routers, it all gets
very complex very quickly. The worst part is using `react-redux` and creating
connectors where I have to explicitly pass whatever actions and state I want
to use explicitly to a container where I need to propagate that state to a
component that's nested five levels deep. Then, if that component needs to
dispatch an action I have to propagate the event through 5 different callbacks
to get it back to the connected container. With Vuex, I can access the store
in any component in one line and dispatch actions to the store from any
component anywhere in the tree and rest easy knowing my component tree will
update with the data changes. I'm seriously considering starting a re-write in
Vue at this point because It's much easier to maintain and refactor.

~~~
acemarke
Hi. I'm a Redux maintainer. A few quick thoughts.

First, Redux does not _force_ you to split your logic up into "separate tiny
little functions". That's the _encouraged_ approach, but you are absolutely
free to structure your reducer logic any way you want. You may want to read
through the "Structuring Reducers" section I wrote for the docs:
[http://redux.js.org/docs/recipes/StructuringReducers.html](http://redux.js.org/docs/recipes/StructuringReducers.html)
.

Second, you _can_ manually write logic in each of your components to access
the Redux store via React context. However, the point of the React-Redux
`connect` function is to generate "container" components that manage that
store interaction logic for you, allowing you to focus on writing more
"presentational" components that simply receive functions and values as props.
You _can_ even directly import the store into your component files and
reference it directly, although that's discouraged for several reasons (per
the Redux FAQ at [http://redux.js.org/docs/faq/StoreSetup.html#store-setup-
mul...](http://redux.js.org/docs/faq/StoreSetup.html#store-setup-multiple-
stores) ).

Third, you shouldn't need to "propagate an event through 5 different
callbacks". One of the main points of Redux is that you can `connect()` _any_
component to give it access to the store. If a deeply nested component needs
to extract a couple values from the store, or dispatch an action, go ahead and
connect it - you don't have limit yourself to only a couple connected
components higher up in the tree (per
[http://redux.js.org/docs/faq/ReactRedux.html#react-
multiple-...](http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-
components) ).

Lemme toss out a few resources for you.

I keep a big list of links to high-quality tutorials and articles on React,
Redux, and related topics, at [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

Also, the Reactiflux chat channels on Discord are a great place to hang out,
ask questions, and learn. The invite link is at
[https://www.reactiflux.com](https://www.reactiflux.com) . Please feel free to
drop by and discuss any pain points or questions you have. I'm usually online
evenings US time, and there's always a bunch of people happy to discuss
things.

~~~
IgorPartola
Since you are here, would you mind doing a quick comparison between Redux and
Vuex? I settled on Vue/Vuex over React/Redux specifically because Redux seemed
to have more complexity when it came to mutations, promises, etc. Why did
Redux choose the path it did and what is the advantage of using it over Vuex
(of course other than the rendering libraries they work with respectively)?

~~~
acemarke
To be honest, I really haven't read up on Vue or Vuex at all, so I can't make
any good comparisons.

I _can_ say that I'm currently working on a blog post that will discuss what
actual technical limitations Redux requires (and where/why those limitations
exist), vs how Redux is _intended_ to be used, vs how it's _possible_ to use
Redux. I've been doing research for that post by reviewing many of the early
Redux issues and discussions, and will be including some of that info in my
post. Hoping to make progress on that post this weekend - if you're
interested, keep an eye on my blog at
[http://blog.isquaredsoftware.com](http://blog.isquaredsoftware.com) .

I did write a comment on Reddit yesterday where I pasted a quote of Redux's
stated objectives from an early version of the README, which may be
informative:
[https://www.reddit.com/r/javascript/comments/67gvic/i_just_d...](https://www.reddit.com/r/javascript/comments/67gvic/i_just_dont_get_what_is_worth_the_extra/dgqbhmb/)
.

In general, Dan and Andrew's primary goals were to enable time-travel
debugging, server rendering, and state traceability, as well as offering up
extension points so that developers could customize things like async behavior
for their own preferences. That led to the effective requirements of immutable
data handling, composed functions for organizing "write" logic, and the
creation of "middleware" as the preferred approach for implementing async
handling.

------
eweise
When people feel the need to write blog posts discussing the various
alternatives to binding data to a view, its probably a sign that the framework
didn't get it right.

~~~
wolco
Having multiple methods for data binding isn't a downside. Different
situations call for different approaches. Opinioned frameworks need to get it
right but Vue gives us the freedom to implement different approaches.

------
peter_retief
Could be useful in a dashboard with constantly changing data? I will
definitely check it out

