Why should objects in Redux be immutable? I know that some frameworks such as Angular2 will use onPush and can take advantage of immutability to compare states of views for faster rendering, but I am wondering if there are other reasons as Redux is framework agnostic and yet it mentions within its own docs to use immutability (regardless of the framework).
Appreciate any feedback.
Thread safety Immutable objects can be useful in multi-threaded applications. Multiple threads can act on data represented by immutable objects without concern of the data being changed by other threads. Immutable objects are therefore considered more thread-safe than mutable objects.
In React, using an Immutable state enables quick and cheap comparison of the state tree before and after a change. As a result, each component decides whether to re-rendered or not before performing any costly DOM operations.
2. What's an Immutable Object? An immutable object is an object whose internal state remains constant after it has been entirely created. This means that the public API of an immutable object guarantees us that it will behave in the same way during its whole lifetime.
The main reason Redux is using immutability is that it doesn't have to traverse an object tree to check for the changes in every key value. Instead, it will only check the object's reference is changed or not in order to update DOM on state change.
Redux is a small library that represents state as (immutable) objects. And new states by passing the current state through pure functions to create an entirely new object/application states.
If your eyes-glazed over there don't worry. To sum up, Redux does not represent changes in your application's state by modifying objects ( as you would with object-oriented paradigms). Instead state changes are represented as the difference between the input object and the output object (var output = reducer(input)
). If you mutate either input
or output
you invalidate the state.
To sum up another way, immutability is a requirement of Redux because Redux represents your application state as "frozen object snapshots". With these discrete snapshots, you can save your state, or reverse state, and generally have more "accounting" for all state changes.
State of your app is only changed by a category of pure functions called reducers. Reducers have 2 important properties:
function name(state, action) {}
, so it makes it easy to compose them:Assume the state looks like this:
var theState = { _2ndLevel: { count: 0 } }
We want to increment the count, so we make these reducers
const INCR_2ND_LEVEL_COUNT = 'incr2NdLevelCount'; function _2ndlevel (state, action) { switch (action.type) { case INCR_2ND_LEVEL_COUNT: var newState = Objectd.assign({}, state); newState.count++ return newState; } } function topLevel (state, action) { switch (action.type) { case INCR_2ND_LEVEL_COUNT: return Object.assign( {}, {_2ndLevel: _2ndlevel(state._2ndlevel, action)} ); } }
Note the use of Object.assign({}, ...)
to create an entirely new objects in each reducer:
Assuming we have wired up Redux to these reducers, then if we use Redux's event system to trigger a state change ...
dispatch({type: INCR_2ND_LEVEL_COUNT})
...Redux will call:
theNewState = topLevel(theState, action);
NOTE: action
is from dispatch()
Now theNewState
is an entirely new object.
Note: You can enforce immutability with a library (or new language features), or just be careful to not mutate anything :D
For a deeper look, I highly recommend you checkout this video by Dan Abramov (the creator). It should answer any lingering questions you have.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With