Reusing Reducer Logic

Reusing Reducer Logic As an application grows, common patterns in reducer logic will start to emerge. You may find several parts of your reducer logic doing the same kinds of work for different types of data, and want to reduce duplication by reusing the same common logic for each data type. Or, you may want to have multiple "instances" of a certain type of data being handled in the store. However, the global structure of a Redux store comes with some trade-offs: it makes it easy to track the o

Three Principles

Three Principles Redux can be described in three fundamental principles: Single source of truth The state of your whole application is stored in an object tree within a single store. This makes it easy to create universal apps, as the state from your server can be serialized and hydrated into the client with no extra coding effort. A single state tree also makes it easier to debug or introspect an application; it also enables you to persist your app's state in development, for a faster developm

Migrating to Redux

Migrating to Redux Redux is not a monolithic framework, but a set of contracts and a few functions that make them work together. The majority of your “Redux code” will not even use Redux APIs, as most of the time you'll be writing functions. This makes it easy to migrate both to and from Redux. We don't want to lock you in! From Flux Reducers capture “the essence” of Flux Stores, so it's possible to gradually migrate an existing Flux project towards Redux, whether you are using Flummox, Alt, tr

Refactoring Reducer Logic Using Functional Decomposition and Reducer Composition

Refactoring Reducer Logic Using Functional Decomposition and Reducer Composition It may be helpful to see examples of what the different types of sub-reducer functions look like and how they fit together. Let's look at a demonstration of how a large single reducer function can be refactored into a composition of several smaller functions. Note: this example is deliberately written in a verbose style in order to illustrate the concepts and the process of refactoring, rather than perfectly concis

Normalizing State Shape

Normalizing State Shape Many applications deal with data that is nested or relational in nature. For example, a blog editor could have many Posts, each Post could have many Comments, and both Posts and Comments would be written by a User. Data for this kind of application might look like: const blogPosts = [ { id : "post1", author : {username : "user1", name : "User 1"}, body : "......", comments : [ { id : "comment1",

Computing Derived Data

Computing Derived Data Reselect is a simple library for creating memoized, composable selector functions. Reselect selectors can be used to efficiently compute derived data from the Redux store. Motivation for Memoized Selectors Let's revisit the Todos List example: containers/VisibleTodoList.js import { connect } from 'react-redux' import { toggleTodo } from '../actions' import TodoList from '../components/TodoList' const getVisibleTodos = (todos, filter) => { switch (filter) { case

Store#getState()

getState() Returns the current state tree of your application. It is equal to the last value returned by the store's reducer. Returns (any): The current state tree of your application.

Middleware

Middleware You've seen middleware in action in the Async Actions example. If you've used server-side libraries like Express and Koa, you were also probably already familiar with the concept of middleware. In these frameworks, middleware is some code you can put between the framework receiving a request, and the framework generating a response. For example, Express or Koa middleware may add CORS headers, logging, compression, and more. The best feature of middleware is that it's composable in a

Redux FAQ: General

Redux FAQ: General Table of Contents When should I use Redux? Can Redux only be used with React? Do I need to have a particular build tool to use Redux? General When should I use Redux? Pete Hunt, one of the early contributors to React, says: You'll know when you need Flux. If you aren't sure if you need it, you don't need it. Similarly, Dan Abramov, one of the creators of Redux, says: I would like to amend this: don't use Redux until you have problems with vanilla React. In general, us

Prior Art

Prior Art Redux has a mixed heritage. It is similar to some patterns and technologies, but is also different from them in important ways. We'll explore some of the similarities and the differences below. Flux Can Redux be considered a Flux implementation? Yes, and no. (Don't worry, Flux creators approve of it, if that's all you wanted to know.) Redux was inspired by several important qualities of Flux. Like Flux, Redux prescribes that you concentrate your model update logic in a certain layer o