Redux docs Suggested:
- 1.1 Motivation
- 1.2 Three principles
- 2.1-5 Basics (pay extra attention to reducers)
React's docs are notoriously bad. Instead, refer to the one page you really need
Once upon a time, we built GUIs, before we dropped the redundant G and the widespread familiarity with CLIs. Each piece of an application encapsulated it's own functionality; it mutated itself, it tracked what to do when, it had to have some kind of messaging system between itself and other components.
View code sat next to both view logic and application logic; logical data flow and the ability to reason about data transformations were lost as incremental code updates created more and more complicated and less understandable spaghetti code (if you've ever written UI code in jquery before, this is that). On top of this, sometimes different UI components relied on the same data or computations, but had difficulty exposing their functionality to each other or had to perform the same computations multiple times. Messaging and dependencies created data races and loops and potentials for resource deadlock.
Fast forward a bit and nobody knows what a CLI is. We're all using browsers, and the majority of us are starting to equate browsers with computers. MVCs come along, like Angular, but inherit a lot of the old way of thinking and it's problems. Angular fails (probably because rigidity, boilerplate code, missing simplicity, and terrible developer PR decisions like Angular 2's lack of backwards compatibility).
So then just the V came along - React,
with it's magically fast rendering of the virtual DOM, the ease of markup living with logic, and it's deadly simple APIs.
Deadly simple in that it's so non-prescriptive, you can use it wrong incredibly easy.
It had promise, sure, but managing your data and application state was still the wild, wild west, and at best you had something
only slightly better than a var _CUR_APP_MODE = 1; switch (_CUR_APP_MODE) { ... }. You've got the unidirectional data flow,
but none of the data management simplicity, and the same resource deadlock and double computation problems of message passing.
So then Flux. Too restrictive, too complicated, but pure of heart.
So then Redux - all the good ideas of Flux, with minimalism mixed equally with raw strength, a formula React proved was a winner.
What were those good ideas? Let's look at how Redux works.
Redux's 2.4 describes the unidirectional data flow paradigm which is simple, predictable, and beautiful because of this. React is the perfect view library for this - transforming input state smartly to markup. Redux gives you the rest of the package - a functional programming approach to mutating state. The cycle is as follows
- user takes an action
- action is represented as a redux action
- redux consumes that action in a reducer, a function which takes a state and an action and returns a state
(this is functional programming at it's best) - the new state is diseminated to react components, who render themselves accordingly
Why is this so nice? Your data is this singular source of truth. Different components have access to the same underlying data when needed, and don't need to worry about message passing - changes mutate data, not other components. The views don't have to be smart. Think of your React components as data funnels, through which you shove data and out comes the appropriate visual change. There are no side effects in your reducers, so your state transformations are predictable and manageable. Being entirely functional enables some really awesome stuff, like viewing, replaying, and modifying actions on the fly with Redux DevTools. View code can live outside of logic code, but markup can still be right next to JS logic. Application logic is centralized.
in retrospect it seems simple.