Redux is a predictable state container
You first have to understand how Redux works. There are few key principles:
- State is a immutable object
- You never mutate application state, you always return a new, modified one
- All state changes are initiated through actions (they contain desired changes details)
- 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.
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