Diving Deeper into Redux

Diving Deeper into Redux

In this article, I’ll delve into Redux’s state container by building a payroll processing engine. The app will store pay stubs, along with all the extras — such as bonuses and stock options.

In this article, I’ll delve into Redux’s state container by building a payroll processing engine. The app will store pay stubs, along with all the extras — such as bonuses and stock options.

I’ll keep the solution in plain JavaScript with TypeScript for type checking. Since Redux is super testable, I’ll also use Jest to verify the app.

Building stateful modern applications is complex. As state mutates, the app becomes unpredictable and hard to maintain. That’s where Redux comes in. Redux is a lightweight library that tackles state. Think of it as a state machine.

For the purposes of this tutorial, I’ll assume a moderate level of familiarity with JavaScript, Node, and npm.

To begin, you can initialize this app with npm:

npm init 

When asked about the test command, go ahead and put jest. This means npm t will fire up Jest and run all unit tests. The main file will be index.js to keep it nice and simple. Feel free to answer the rest of the npm init questions to your heart’s content.

I’ll use TypeScript for type checking and nailing down the data model. This aids in conceptualizing what we’re trying to build.

To get going with TypeScript:

npm i typescript --save-dev 

I’ll keep dependencies that are part of the dev workflow in devDependencies. This makes it clear which dependencies are for developers and which goes to prod. With TypeScript ready, add a start script in the package.json:

"start": "tsc && node .bin/index.js" 

Create an index.ts file under the src folder. This separates source files from the rest of the project. If you do an npm start, the solution will fail to execute. This is because you’ll need to configure TypeScript.

Create a tsconfig.json file with the following configuration:

{
  "compilerOptions": {
    "strict": true,
    "lib": ["esnext", "dom"],
    "outDir": ".bin",
    "sourceMap": true
  },
  "files": [
    "src/index"
  ]
}

I could have put this configuration in a tsc command-line argument. For example, tsc src/index.ts --strict .... But it’s much cleaner to go ahead and put all this in a separate file. Note the start script in package.json only needs a single tsc command.

Here are sensible compiler options that will give us a good starting point, and what each option means:

  • strict: enable all strict type checking options, i.e., --noImplicitAny, --strictNullChecks, etc.
  • lib: list of library files included in the compilation
  • outDir: redirect output to this directory
  • sourceMap: generate source map file useful for debugging
  • files: input files fed to the compiler

Because I’ll be using Jest for unit testing, I’ll go ahead and add it:

npm i jest ts-jest @types/jest @types/node --save-dev 

The ts-jest dependency adds type checking to the testing framework. One gotcha is to add a jest configuration in package.json:

"jest": {
  "preset": "ts-jest"
}

This makes it so the testing framework picks up TypeScript files and knows how to transpile them. One nice feature with this is you get type checking while running unit tests. To make sure this project is ready, create a __tests__ folder with an index.test.ts file in it. Then, do a sanity check. For example:

it('is true', () => {
  expect(true).toBe(true);
});

Doing npm start and npm t now runs without any errors. This tells us we’re now ready to start building the solution. But before we do, let’s add Redux to the project:

npm i redux --save 

This dependency goes to prod. So, no need to include it with --save-dev. If you inspect your package.json, it goes in dependencies.

Payroll Engine in Action

The payroll engine will have the following: pay, reimbursement, bonus, and stock options. In Redux, you can’t directly update state. Instead, actions are dispatched to notify the store of any new changes.

So, this leaves us with the following action types:

const BASE_PAY = 'BASE_PAY';
const REIMBURSEMENT = 'REIMBURSEMENT';
const BONUS = 'BONUS';
const STOCK_OPTIONS = 'STOCK_OPTIONS';
const PAY_DAY = 'PAY_DAY';

The PAY_DAY action type is useful for dolling out a check on pay day and keeping track of pay history. These action types guide the rest of the design as we flesh out the payroll engine. They capture events in the state lifecycle — for example, setting a base pay amount. These action events can attach to anything, whether that be a click event or a data update. Redux action types are abstract to the point where it doesn’t matter where the dispatch comes from. The state container can run both on the client and/or server.

TypeScript

Using type theory, I’ll nail down the data model in terms of state data. For each payroll action, say an action type and an optional amount. The amount is optional, because PAY_DAY doesn’t need money to process a paycheck. I mean, it could charge customers but leave it out for now (maybe introducing it in version two).

So, for example, put this in src/index.ts:

interface PayrollAction {
  type: string;
  amount?: number;
}

For pay stub state, we need a property for base pay, bonus, and whatnot. We’ll use this state to maintain a pay history as well.

This TypeScript interface ought to do it:

interface PayStubState {
  basePay: number;
  reimbursement: number;
  bonus: number;
  stockOptions: number;
  totalPay: number;
  payHistory: Array;
}

The PayStubState is a complex type, meaning it depends on another type contract. So, define the payHistory array:

interface PayHistoryState {
  totalPay: number;
  totalCompensation: number;
}

With each property, note TypeScript specifies the type using a colon. For example, : number. This settles the type contract and adds predictability to the type checker. Having a type system with explicit type declarations enhances Redux. This is because the Redux state container is built for predictable behavior.

As the app mutates, type checking adds an extra layer of predictability. Type theory also aids as the app scales because it’s easier to refactor large sections of code.

Conceptualizing the engine with types now helps to create the following action functions:

export const processBasePay = (amount: number): PayrollAction =>
  ({type: BASE_PAY, amount});
export const processReimbursement = (amount: number): PayrollAction =>
  ({type: REIMBURSEMENT, amount});
export const processBonus = (amount: number): PayrollAction =>
  ({type: BONUS, amount});
export const processStockOptions = (amount: number): PayrollAction =>
  ({type: STOCK_OPTIONS, amount});
export const processPayDay = (): PayrollAction =>
  ({type: PAY_DAY});

What’s nice is that, if you attempt to do processBasePay('abc'), the type checker barks at you. Breaking a type contract adds unpredictability to the state container. I’m using a single action contract like PayrollAction to make the payroll processor more predictable. Note amount is set in the action object via an ES6 property shorthand. The more traditional approach is amount: amount, which is long-winded. An arrow function, like () => ({}), is one succinct way to write functions that return an object literal.

Reducer as a Pure Function

The reducer functions need a state and an action parameter. The state should have an initial state with a default value. So, can you imagine what our initial state might look like? I’m thinking it needs to start at zero with an empty pay history list.

For example:

const initialState: PayStubState = {
  basePay: 0, reimbursement: 0,
  bonus: 0, stockOptions: 0,
  totalPay: 0, payHistory: []
};

The type checker makes sure these are proper values that belong in this object. With the initial state in place, begin creating the reducer function:

export const payrollEngineReducer = (
  state: PayStubState = initialState,
  action: PayrollAction): PayStubState => {

The Redux reducer has a pattern where all action types get handled by a switch statement. But before going through all switch cases, I’ll create a reusable local variable:

let totalPay: number = 0; 

Note that it’s okay to mutate local variables if you don’t mutate global state. I use a let operator to communicate this variable is going to change in the future. Mutating global state, like the state or action parameter, causes the reducer to be impure. This functional paradigm is critical because reducer functions must remain pure.

Start the reducer’s switch statement to handle the first use case:

switch (action.type) {
  case BASE_PAY:
    const {amount: basePay = 0} = action;
    totalPay = computeTotalPay({...state, basePay});

    return {...state, basePay, totalPay};

I’m using an ES6 rest operator to keep state properties the same. For example, ...state. You can override any properties after the rest operator in the new object. The basePay comes from destructuring, which is a lot like pattern matching in other languages. The computeTotalPay function is set as follows:

const computeTotalPay = (payStub: PayStubState) =>
  payStub.basePay + payStub.reimbursement
  + payStub.bonus - payStub.stockOptions;

Note you deduct stockOptions because the money will go towards buying company stock. Say you want to process a reimbursement:

case REIMBURSEMENT:
  const {amount: reimbursement = 0} = action;
  totalPay = computeTotalPay({...state, reimbursement});

  return {...state, reimbursement, totalPay};

Since amount is optional, make sure it has a default value to reduce mishaps. This is where TypeScript shines, because the type checker picks up on this pitfall and barks at you. The type system knows certain facts so it can make sound assumptions. Say you want to process bonuses:

case BONUS:
  const {amount: bonus = 0} = action;
  totalPay = computeTotalPay({...state, bonus});

  return {...state, bonus, totalPay};

This pattern makes the reducer readable because all it does is maintain state. You grab the action’s amount, compute total pay, and create a new object literal. Processing stock options is not much different:

case STOCK_OPTIONS:
  const {amount: stockOptions = 0} = action;
  totalPay = computeTotalPay({...state, stockOptions});

  return {...state, stockOptions, totalPay};

For processing a paycheck on pay day, it’ll need to blot out bonus and reimbursement. These two properties don’t remain in state per paycheck. And, add an entry to pay history. Base pay and stock options can stay in state because they don’t change as often per paycheck. With this in mind, this is how PAY_DAY goes:

case PAY_DAY:
  const {payHistory} = state;
  totalPay = state.totalPay;

  const lastPayHistory = payHistory.slice(-1).pop();
  const lastTotalCompensation = (lastPayHistory
    && lastPayHistory.totalCompensation) || 0;
  const totalCompensation = totalPay + lastTotalCompensation;

  const newTotalPay = computeTotalPay({...state,
    reimbursement: 0, bonus: 0});
  const newPayHistory = [...payHistory, {totalPay, totalCompensation}];

  return {...state, reimbursement: 0, bonus: 0,
    totalPay: newTotalPay, payHistory: newPayHistory};

In an array like newPayHistory, use a spread operator, which is the reverse of rest. Unlike rest, which collects properties in an object, this spreads items out. So, for example, [...payHistory]. Even though both these operators look similar, they aren’t the same. Look closely, because this might come up in an interview question.

Using pop() on payHistory doesn’t mutate state. Why? Because slice() returns a brand new array. Arrays in JavaScript are copied by reference. Assigning an array to a new variable doesn’t change the underlying object. So, one must be careful when dealing with these types of objects.

Because there’s a chance lastPayHistory is undefined, I use poor man’s null coalescing to initialize it to zero. Note the (o && o.property) || 0 pattern to coalesce. Maybe a future version of JavaScript or even TypeScript will have a more elegant way of doing this.

Every Redux reducer must define a default branch. To make sure state doesn’t become undefined:

default:
  return state;
Testing the Reducer Function

One of the many benefits of writing pure functions is that they’re testable. A unit test is one where you must expect predictable behavior — to the point where you can automate all tests as part of a build. In __tests__/index.test.ts, knock out the dummy test and import all functions of interest:

import { processBasePay,
  processReimbursement,
  processBonus,
  processStockOptions,
  processPayDay,
  payrollEngineReducer } from '../src/index';

Note that all functions were set with an export so you can import them in. For a base pay, fire up the payroll engine reducer and test it:

it('process base pay', () => {
  const action = processBasePay(10);
  const result = payrollEngineReducer(undefined, action);

  expect(result.basePay).toBe(10);
  expect(result.totalPay).toBe(10);
});

Redux sets the initial state as undefined. Therefore, it’s always a good idea to provide a default value in the reducer function. What about processing a reimbursement?

it('process reimbursement', () => {
  const action = processReimbursement(10);
  const result = payrollEngineReducer(undefined, action);

  expect(result.reimbursement).toBe(10);
  expect(result.totalPay).toBe(10);
});

The pattern here is the same for processing bonuses:

it('process bonus', () => {
  const action = processBonus(10);
  const result = payrollEngineReducer(undefined, action);

  expect(result.bonus).toBe(10);
  expect(result.totalPay).toBe(10);
});

For stock options:

it('skip stock options', () => {
  const action = processStockOptions(10);
  const result = payrollEngineReducer(undefined, action);

  expect(result.stockOptions).toBe(0);
  expect(result.totalPay).toBe(0);
});

Note totalPay must remain the same when stockOptions is greater than totalPay. Since this hypothetical company is ethical, is doesn’t want to take money from its employees. If you run this test, note that totalPay is set to -10 because stockOptions gets deducted. This is why we test code! Let’s fix this where it computes total pay:

const computeTotalPay = (payStub: PayStubState) =>
  payStub.totalPay >= payStub.stockOptions
  ? payStub.basePay + payStub.reimbursement
    + payStub.bonus - payStub.stockOptions
  : payStub.totalPay;

If the employee doesn’t make enough money to buy company stock, go ahead and skip the deduction. Also, make sure it resets stockOptions to zero:

case STOCK_OPTIONS:
  const {amount: stockOptions = 0} = action;
  totalPay = computeTotalPay({...state, stockOptions});

  const newStockOptions = totalPay >= stockOptions
    ? stockOptions : 0;

  return {...state, stockOptions: newStockOptions, totalPay};

The fix figures out whether they have enough in newStockOptions. With this, unit tests pass, and the code is sound and makes sense. We can test the positive use case where there’s enough money for a deduction:

it('process stock options', () => {
  const oldAction = processBasePay(10);
  const oldState = payrollEngineReducer(undefined, oldAction);
  const action = processStockOptions(4);
  const result = payrollEngineReducer(oldState, action);

  expect(result.stockOptions).toBe(4);
  expect(result.totalPay).toBe(6);
});

For pay day, test with multiple states and make sure one-time transactions don’t persist:

it('process pay day', () => {
  const oldAction = processBasePay(10);
  const oldState = payrollEngineReducer(undefined, oldAction);
  const action = processPayDay();
  const result = payrollEngineReducer({...oldState, bonus: 10,
    reimbursement: 10}, action);

  expect(result.totalPay).toBe(10);
  expect(result.bonus).toBe(0);
  expect(result.reimbursement).toBe(0);
  expect(result.payHistory[0]).toBeDefined();
  expect(result.payHistory[0].totalCompensation).toBe(10);
  expect(result.payHistory[0].totalPay).toBe(10);
});

Note how I tweak oldState to verify bonus and reset reimbursement back to zero.

What about the default branch in the reducer?

it('handles default branch', () => {
  const action = {type: 'INIT_ACTION'};
  const result = payrollEngineReducer(undefined, action);

  expect(result).toBeDefined();
});

Redux sets an action type like INIT_ACTION in the beginning. All we care about is that our reducer sets some initial state.

Putting It All Together

At this point, you may start to wonder if Redux is more of a design pattern than anything else. If you answer that it’s both a pattern and a lightweight library, then you’re correct. In index.ts, import Redux:

import { createStore } from 'redux'; 

The next code sample can go wrapped around this if statement. This is a stopgap, so unit tests don’t leak into integration tests:

if (!process.env.JEST_WORKER_ID) {
}

I don’t recommend doing this in a real project. Modules can go in separate files to isolate components. This makes it more readable and won’t leak concerns. Unit tests also benefit from the fact modules run in isolation.

Fire up a Redux store with the payrollEngineReducer:

const store = createStore(payrollEngineReducer, initialState);
const unsubscribe = store.subscribe(() => console.log(store.getState()));

Every store.subscribe() returns a subsequent unsubscribe() function useful for cleaning up. It unsubscribes callbacks when actions get dispatched through the store. Here, I’m outputting current state to the console with store.getState().

Say this employee makes 300, has a 50 reimbursement, 100 bonus, and 15 going towards company stock:

store.dispatch(processBasePay(300));
store.dispatch(processReimbursement(50));
store.dispatch(processBonus(100));
store.dispatch(processStockOptions(15));
store.dispatch(processPayDay());

To make it more interesting, do another 50 reimbursement and process another paycheck:

store.dispatch(processReimbursement(50));
store.dispatch(processPayDay());

Finally, run yet another paycheck and unsubscribe from the Redux store:

store.dispatch(processPayDay());

unsubscribe();

The end result looks like this:

{ "basePay": 300,
  "reimbursement": 0,
  "bonus": 0,
  "stockOptions": 15,
  "totalPay": 285,
  "payHistory":
   [ { "totalPay": 435, "totalCompensation": 435 },
     { "totalPay": 335, "totalCompensation": 770 },
     { "totalPay": 285, "totalCompensation": 1055 } ] }

As shown, Redux maintains state, mutates, and notifies subscribers in one sweet little package. Think of Redux as a state machine that is the source of truth for state data. All this, while embracing the best coding has to offer, such as a sound functional paradigm.

Conclusion

Redux has a simple solution to the complex problem of state management. It rests on a functional paradigm to reduce unpredictability. Because reducers are pure functions, it’s super easy to unit test. I decided to use Jest, but any test framework that supports basic assertions will work too.

TypeScript adds an extra layer of protection with type theory. Couple type checking with functional programming and you get sound code that hardly breaks. Best of all, TypeScript stays out of the way while adding value. If you notice, there’s little extra coding once type contracts are in place. The type checker does the rest of the work. Like any good tool, TypeScript automates coding discipline while remaining invisible. TypeScript comes with a loud bark yet gentle bite.

If you wanted to have a play around with this project (and I hope you do), you can find the source code for this article on GitHub.

An intro to Redux and how state is updated in a Redux application

An intro to Redux and how state is updated in a Redux application

I started learning Redux a few days back and it was an overwhelming concept for me at the start. After polishing my skills in ReactJS by making a&nbsp;<a href="https://github.com/aimenbatool/my-reads" target="_blank">personal book reading application</a>, I headed towards Redux to learn more about it.

I started learning Redux a few days back and it was an overwhelming concept for me at the start. After polishing my skills in ReactJS by making a personal book reading application, I headed towards Redux to learn more about it.

Today, I’m going to share a few core Redux concepts without using any view library (React or Angular). This is a kind of a personal note for future reference but it can help others as well.

Let’s dig in together!

What is Redux?

Redux is an open-source library to improve the predictability of the state in a JavaScript application. It is an independent library. It is commonly used with other libraries like React and Angular for better state management of the application. Redux was created by Dan Abramov in 2015 to handle complex state management in an efficient way.


When an application grows larger it becomes harder to manage the state and debug for issues. It becomes a challenge to track when and where the state is changed and where the changes need to be reflected. Sometimes a user input triggers some API call which updates some model. That model in turn updates some state or maybe the other model and so on.

In such a situation it becomes grinding to track the state changes. It happens mainly because there is no defined rule to update a state and state can be changed from anywhere inside the application.

Redux tries to solve this issue by providing a few simple rules to update the state to keep it predictable. Those rules are the building blocks of Redux.

Redux Store:

As we discussed earlier, the main purpose of Redux is to provide predictable state management in our applications. Redux achieves this by having a single source of truth, that is a single state tree. The state tree is a simple JavaScript object which holds the whole state of our application. There are only a few ways to interact with the state. And this makes it easy for us to debug or track our state.


We now have only one main state which occupies the whole state of the application located at a single location. Any changes made into the state tree are reflected in the whole application because this is the only source of data for the app. And, this is the first fundamental principle of Redux.

Rule #1 — Single source of truth

The state of your whole application is stored in an object tree within a single store. — Official docs

The ways you can interact with a state tree are:

  • Getting the state
  • Listening to the changes in the state
  • Updating the state

store is a single unit that holds the state tree and the methods to interact with the state tree. There is no other way to interact with a state inside the store except through these given methods.

Let’s talk about the methods a store gives us to interact with the state.

  • getState() — Returns the current state of the application.
  • dispatch(action) — The only way to update a state is by dispatching an action and dispatch(action) serves the purpose. We will talk more in detail in a bit.
  • subscribe(listener) — The purpose of this method is to listen for the state changes. Every time a state is changed, it will be called and will return the updated state.
  • replaceReducer(nextReducer) — Replaces the reducer currently used by the store to calculate the state.

Now when we have a store which contains a state tree and a few ways to interact with the state, how can we update application state?

Updating state in the application:

The only way to update a state is to dispatch an action. This is the 2nd rule.


Rule #2 — State is read-only

An action is a plain JavaScript object to keep track of the specific event taking place in the application. What makes it special is a ‘type’ property which is a necessary part of it.


{
  type: "ADD_BOOK_TO_THE_CART"
}

The main purpose of this property is to let Redux know about the event taking place. This type should be descriptive about the action. Along with the ‘type’ property, it can have other information about the event taking place.

Actions can have as much information as you want. It is a good practice to provide less and necessary information — preferably an id or any unique identifier wherever possible.

Here we have an action to add a book to the cart.

{
    type: 'ADD_BOOK_TO_THE_CART',
    bookId: 10, 
}

Once we define our action we pass it to the dispatcher. store.dispatch() is a function provided by the library which accepts an action to perform an action against the state. Redux restricts updating the state to this method only.

store.dispatch({
    type: 'ADD_BOOK_TO_THE_CART',
    bookId: 10,
})

This strict way of updating the state ensures that the state can not be changed directly either by view or any network callback. The only way to update a state is by defining the action and then dispatching it. Remember that actions are plain JavaScript objects. Actions can be logged, serialized, and replayed for debugging purposes.

We now have a store, a state, and an action in our app to perform some tasks against the state. Now we need a way to use these actions to actually do the update. This can be done by using a pure function and this is rule #3.

Rule#3 — Changes are made with pure functions

Magic happens here. We need a simple pure function, which, as a parameter, takes the current state of the application and an action to perform on the state, and then returns the updated state. These functions are called reducers.

function booksReducer (state = [], action) {
// Magic is happening here...
  }

These are called reducers because they take the collection of values, reduce it to an updated state and then return it. Since reducers are pure functions they do not mutate the original state. Instead, they return the updated state in a new object. Our application can have one or more than one reducer. Each reducer can have a relevant state to perform specific tasks.

function booksReducer (state = [], action) {
    switch(action.type) {
        case ADD_BOOK_TO_THE_CART:
            return state.concat([action.bookId]);
        case REMOVE_BOOK_FROM_CART:
            return state.filter( book => book.bookId !== action.bookId);
        // a few more actions
        default:
            return state;
    } 
}

Since reducers are pure functions, they should have the following attributes:

  • Given the same input, it should return the same output every time — No mutation is allowed.
  • No side effects — No API call data change from an external source.

The process.

If we connect the dots, Redux is a library which has a store that contains a state tree and a few methods to interact with the state. The only way to update a state inside a store is to dispatch an action and define a reducer function to perform tasks based on the given actions. Once dispatched, the action goes inside the reducer functions which performs the tasks and return the updated state to the store. This is what Redux is all about.

State update flow in Redux

What have we learned so far?

Let’s summarize what we have learned so far to connect the dots.


  • Redux — An opensource predictable state container
  • State Tree — A plain JavaScript object which contains whole application state
  • Three ways to interact with a state (the only ways):
  • Store — A single unit which contains state tree & methods to interact with the state tree
  • Actions — Plan Javascript objects to describe the action taking place
  • Reducers — Pure Javascript functions to take current state and an action to return a new state

Since Redux is an independent library which can be used with React, Angular or any other library, I avoided making a sample application with any of these view libraries. Instead, I focused on the core Redux concepts only.

Redux can be overwhelming at first and if you are a newbie or junior developer it can give you a tough time. But consistency and a positive attitude is the key to success.

Originally published on https://medium.freecodecamp.org



Understanding React with Redux and Redux Thunk for Beginners

Understanding React with Redux and Redux Thunk for Beginners

Introduction

Redux, according to the offical docs, is a predictable state container for JavaScript apps written by Dan Abramov. It’s a lightweight implementation of Flux, which is another library for managing the state. Basically Redux took the ideas that Flux brought in, leaving out its complexity by “borrowing” things from Elm.

For starters, there are several key concepts to understand: store, actions / action creators, and reducers. The official documentation is pretty straightforward and also plenty of examples and nice analogies can be found on the internet.

Principles

Redux has three fundamental principles:

  • single source of truth

The whole state of the application is stored in an object tree (within a single store). Visualize the state as a “model”, but without setters. As a plus, a single state tree enables us to debug our application with ease.

  • state is read-only

In order to modify state in Redux, actions have to be dispatched. Actions are a plain JavaScript object that describe what changed, sending data from the application to the store.

An action will look like this:

{
      type: 'ACTION_TYPE',
      action_value: string
  }

  • changes are made with pure functions

In order to tie state and actions together, we write a function called a reducer that takes two parameters: the (soon to be previous) state and an action. This pure function applies the action to that state and returns the desired next state.

Example of a reducer:

 export function reducer(state = '', action) {
      switch (action.type) {
          case 'ACTION_TYPE':
              return action.action_value;
          default:
              return state;
      }
  } 

Important: Reducers do not store state, and they do not mutate state. You pass state to the reducer and the reducer will return state.

Tip: As a best practice, even though it’s possible to have a single reducer that manages the transformation done by every action, it is better to use reducer composition - breaking down the reducer into multiple, smaller reducers, each of them handling a specific slice of the application state.

How it works

When one action is dispatched to the store, the combined reducer catches the action and sends it to each of the smaller reducers. Each smaller reducer examines what action was passed and dictates if and how to modify that part of state. You will find an example of a combined reducer a bit later in the article.

After each smaller reducer produces its corresponding next state, an updated state object will be saved in the store. Because this is important, I’m mentioning again that the store is the single source of truth in our application. Therefore, when each action is run through the reducers, a new state is produced and saved in the store.

Besides all of this, Redux comes up with another concept, action creators, which are functions that return actions. These can be linked to React components and when interacting with your application, the action creators are invoked (for example in one of the lifecycle methods) and create new actions that get dispatched to the store.

 export function actionCreator(bool) {
        return {
            type: 'ACTION_TYPE',
            action_value: bool
        };
    }

Fetching data from an API

Now onto our application. All of the above code snippets were just examples. We will now dive into the important bits of the code of our app. Also, a github repo will be available at the end of the article, containing the entire app.

Our app will fetch (asynchronously) data that is retrieved by an API - assuming we already built and deployed a working API, how convenient :) - and then display the fetched data as nice as my UI design skills go (not too far).

TVmaze’s public API contains tonnes of data and we will fetch all the shows they have ever aired. Then, the app will display all the shows, toghether with their rating and premiere date.

Designing our state

In order for this application to work properly, our state needs to have 3 properties: isLoading, hasError and items. So we will have one action creator for each property and an extra action creator where we will fetch the data and call the other 3 action creators based on the status of our request to the API.

Action creators

Let’s have a look at the first 3 action creators

export function itemsHaveError(bool) {
        return {
            type: 'ITEMS_HAVE_ERROR',
            hasError: bool
        };
    }

    export function itemsAreLoading(bool) {
        return {
            type: 'ITEMS_ARE_LOADING',
            isLoading: bool
        };
    }

    export function itemsFetchDataSuccess(items) {
        return {
            type: 'ITEMS_FETCH_DATA_SUCCESS',
            items
        };
    }

The first 2 action creators will receive a bool as a parameter and they will return an object with that bool value and the corresponding type.

The last one will be called after the fetching was successful and will receive the fetched items as an parameter. This action creator will return an object with a property called items that will receive as value the array of items which were passed as an argument. Instead if items: items, we can just write items, using an ES6 syntactic sugar called property shorthand.

To visualize a bit what was described earlier, this is how it looks in Redux DevTools:

Out of the box, action creators can return just actions. That’s where Redux Thunk comes in handy. Thunk allows us to have action creators that return a function instead of an action and dispatch an action only in certain cases.

If it wasn’t for Redux Thunk, we would probably end up having just one action creator, something like this:

export function itemsFetchData(url) {
        const items = axios.get(url);

        return {
            type: 'ITEMS_FETCH_DATA',
            items
        };
    }

Obviously, it would be a lot harder in this scenario to know if the items are still loading or checking if we have an error.

Knowing these and using Redux Thunk, our action creator will be:

 export function itemsFetchData(url) {
        return (dispatch) => {
            dispatch(itemsAreLoading(true));

            axios.get(url)
                .then((response) => {
                    if (response.status !== 200) {
                        throw Error(response.statusText);
                    }

                    dispatch(itemsAreLoading(false));

                    return response;
                })
                .then((response) => dispatch(itemsFetchDataSuccess(response.data)))
                .catch(() => dispatch(itemsHaveError(true)));
        };
    }

Reducers

Now that we have our action creators in place, let’s start writing our reducers.

All reducers will be called when an action is dispatched. Because of this, we are returning the original state in each of our reducers. When the action type matches, the reducer does what it has to do and returns a new slice of state. If not, the reducer returns the original state back.

Each reducer takes 2 parameters: the (soon to be previous) slice of state and an action object:

export function itemsHaveError(state = false, action) {
        switch (action.type) {
            case 'ITEMS_HAVE_ERROR':
                return action.hasError;
            default:
                return state;
        }
    }

    export function itemsAreLoading(state = false, action) {
        switch (action.type) {
            case 'ITEMS_ARE_LOADING':
                return action.isLoading;
            default:
                return state;
        }
    }

    export function items(state = [], action) {
        switch (action.type) {
            case 'ITEMS_FETCH_DATA_SUCCESS':
                return action.items;
            default:
                return state;
        }
    }

Now that we have the reducers created, let’s combine them in our index.js from our reducers folder:

 import { combineReducers } from 'redux';
    import { items, itemsHaveError, itemsAreLoading } from './items';

    export default combineReducers({
        items,
        itemsHaveError,
        itemsAreLoading
    });

Creating the store

Don’t forget about including the Redux Thunk middleware in the configureStore.js:


 import { createStore, applyMiddleware } from 'redux';
    import thunk from 'redux-thunk';
    import rootReducer from '../reducers';

    export default function configureStore(initialState) {
        const composeEnhancers = 
            window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ ?   
                window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__({
                    // options like actionSanitizer, stateSanitizer
                }) : compose;

        const enhancer = composeEnhancers(
            applyMiddleware(thunk)
        );

        return createStore(
            rootReducer,
            initialState,
            enhancer
        );
    }

Using the store in our root index.js

 import React from 'react';
    import { render } from 'react-dom';
    import { Provider } from 'react-redux';
    import configureStore from './store/configureStore';

    import ItemList from './components/ItemList';

    const store = configureStore();

    render(
        <Provider store={store}>
            <ItemList />
        </Provider>,
        document.getElementById('app')
    );

Writing our React component which shows the fetched data

Let’s start by talking about what we are importing here.

In order to work with Redux, we have to import connect from ‘react-redux’:

    import { connect } from 'react-redux';

Also, because we will fetch the data in this component, we will import our action creator that fetches data:

    import { itemsFetchData } from '../actions/items';

We are importing only this action creator, because this one also dispatches the other actions to the store.

Next step would be to map the state to the components’ props. For this, we will write a function that receives state and returns the props object.

const mapStateToProps = (state) => {
        return {
            items: state.items,
            hasError: state.itemsHaveError,
            isLoading: state.itemsAreLoading
        };
    };

When we have a new state, the props in our component will change according to our new state.

Also, we need to dispatch our imported action creator.

    const mapDispatchToProps = (dispatch) => {
        return {
            fetchData: (url) => dispatch(itemsFetchData(url))
        };
    };


With this one, we have access to our itemFetchData action creator through our props object. This way, we can call our action creator by doing this.props.fetchData(url);

Now, in order to make these methods actually do something, when we export our component, we have to pass these methods as arguments to connect. This connects our component to Redux.

    export default connect(mapStateToProps, mapDispatchToProps)(ItemList);

Finally, we will call this action creator in the componentDidMount lifecycle method:

    this.props.fetchData('http://api.tvmaze.com/shows');


Side note: if you are wondering why are we calling the action creator in componentDidMount instead of other lifecycle methods, I have found a couple of good reasons here:

  • You can’t guarantee the AJAX request won’t resolve before the component mounts. If it did, that would mean that you’d be trying to setState on an unmounted component, which not only won’t work, but React will yell at you for. Doing AJAX in componentDidMount will guarantee that there’s a component to update.

  • Fiber, the next implementation of React’s reconciliation algorithm, will have the ability to start and stop rendering as needed for performance benefits. One of the trade-offs of this is that componentWillMount, the other lifecycle event where it might make sense to make an AJAX request, will be “non-deterministic”. What this means is that React may start calling componentWillMount at various times whenever it feels like it needs to. This would obviously be a bad formula for AJAX requests.

Besides this, we need some validations:

    if (this.props.hasError) {
        return <p>Sorry! There was an error loading the items</p>;
    }

    if (this.props.isLoading) {
        return <p>Loading ...</p>;
    }


And the actual iteration over our fetched data array:

 {this.props.items.map((item) => (
        // display data here
    ))}

In the end, our component will look like this:

 import React, { Component, PropTypes } from 'react';
    import { connect } from 'react-redux';
    import { ListGroup, ListGroupItem } from 'react-bootstrap';
    import { itemsFetchData } from '../actions/items';

    class ItemList extends Component {
        componentDidMount() {
            this.props.fetchData('http://api.tvmaze.com/shows');
        }

        render() {
            if (this.props.hasError) {
                return <p>Sorry! There was an error loading the items</p>;
            }

            if (this.props.isLoading) {
                return <p>Loading ...</p>;
            }

            return (
                <div style={setMargin}>
                    {this.props.items.map((item) => (
                        <div key={item.id}>
                                <ListGroup style={setDistanceBetweenItems}>
                                    <ListGroupItem href={item.officialSite} header={item.name}>
                                        Rating: {item.rating.average}
                                        <span className="pull-xs-right">Premiered: {item.premiered}</span>
                                    </ListGroupItem>
                                </ListGroup>
                        </div>
                    ))}
                </div>
            );
        }
    }

    ItemList.propTypes = {
        fetchData: PropTypes.func.isRequired,
        items: PropTypes.array.isRequired,
        hasError: PropTypes.bool.isRequired,
        isLoading: PropTypes.bool.isRequired
    };

    const mapStateToProps = (state) => {
        return {
            items: state.items,
            hasError: state.itemsHaveError,
            isLoading: state.itemsAreLoading
        };
    };

    const mapDispatchToProps = (dispatch) => {
        return {
            fetchData: (url) => dispatch(itemsFetchData(url))
        };
    };

    export default connect(mapStateToProps, mapDispatchToProps)(ItemList);

And that was all !

Our app will look like this:

I wasn’t lying about my design skills, was I ? :)

Last words and other resources

We now have an app that is fetching data asynchronously from an API, using React for our UI and Redux for managing the state of our application. I think this is a good starting point for a personal / small project and also you get to work with new technologies.

This doesn’t mean that Redux is the solution for every problem we face when writing apps in React or that Redux is a a must-use in any Javascript written project, as Dan Abramov states in an interesting article.

Also worth noting, Facebook are preparing React Fiber, a reimplementation of React. They state that its goal is to make it more suitable for animations and gestures and that the key new feature will be incremental rendering which is:

  • the ability to split rendering work into chunks and spread it out over multiple frames

Redux in React

Redux in React

React Redux is maintained by the Redux team, and kept up-to-date with the latest APIs from Redux and React.

React Redux is maintained by the Redux team, and kept up-to-date with the latest APIs from Redux and React.

React is all about moving parts that pass information to each other. You will notice sometimes you have really long chains that go through several containers and several components. This can be a hassle if the data got messed up in one of the steps and you have to slowly backtrack and look through each part to find the error. there is where Redux comes into play! Redux stores all of your state information in a separate object, and any component can get the information it needs from this object. So instead of going home => container1 => component1=> component2, it will go home => Redux Object => component2. Lets see how this all works!

First is the reducer function.

You have two objects that are separate from everything else, the state and the action. The state contains, well, the state of your page, and the action contains the instructions to update that state.

let state = {name: "abc"}
let action = {type: "JOE-IFY"}

To allow action to modify state, you need a function.

function changeState(state, action) {
   if (action.type === 'JOE-IFY') {
      return {name: 'Joe'}
   }
}

If the action type is ‘JOE-IFY’, change the state of name to be “Joe”. There can be many different commands to change names, typically a switch case it used. However, to make sure a null or undefined is never returned a default case is added that returns the previous state.

function changeState(state, action) {
   switch (action.type) {
      case 'JOE-IFY':
         return {name: 'Joe'}
      default: 
         return: state
   }
}

Now if you ran the changeState function with the state and “JOE-IFY” you would get {name: “Joe”}.

If you had another action type, for example to change the name to “Bob” it would look like:

function changeState(state, action) {
   switch (action.type) {
      case 'JOE-IFY':
         return {name: 'Joe'}
      case 'BOB-IFY':
         return {name: 'Bob'}
      default: 
         return: state
   }
}

Now if you instead ran it with the function “BOB-IFY” you would get {name: “Bob”}. This changeState function is called the “reducer”, as it reduces the state and action into a new state.

You can make it more complicated as well, since an action can have multiple attributes.

let state = {name: "abc"}
let action = {type: "CHANGE_NAME",
              newName: "Spooderman"}

You will have to change the function such that it changes the state of name to that of newName. Something like:

function changeState(state, action) {
   switch (action.type) {
      case 'CHANGE_NAME':
         return {name: action.newName}
      default: 
         return: state
   }
}

This is the gist of how a reducer function works.

Using Redux in a React App

First install redux.

npm install redux

Install react-redux.

npm install react-redux

Inside your “src” folder, create a “reducers” folder, and inside the “reducers” folder create a “reducerFunctionName.js” file.

Redux gives you the createStore() function, which when called returns the state. React-redux gives you the “provider” component, where store is passed in and is subsequently passed down everywhere else. React-redux also lets us re-render whenever the specified changes to the state happen via the connect method. Import them both into index.js. Also import your reducer function.

import {createStore} from 'redux';
import {Provider} from 'react-redux'
import reducerFunctionName from './reducers/reducerFunctionName.js'
const store = createStore(reducerFunctionName);
ReactDom.render(
   <Provider store={store}>
      {' '}
      <App />
   </Provider>, 
   document.getElementById('root')
)

Now we can pass the store and access it in every component. To any component that wishes to access the store, import connect from react-redux and modify the export.

import {connect} from 'react-redux'
const mapStateToProps = state => {
   return {
      name: state.name
   }
}
const mapDispatchToProps = state => {
   return {
      changeName: () => dispatch({type: "CHANGE_NAME"})
   }
}
export default connect(
   mapStateToProps,
   mapDispatchToProps
)(App);

mapDispatchToProps allows us to have access to the “changeName” function, which is what we are calling us passing in action.type “CHANGE_NAME” to the reducer. Similarly, name is provided by the mapStateToProps function, which gives us access to the name in the state.

Your components now have access to the state information inside the store object, and are able to access the functions needed to change the state. Just about done!

One final thing. Now what if you had multiple functions? You can theoretically transform all of them into different cases for the same reducer function, but this would be weird; you would have a case for “CHANGE_NAME”, a case for “BUY_FOOD”, and other cases for tons of weird things that have nothing to do with each other. It is better to separate out the reducer functions. This can be done through “combineReducers”.

In the “reducers” folder create a new file called “rootReducer.js”. At the top enter:

import {combineReducers} from 'redux'

Then copy paste your other reducer functions over, but without the export default part in front of them. Then add it to the end.

export default combinedReducers({
   nameChanger,
   colorChanger
})

Note that now to access information from on of the reducers you have to specify the reducer name first now, so instead of “state.name” if name is stored in the nameChanger function you need to do “state.nameChanger.name”.

Go back to your index.js and import rootReducer from “./reducers/rootReducer.js”, you don’t need the earlier individual file imports anymore.

Your finished combinedReducer should look something like this:

import {combineReducers} from 'redux'
function colorChanger(state = {color: "red"}, action) {
  switch (action.type) {
    case 'CHANGE_COLOR':
      console.log(state);
      return {color: action.newColor}
    default:
      return state;
  }
}
function nameChanger(state = {name: "zed"}, action) {
  switch (action.type) {
    case 'CHANGE_NAME':
      console.log(state);
      return {name: action.newName}
    default:
      return state;
  }
}
export default combineReducers({
  nameChanger,
  colorChanger
})

And an example app.js that uses the above reducers might look something like:

import './App.css';
import React, {Component} from 'react';
import {connect} from 'react-redux';
import Something from './containers/Something.js'
class App extends Component {
handleChange = (event) => {
    this.props.changeName(event.target.value)
  }
handleChange2 = (event) => {
    this.props.changeColor(event.target.value)
  }
render () {
    return (
      <div className="App">
        <form>
          <label>
          NewName: <input type="text" onChange={event => {this.handleChange(event)}}/>
          <br/>
          NewColor: <input type="text" onChange={event => {this.handleChange2(event)}}/>
          </label>
          <br/>
          <input type="submit"/>
        </form>
        <p>{this.props.name}</p>
        <p>{this.props.color}</p>
      </div>
    )
  }
}
const mapStateToProps = state => {
  return {
    name: state.nameChanger.name,
    color: state.colorChanger.color
  };
}
const mapDispatchToProps = dispatch => {
  return {
    changeName: (event) => dispatch({type: 'CHANGE_NAME', newName: event }),
    changeColor: (event) => dispatch({type: 'CHANGE_COLOR', newColor: event })
  };
}
export default connect(
  mapStateToProps,
  mapDispatchToProps
)(App);

The default states for name and color are shown at the bottom. The redux state for name and color can be updated through the input bars, and the updated state is shown again with the new name and color.

And we are all done! That was a long ride and took me quite a while to figure out, so hopefully this guide helps you learn Redux faster than I did! Happy coding with your newfound knowledge of Redux!