3 Basic Principles You MUST Know Before Using Redux

Redux is a library for managing states that follow the principles of the flux architecture. We won't go too deep in technical details, but we'll cover the basic principles that you'll need to understand this framework. Redux is an independent framework, but for the sake of brevity, we'll assume that we are using it with React.

Global state (store)

Unlike React’s standard architecture, the components state isn’t stored
in its component class (with exception to specific cases). All data from
the view or received by API’s, databases or any other endpoint is
stored in a single global object called the store (is also common to
name it the state).

The goal of the store is to link each component property to one of its
properties. This way, every time that a property data is updated, the
component its rendered again using the new data instead. Following this
concept, let's assume we have an app that requires user authentication
and todo-list features. In this case, our store would look something
like this:

{
  auth: {
    username: 'admin',
    name: 'John Doe'
  },
  todos: [
    'Brew coffee',
    'Read Redux article',
    'Watch AI documentary'
  ],
} 

See that we stored data about two different features in a single object.

Actions

"Actions are payloads of information that send data from your application to your store. They are the only source of information for the store." - redux.js.org

That means that every time that you need to change a property data in
the store, you need to dispatch an action. In a more technical
description, actions are objects that contain a type property
(responsible for informing the store about what kind of action it is
supposed to execute) and the payload (the actual data to be altered).

// Action example

{
  type: 'LOGIN',
  payload: {
    username: 'admin',
    password: '123456'
  },
}

It is good practice to maintain all data (except the type) inside a single property called payload.

Still thinking about the auth feature, we could implement three actions:

LOGIN_REQUEST

LOGIN_SUCCESS

LOGIN_ERROR

The first one would be dispatched directly by the user, while the other
two would be dispatched by the app is based on the response of the auth
API.

To dispatch an action in our app, we need to make it the returned object
of a pure function (action creator). This function will be made
available for every component of the app.

const authUser = (username, password) => ({
  type: 'LOGIN_REQUEST',
  payload: {
    username,
    password
  }
});

Reducers

Although actions can listen to events triggered by the user or by the
app, they can't change the state of our store. To make any change in the
store, we need to use our middlemen, reducers.

Every reducer listens to every action dispatched by the app. It is up to
us to define which of these actions it needs to take into account and
do something about. For the auth feature, we would have a reducer to
deal with the auth data of the user:

const authenticated = (state = false, action) => {
  switch(action.type) {
    case 'LOGIN_SUCCESS':
      return true;
    case 'LOGOUT'
      return false;
    default:
      return state;
  }
}

The first argument received by the reducer should always be the current
state and we must give it the appropriate default value (in this case,
false). The second argument is our action object that holds the type and
payload data.

Is common practice to use a switch statement to assess the action type
and return a value accordingly. This is what makes sure that our reducer
only changes the state of the store with specific actions and return
the default value for the other ones, preserving the state integrity.

Every reducer controls a single property of the store's state.
Nonetheless, the property's value can be yet another object too. This
gives us more possibilities for our app, for instance, separating the
state in "modules":

// State representation

{
  auth: {
    authenticated: true,
  },
  user: {
    username: 'admin',
    name: 'John Doe'
  },
  token: 'somecooltoken',
  // ... other properties
}

Reducers have the edge to be super powerful and change more than one
data in the state as long as they are encapsulated in the same
object/module that the reducer is responsible for.

In conclusion, these are the basics you need to understand to work with
Redux, but as your app grows in complexity, you can make use of even
more advanced features like middlewares

I hope this was a helpful introduction to Redux and that you feel more motivated to use Redux to its full extend from now on.

Previously published at https://medium.com/@mrcsmedeiros/3-basic-principles-you-must-know-before-using-redux-fc32917577ab