Differences in Vuex and Redux immutability approaches

Question

Having played with Vuex and realized how easy it is to mutate states through mutation handler with simple assignment, I am working with redux right now and learned that redux stresses on immutability but it makes coding slightly more verbose. The question now arises,

1. why does redux stress on immutability but vuex does not?
2. why does redux seem more popular even though you can do the same thing with vuex with much, much simpler coding?
3. What is the pros and cons of these two different approach?

Surprisingly there is no information I can find on this over internet.

Answer 1

To answer the questions you need to know how they both work. Veux has a state that is an observable/reactive so setting state.something will trigger anything watching state.something.

Redux state is a "normal" javascript data object (no methods on the object and no prototype should be used). When an action is dispatched then a new state is created by redux and react-redux will run all the mapStateToProps or useSelector functions and compare the current result with the last one (using referential compare so {} !== {}. If there is a change then react-redux will re render that component.

To now answer your questions:

1. Veux state is not just an object and a lot of listeners are added to state so when you do state.newValue='new value' it'll trigger all these listeners. Redux needs to compare previous value with current and the most performant way to do it is referential compare. Therefore you have to generate a new state where all unchanged props still point to the same reference as before but changed props point to another reference.

2. React/Redux uses a functional approach and vue/veux an OO approach. Why it's popular may be because React Redux existed longer and has a better supported ecosystem. Functional programming has become more popular lately because even after decades of trying it's still very hard to write good code in OO (concurrency). The best Uncle Bob can come up with is "A class should have only one reason to change." and written according to that rule you'll end up with a class that has only method which could be done with a function. A problem with combining related data and behavior in a class is that later this relation may change later or you've find that the way you related them does not reflect what needs to be implemented in the real world.

3. They are both difficult to learn and do well, I find redux way easier to follow and predict what happens in complicated code bases (complex requirements, not needless complexity) and way easier to test but in the end it's just a personal preference.