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.

dispatch(action) Dispatches an action. This is the only way to trigger a state change. The store's reducing function will be called with the current getState() result and the given action synchronously. Its return value will be considered the next state. It will be returned from getState() from now on, and the change listeners will immediately be notified. A Note for Flux Users If you attempt to call dispatch from inside the reducer, it will throw with an error saying “Reducers may not dispa

Store A store holds the whole state tree of your application. The only way to change the state inside it is to dispatch an action on it. A store is not a class. It's just an object with a few methods on it. To create it, pass your root reducing function to createStore. A Note for Flux Users If you're coming from Flux, there is a single important difference you need to understand. Redux doesn't have a Dispatcher or support many stores. Instead, there is just a single store with a single root re

Store In the previous sections, we defined the actions that represent the facts about “what happened” and the reducers that update the state according to those actions. The Store is the object that brings them together. The store has the following responsibilities: Holds application state; Allows access to state via getState(); Allows state to be updated via dispatch(action); Registers listeners via subscribe(listener); Handles unregistering of listeners via the function returned by subscri

Splitting Up Reducer Logic For any meaningful application, putting all your update logic into a single reducer function is quickly going to become unmaintainable. While there's no single rule for how long a function should be, it's generally agreed that functions should be relatively short and ideally only do one specific thing. Because of this, it's good programming practice to take pieces of code that are very long or do many different things, and break them into smaller pieces that are easie

Server Rendering The most common use case for server-side rendering is to handle the initial render when a user (or search engine crawler) first requests our app. When the server receives the request, it renders the required component(s) into an HTML string, and then sends it as a response to the client. From that point on, the client takes over rendering duties. We will use React in the examples below, but the same techniques can be used with other view frameworks that can render on the server

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

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

Redux FAQ: Store Setup Table of Contents Can or should I create multiple stores? Can I import my store directly, and use it in components myself? Is it OK to have more than one middleware chain in my store enhancer? What is the difference between next and dispatch in a middleware function? How do I subscribe to only a portion of the state? Can I get the dispatched action as part of the subscription? Store Setup Can or should I create multiple stores? Can I import my store directly, and

Redux FAQ: Reducers Table of Contents How do I share state between two reducers? Do I have to use combineReducers? Do I have to use the switch statement to handle actions? Reducers How do I share state between two reducers? Do I have to use combineReducers? The suggested structure for a Redux store is to split the state object into multiple “slices” or “domains” by key, and provide a separate reducer function to manage each individual data slice. This is similar to how the standard Flux p