What is the better way to structure a large redux project?

Question

I recently started to using Redux, and so far everything has been going fairly well. However, as my application grows, I am starting to question what are the best practices for it's structure. Most tutorials and the documentation gives you very small examples, so I am not sure what direction I should take this.

Basically my application is massive, and it is separated in various modules that are completely independent of each other.

From my understanding an app is something that does one single thing, so I am writing my code considering each separate module it's own app, since they are completely independent and each do a completely different task.

As it is now, I structured am making it in a way that each module has it's own little redux structure. So the folders are as follows:

- module1
   - actions
   - reducers
   - containers
   - components

- module2
  - actions
  - reducers
  - containers
  - components
  ...

And obviously they get all put together on a main App file, where they are all routed.

As my application grows, I am unfortunately noticing that a lot of the code is in fact repeated. So I am starting to wonder if my approach was correct given the circumstances, or if it would be better to just go with all modules sharing everything, sortav like this:

- actions
  -module1Actions
  -module2Actions
- reducers
  -module1Reducers
  -module2Reducers
- containers
  -module1Containers
  -module2Containers
- components
  -module1Components
  -module2Components

Can someone shed some light on what would be the better approach?

Answer 1

Yeah, your approach is absolutely correct – and a lot of boilerplate code (which is quite tricky to avoid) is just a feature of Redux, not a bug. So, idiomatic application has a lot of modules, just like you have.

Unfortunately, it is really hard to unify it, because reducers are pretty unique from a project to project, so I don't know any successful and popular implementation. There is a mobX library, which eliminates merging state (because you can just mutate data there), but it seems it works only in small projects.

So, the single advice from my own experience which I can give to you is to write modules factory, which will produce actions, reducers and selectors, and if you have similar structure in your endpoints, when it will decrease a lot of boilerplate. But unique things (like login, for instance) is basically impossible to generalize.

Answer 2

There's a number of approaches to React/Redux app structure out there. There's also been a lot of experimentation with ways to better encapsulate logic and chunks of functionality. One of the tradeoffs for Redux is that the global state makes things easier to deal with at the app level, but encapsulation can be more difficult.

My my React/Redux links list has a couple categories with relevant info. I have a section with articles on React/Redux project structure. There's also a number of articles and code attempts that try to tackle the "fully encapsulated and reusable chunk of logic" issue. I have links to those articles and discussions in the Redux Techniques#Encapsulation section.

On a semi-related note, there's a whole bunch of libs that try to help solve the "per-component state in Redux" concept. Most of them basically set up a top-level slice of your state and store component data keyed by ID in there, and have ways to generate IDs for the components. I've got a list of them in my Redux addons catalog, in the Component State page. I haven't yet actually tried any of them myself, just cataloged them.

Finally, the Redux FAQ has some relevant info on the topic, at http://redux.js.org/docs/faq/CodeStructure.html#structure-file-structure .