Skip to content
This repository has been archived by the owner on Mar 24, 2022. It is now read-only.

Thinking in Redux

Liam Morley edited this page Nov 14, 2015 · 1 revision

This discusses the client aspect of our implementation, specifically with regard to the development mindset.

Introduction to Redux

Redux is a JavaScript framework that espouses a minimalistic and functionally oriented view of Facebook's Flux architecture. While Pulse chooses to combine Redux with React1, React is not a requirement or dependency of Redux.

Redux has three principles:

  1. There is one client-side data store which is the single source of truth regarding the client's understanding of the application state.
  2. This state is read-only: the only way to change state is to emit an action, which only express an intent to mutate.
  3. State mutations (known as reducers) are pure functions which simply accept the current state and an action and return a new state; they have no side effects.

Actions

Actions are instructions sent from the view to the store which indicate how to change state. These may or may not include a network request to the server: potential actions within Pulse may be to create a new project, or to filter/sort existing projects, or to indicate that a request for projects from the server is underway in order to display a spinner. Actions are plain objects and have no behavior.

Asynchronous actions break this rule (with the help of the redux-thunk middleware) by returning functions that accept a dispatch callback which the function can call when the request is resolved. The end result of processing the middleware is a plain action object, the same as in the previous paragraph.

Reducers

Reducers specify how the state should be changed by a given action, or rather, what the new state should be, given a certain action. They do not mutate the current state or given action, perform API calls, redirect to a new route or URL, or interact with non-pure functions (e.g. Date.now() or Math.random()).

Store

The store contains the state of the application, facilitates updates to the state, and provides a method for registering listeners. There is only one store in a Redux application, and contains the entire application state.

Any desired middleware can be attached to the application during the creation of the store.

Application Structure and Data Flow

There is a single store, which is instantiated with all of the reducers. Upon any event that would result in a change of state (either data or UI), an action is created and passed to the store. The store then delegates that action to the reducer, which then returns the updated state.

While technically any React component can contain state, best practices within React state that only top-level components manage state, and child components get data passed into them. Every time the state changes, all components are then redrawn with their new parameters, which is actually quite efficient due to React's virtual DOM. For this reason, only top-level components are aware of Redux, and all other components are simply basic React components.

Footnotes

1: As this paper does not currently seek to explain React in general, it may be useful to read React's documentation on thinking in React. To quickly summarize React's role: it is a component-centric JavaScript framework focused on rendering of information.

Clone this wiki locally