Using Object Spread Operator

Using Object Spread Operator Since one of the core tenets of Redux is to never mutate state, you'll often find yourself using Object.assign() to create copies of objects with new or updated values. For example, in the todoApp below Object.assign() is used to return a new state object with an updated visibilityFilter property: function todoApp(state = initialState, action) { switch (action.type) { case SET_VISIBILITY_FILTER: return Object.assign({}, state, { visibilityFilter:

Isolating Redux Sub-Apps

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

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

Writing Tests

Writing Tests Because most of the Redux code you write are functions, and many of them are pure, they are easy to test without mocking. Setting Up We recommend Jest as the testing engine. Note that it runs in a Node environment, so you won't have access to the DOM. npm install --save-dev jest To use it together with Babel, you will need to install babel-jest: npm install --save-dev babel-jest and configure it to use ES2015 features in .babelrc: { "presets": ["es2015"] } Then, add this to scri

Redux FAQ: Code Structure

Redux FAQ: Code Structure Table of Contents What should my file structure look like? How should I group my action creators and reducers in my project? Where should my selectors go? How should I split my logic between reducers and action creators? Where should my “business logic” go? Code Structure What should my file structure look like? How should I group my action creators and reducers in my project? Where should my selectors go? Since Redux is just a data store library, it has no direc

Motivation

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

Splitting Up Reducer Logic

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

Implementing Undo History

Implementing Undo History Building an Undo and Redo functionality into an app has traditionally required conscious effort from the developer. It is not an easy problem with classical MVC frameworks because you need to keep track of every past state by cloning all relevant models. In addition, you need to be mindful of the undo stack because the user-initiated changes should be undoable. This means that implementing Undo and Redo in an MVC application usually forces you to rewrite parts of your

Redux FAQ: Organizing State

Redux FAQ: Organizing State Table of Contents Do I have to put all my state into Redux? Should I ever use React's setState()? Can I put functions, promises, or other non-serializable items in my store state? How do I organize nested or duplicate data in my state? Organizing State Do I have to put all my state into Redux? Should I ever use React's setState()? There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializab