How to Start ReactJS Development Fast. Part 2: Best Practices
Tags: react, webdev, showdev, redux
Published: 2019-12-16 09:18:46

---
title: How to Start ReactJS Development Fast. Part 2: Best Practices
published: true
description: How to start ReactJS development fast? Read the article where our React experts overview such tools as CRA, Next.js, and Gatsby and provide our best practices.
tags: react, webdev, showdev, redux
cover_image: https://thepracticaldev.s3.amazonaws.com/i/b2so4l2iwblslalylbbi.jpg
---

Today, we are going to provide you with the second part of the article [How to Start ReactJS Development Fast: 3 Solid Tools and Best Practices](https://www.codica.com/blog/how-to-start-reactjs-development-fast-3-solid-tools-and-best-practices/). Here we want to provide you with our best practices on React-Redux project structure to give a better understanding of the application architecture.

## Best practices on React-Redux project structure

In this section, we want to share our base recommendations on [how to structure your React-Redux project files and code](https://github.com/codica2/react-app-best-practice) so that your application stays maintainable as it scales, based on our experience. The guideline is based on improving the create-react-app setup.

Initially, we decided to separate React and Redux into different folders. Thus, it simplifies the process of applying any changes or adding a new feature. Redux-specific code (reducers, actions, action types) is split by feature-first pattern [Re-Ducks](https://github.com/alexnm/re-ducks). Here is an example of a project structure we use in practice:

```
src/
├── state => redux specific code (Re-Ducks)
|   ├── ducks/
|   |   ├── duck/
|   |   |   ├── types.js
|   |   |   ├── actions.js
|   |   |   ├── selectors.js
|   |   |   ├── reducers.js
|   |   |   ├── tests.js
|   |   |   ├── index.js
|   utilities/ => global constants and helper functions
|   views/
|    ├── routes/       => base router
|    ├── components/   => feature-first components
|    ├── pages/        => layouts, related to routes
|    ├── styled/       => StyledComponents
|    └── UI/           => reusable components
```

We prefer to create the React components first and then the corresponding Redux code. It allows us to have a general understanding of the data requirements.

The /ducks directory has a fixed pattern. We use a modified version of the ducks pattern to organize our Redux code:

```
ducks/
├── duck/
|   ├── actions.js
|   ├── reducers.js
|   ├── types.js
|   ├── utils.js
|   ├── selectors.js
|   └── index.js
└── index.js
```

Now, let’s discuss each /duck folder file to understand why is it important and what it stands for.
### Project structure files
**types.js**
This file contains string literals for our action types. It provides an easy reference to the actions available. These strings are exported as an object literal which can then be imported into your reducers and action creators instead of hard-coding them. Although maintaining a separate file that contains the action types is optional, it is highly recommended in organizing the structure of your project files.

```react
// types.js
export const SOME_YOUR_TYPE = "SOME_YOUR_TYPE";
```

**actions.js**
In this file, we define all the actions. Actually, some developers tend to separate async actions and action creators, but we don’t think it is pretty crucial.

```react
// actions.js
import types from './types.js';

// action creator
const someAction = payload => ({
  type: types.SOME_YOUR_TYPE,
  payload
});
```

Actually, we use redux middlewares such as [redux-thunk](https://www.npmjs.com/package/redux-thunk) or [redux-promise-middleware](https://github.com/pburtchaell/redux-promise-middleware) for dispatching async actions.

**reducer.js**
The reducer is required to update the state. We create a single reducer for each action using `createReducer`. We use this command to create reducers, not the basic switch-case template. The matter is it's very useful, for example, if you need to scope out part of a reducer to use variables with the same name in several `case` statements.

```react
// reducer.js
const someReducer = createReducer(initialState)({
  [types.YOUR_ACTION_TYPE]: (state, action) => {
    return {
      ...state,
      some_prop: action.payload
    };
  },

  [types.SOME_ANOTHER_TYPE]: (state, { payload: { data } }) => ({
    ...state,
    data,
    loading: false
  }),

  [types.MAY_BE_YOU_WANT_RESET]: (state, action) => ({
    ...initialState
  })
});
```

**selectors.js**
In Redux, a selector is a piece of logic that receives a certain piece of state from the store. Additionally, a selector can compute data from a given state, allowing the store to hold only basic raw data. Selectors are usually used as a part of the binding between the store and the container components.

We use the [Reselect](https://github.com/reduxjs/reselect) library to create selectors. This library is not the only way or the requirement to create selectors. However, it gives several advantages in terms of developer experience and performance:

* Selectors created through a createSelector function are memoized. It means that the function remembers the arguments passed-in the last time it was invoked. Thus, it doesn’t recalculate the result if the arguments are the same.
* Selectors can be composed/chained together easily. This way, each selector stays small and focused on one task.

Here is a simple **filteredTodos** selector example to demonstrate how it works:

```react
// selector.js

import { createSelector } from 'reselect';

const todoSelector = state => state.todo.todos;
const searchTermSelector = state => state.todo.searchTerm;

export const filteredTodos = createSelector(
  [todoSelector, searchTermSelector],
  (todos, searchTerm) => {
    return todos.filter(todo => todo.title.match(new RegExp(searchTerm, 'i')));
  }
);
```

With the help of this library, we can use the **filteredTodos** selectors to get all the todos if there’s no `searchTerm` set in the state, or a filtered list otherwise.

Also, we can get all the todos in a flat shape in conjunction with normalized data:

```react
import { denormalize } from 'normalizer';

import { todo } from '../../schemas';

const getById = state => state.todo.byId;

const getAllIds = state => state.todo.all;

export const makeAllTodos = () =>
 createSelector(
   [getAllIds, getById],
   (all, todos) =>
     denormalize(all, [todo], { todos}),
 );
```

**index.js**
Here, we re-export all our actions, selectors and our reducer as a default export.

```react
// index.js
export * from './actions';
export * from './selectors';

export { default } from './reducer';
```

Finally, our duck folder is ready!

This is the way we organize our React app structure to make the application maintainable when it scales.
## Conclusion
At Codica, we have created our [Best Practices on React-Redux project development](https://github.com/codica2/react-app-best-practice) that can help you understand your application architecture and build a well-structured code. Our experts believe these recommendations will help you properly organize your project structure to make it easy-to-maintain and easy-to-read.

Stay tuned and check our full article: [How to Start ReactJS Development Fast: 3 Solid Tools and Best Practices](https://www.codica.com/blog/how-to-start-reactjs-development-fast-3-solid-tools-and-best-practices/).