Recipes These are some use cases and code snippets to get you started with Redux in a real app. They assume you understand the topics in basic and advanced tutorials. Migrating to Redux Using Object Spread Operator Reducing Boilerplate Server Rendering Writing Tests Computing Derived Data Implementing Undo History Isolating Subapps

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

Prerequisite Reducer Concepts As described in Reducers, a Redux reducer function: Should have a signature of (previousState, action) => newState, similar to the type of function you would pass to Array.prototype.reduce(reducer, ?initialValue) Should be "pure", which means it does not mutate its arguments, perform side effects like API calls or modifying values outside of the function, or call non-pure functions like Date.now() or Math.random(). This also means that updates should be done in

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",

Motivation As the requirements for JavaScript single-page applications have become increasingly complicated, our code must manage more state than ever before. This state can include server responses and cached data, as well as locally created data that has not yet been persisted to the server. UI state is also increasing in complexity, as we need to manage the active route, the selected tab, whether to show a spinner or not, should pagination controls be displayed, and so on. Managing this ever

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

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

Managing Normalized Data As mentioned in Normalizing State Shape, the Normalizr library is frequently used to transform nested response data into a normalized shape suitable for integration into the store. However, that doesn't address the issue of executing further updates to that normalized data as it's being used elsewhere in the application. There are a variety of different approaches that you can use, based on your own preference. We'll use the example of adding a new Comment to a Post. St

Isolating Redux Sub-Apps Consider the case of a “big” app (contained in a <BigApp> component) that embeds smaller “sub-apps” (contained in <SubApp> components): import React, { Component } from 'react' import SubApp from './subapp' class BigApp extends Component { render() { return ( <div> <SubApp /> <SubApp /> <SubApp /> </div> ) } } These <SubApp>s will be completely independent. They won't share

Introduction Motivation Three Principles Prior Art Ecosystem Examples