How to structure Redux components/containers

Question

I’m using redux and I’m not sure about how to organize my components, I think the best is to keep them in folders with the name of the main component as the name of the folder and all inner components inside:

components
  Common/   things like links, header titles, etc
  Form/     buttons, inputs, etc
  Player/   all small components forming the player
    index.js  this one is the top layout component
    playBtn.js
    artistName.js
    songName.js
  Episode/  another component

Then, in the containers folder, I’ve one container per page, that are the only ones I'm actually connecting to Redux:

containers/
  HomePageApp.js
  EpisodePageApp.js
  ...

and then the actions are one per each top component, instead of one per page, so in the page container that I connect to Redux I pass all the actions of the components used in that page. For example:

actions/
  Player.js
  Episode.js
  ...

Am I doing this right? I haven't found much information about it googling, and the ones I've found I think they are limited to small projects.

Thanks!

Hanover

Please have a look at this article: jaysoo.ca/2016/02/28/… – Cyrenaica

Answer 1

In the official examples we have several top-level directories:

• components for “dumb” React components unaware of Redux;
• containers for “smart” React components connected to Redux;
• actions for all action creators, where file name corresponds to part of the app;
• reducers for all reducers, where file name corresponds to state key;
• store for store initialization.

This works well for small and mid-level size apps.

When you want to go more modular and group related functionality together, Ducks or other ways of grouping functionality by domain is a nice alternative way of structuring your Redux modules.

Ultimately choose whatever structure works best for you. There is no way Redux authors can know what’s convenient for you better than you do.

Sidwel

I found the redux-form is very convenience. But it connect with state, what directory you think it should be. – Raynell

@Dan - curious on your thoughts on this proposed structure? The container vs. component separation of duties wasn't as clear to me at first, but the "hierarchy" of containers vs. components seems built in with the file naming. – Untruthful

@Banjer: I don’t have any opinion on the structure :-). Use what works for you. I’m not the right person to ask because I’m not building apps with Redux. – Sidwel

Right on, I'll pick a style and run with it. But going forward, we will want your opinion on everything...hows this shirt look? – Untruthful

Answer 2

This is more a question about best practices / code style, and there is no clear answer. However, a very neat style was proposed in the React redux boilerplate project. It's very similar to what you currently have.

./react-redux-universal-hot-example
├── bin
├── src
│   ├── components // eg. import { InfoBar } from '../components'
│   │   ├── CounterButton
│   │   ├── GithubButton
│   │   ├── InfoBar
│   │   ├── MiniInfoBar
│   │   ├── SurveyForm
│   │   ├── WidgetForm
│   │   └── __tests__
│   ├── containers // more descriptive, used in official docs/examples...
│   │   ├── About
│   │   ├── App
│   │   ├── Home
│   │   ├── Login
│   │   ├── LoginSuccess
│   │   ├── NotFound
│   │   ├── RequireLogin
│   │   ├── Survey
│   │   ├── Widgets
│   │   └── __tests__
│   │       └── routes.js // routes defined in root
│   ├── redux
│   │   ├── init.js
│   │   ├── middleware
│   │   │   └── clientMiddleware.js  // etc
│   │   └── modules // (action/creator/reducer/selector bundles)
│   │       ├── auth.js
│   │       ├── counter.js
│   │       ├── reducer.js  
│   │       ├── info.js
│   │       └── widgets.js
│   ├── server
│   │   ├── middleware
│   │   └── actions // proxy to separate REST api...
│   └── utils
│   │   ├── validationUtility.js // utility only (component-level definitions inside respective dir)
│       └── createDevToolsWindow.js  // etc
├── static
│   ├── dist
│   └── images
└── webpack

Hayse

Answer 3

I prefer keeping smart and dumb components in the same file, but use default export for smart component and export for presentation/dumb components. This way you can reduce file noise in your directory structure. Also group your components by "View" i.e. (Administration => [admin.js, adminFoo.js, adminBar.js], Inventory => [inventory.js, inventoryFoo.js, inventoryBar.js], etc).

Curlicue

i like this idea. – Stopcock

Answer 4

I have no strong opinion about the component directories, but I like putting the actions, constants and reducers together:

state/
  actions/
    index.js
    ...
  constants.js
  reducers.js

I alias state with with webpack so in the container components I can import {someActionCreator} from 'state/actions';.

This way, all the stateful code in the app resides in a single place.

Note that reducers.js could be split into multiple files simply by making a reducers/ directory like actions/ and you wouldn't have to change any import statements.

Foresee

Answer 5

In Redux you have one entry point for your actions (actions/ folder) and an entry point for the reducers (reducers/ folder).

If you go with domain-based code structure you simplify domain/feature implementation and maintenance... on the other hand you are complicating component dependencies and app state/logic maintenance.

Where are you gonna put reusable components? inside feature/domain folder? so if you need a reusable component from other feature/domain you need to create a dependency between domains? mmh not so good for large app!

When you have to combine reducers, domain-code-structure takes away what it gave you previously.

You are only creating single redux modules for each domain/feature. domain-code-structure should be good in some/most cases, but this is not Redux.

Champ

Answer 6

I have a boilerplate with react, redux folder structure and it's being used for many company projects. You can check it out here: https://github.com/nlt2390/le-react-redux-duck

Vinous

Repositories might change location, your answer here will stay. So please summarize what you did in your project to make your answer more useful. See also: meta.stackexchange.com/a/8259/266197 – Damal