4 ms·

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

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 10y ago
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.
- ng12 10y ago
  You can do that in Redux. Just put your store somewhere you can import it or write a little utility so each component is connected to the entire state. The reason people don't is to keep them honest about abstraction layers, separation of concerns, and reusability.
  - scriptkiddy 10y ago
    I've thought about doing that. However, it doesn't really seem to play well with React's architecture. For instance, React does not have any built in support for computed properties. Therefore, if I am returning data from the central store through a function on a component that calls a getter from the store, the component will not update if the central state changes during the component's life cycle. Of course I could write a polling function or some sort of watcher method that binds the computed properties to component state, but that sounds like a mess. At a certain point after trying to get React to act more like like Vue, I have to ask myself why I'm not just using Vue in the first place. Regarding you statement about abstraction layers, separation of concerns, and re-usability: If I want a generic and re-usable component I just won't give it any data state. It may have local presentation state, but all data will be passed to it from a parent. Any operations the component allows will simply emit events. Both Vue and React are equally suitable for this and I have no complaints about either for generic components. I'm not sure how being able to read central state in any component violates separation of concerns, however. The store is still handing all mutations to application state in Redux or Vuex. The difference with Vuex is that You do not need to have a chain of callbacks for dispatching actions, you do not need "connected containers", and you do not need to pass state through components in a tree that do not require that state. For instance, say I have a user profile page. This page displays user information received from a REST detail endpoint. Simple enough, right? I just have a `UserProfileContainer` where I define functions for fetching the user object from the API and then getters for retrieving that state. Now, I decide that I want to display a user's recent activities in a feed on the same page. Do I add to my `UserProfileContainer` to pass state down to the new feed component and it's children, or do I define the feed component as a new container? Or, do I define an intermediary `UserProfileLayout` component that is not a container and handles delegating state passed to it from the `UserProfileContainer`? If I do that I am passing application state through a component that has no use for it and I have to define an addional callback to propagate the event back to `UserProfileContainer`. Or maybe I should use `UserProfileContainer` itself to delegate state to the `UserInfo` and `UserFeed` components? How you compose this theoretical interface is probably defined by the structure of the rest of the application. I'm simply stating the Redux becomes more and more difficult to work with as the depth of component nesting increases.

scriptkiddy 10y ago

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.

ng12 10y ago
You can do that in Redux. Just put your store somewhere you can import it or write a little utility so each component is connected to the entire state. The reason people don't is to keep them honest about abstraction layers, separation of concerns, and reusability.
- scriptkiddy 10y ago
  I've thought about doing that. However, it doesn't really seem to play well with React's architecture. For instance, React does not have any built in support for computed properties. Therefore, if I am returning data from the central store through a function on a component that calls a getter from the store, the component will not update if the central state changes during the component's life cycle. Of course I could write a polling function or some sort of watcher method that binds the computed properties to component state, but that sounds like a mess. At a certain point after trying to get React to act more like like Vue, I have to ask myself why I'm not just using Vue in the first place. Regarding you statement about abstraction layers, separation of concerns, and re-usability: If I want a generic and re-usable component I just won't give it any data state. It may have local presentation state, but all data will be passed to it from a parent. Any operations the component allows will simply emit events. Both Vue and React are equally suitable for this and I have no complaints about either for generic components. I'm not sure how being able to read central state in any component violates separation of concerns, however. The store is still handing all mutations to application state in Redux or Vuex. The difference with Vuex is that You do not need to have a chain of callbacks for dispatching actions, you do not need "connected containers", and you do not need to pass state through components in a tree that do not require that state. For instance, say I have a user profile page. This page displays user information received from a REST detail endpoint. Simple enough, right? I just have a `UserProfileContainer` where I define functions for fetching the user object from the API and then getters for retrieving that state. Now, I decide that I want to display a user's recent activities in a feed on the same page. Do I add to my `UserProfileContainer` to pass state down to the new feed component and it's children, or do I define the feed component as a new container? Or, do I define an intermediary `UserProfileLayout` component that is not a container and handles delegating state passed to it from the `UserProfileContainer`? If I do that I am passing application state through a component that has no use for it and I have to define an addional callback to propagate the event back to `UserProfileContainer`. Or maybe I should use `UserProfileContainer` itself to delegate state to the `UserInfo` and `UserFeed` components? How you compose this theoretical interface is probably defined by the structure of the rest of the application. I'm simply stating the Redux becomes more and more difficult to work with as the depth of component nesting increases.