Redux is a predictable state container

Question

The description of Redux project is:

Redux is a predictable state container

Can explain to me what \"predictable\" word meaning in t

Answer 1

Redux is a "state container" because it holds all the state of your application. It doesn't let you change that state directly, but instead forces you to describe changes as plain objects called "actions". Actions can be recorded and replayed later, so this makes state management predictable. With the same actions in the same order, you're going to end up in the same state.

By Dan Abramov

Answer 2

After some while, I understood the point: First all, my question come from C++/Java/C# event driven (Redux have implementation not only for JS).

So I wonder what so bad with old pattern fashion Event-driving environment like Winform and all like? They all work with DataTable or collection of plain classes (Structures). The visual component hold state of Edit state or another Widget state, but not logic at all. (I not refer here to big words like MVC or MVVW or all other slogan. But all convince the same truth: we must seperate the View from Logic in some way).

Refer to Evaldas Buinauskas answer, have 4 principle. Let me explain why those principles is not the piont:

1> For what reason I need immutable? (Automatic changing awareness can be done with Aspect-Oriented Programming Or even is not so badly call re-render manually after each action)

2> Same of above (I still guess we not want clone hole store for each action without delete the previous one. For most app is not necessary or not possible due the lake of RAM).

3> All event driven I knew implement it.

4> Some of above. Immutable not necessary and new state as result of Action implement well with all known event driver patterns.

So, I think the main answer of Evaldas Buinauskas from my view point is:

Redux is heavily inspired by Elm architecture and encourages functional programming principles, one of them being pure functions (they produce no side effects (like http calls, disk reads) and their output is always the same for the same input).

With pure function that not change anything outside of Store, we get more clear and testable code (I guess that mean of words "Predicated").

Answer 3

You first have to understand how Redux works. There are few key principles:

1. State is a immutable object
2. You never mutate application state, you always return a new, modified one
3. All state changes are initiated through actions (they contain desired changes details)
4. Reducers take current state, action and produce a new state ((state, action) => state)

So you can see that this is all unidirectional (changes flow one way only):

state -> action -> reducer -> state -> action -> reducer -> state ...

Redux is heavily inspired by Elm architecture and encourages functional programming principles, one of them being pure functions (they produce no side effects (like http calls, disk reads) and their output is always the same for the same input).

Every single state change in reducers has to be taken care by developers explicitly. Also all reducers are supposed to be pure. That's where the predictability comes from.

So to summarize, predictable in this context means, that using Redux you'll know what every single action in application will do and how state will change.

Answer 4

You need to understand how changes are made in Reux and what is action and reducer in it.

• An action is an object which has a type property and it describes the changes in the state of the application.
• A reducer actually carries out the state transition depending on the action.

This way reducer carries out a definite state transition based on a definite action out of multiple possible actions. So every time a specific action causes a specific change in a state and makes Redux predictable.