The problem of finding the right folder structure for a react redux paradigm always ends in a dilemma. The idea is totally subjective and the efficient folder architecture would be different for different use cases.
The one folder structure I ended up with for my use case is as below.
This one particular way of arranging files is mainly inspired from the fact that, I have a team of more than two working on the frontend app development and my primary need is to provide them a structured way to enable communication between components, store, saga and backend apis.
I wanted a team to specifically focus on getting the store populated from backend and another team to look on to the store and develop UI accordingly. With this folder structure I am expecting a complete segregation of api services and presentation component.
├── package.json ├── public │ ├── favicon.ico │ ├── index.html │ └── manifest.json └── src ├── app │ ├── App.js │ ├── App.test.js │ ├── Dashboard │ │ ├── DashboardContainer.js │ │ ├── Dashboard.js │ │ └── index.js │ ├── Login │ │ ├── index.js │ │ ├── LoginContainer.js │ │ ├── LoginForm.js │ │ └── Login.js │ ├── main │ │ ├── Main.js │ │ └── RouteComponents.js │ └── utilities │ ├── messages.js │ ├── routes.js │ └── utils.js ├── constants │ └── Presets.js ├── css │ ├── App.css │ └── index.css ├── index.js ├── serviceWorker.js └── store ├── auth │ ├── actions.js │ ├── index.js │ ├── reducer.js │ ├── saga.js │ └── tests.js ├── index.js ├── rootReducer.js └── rootSaga.js
In the above architecture I have two main folders store and app in the root folder. The store has redux and saga related files. I have individual directories for different modules in store as well as app. Mostly each directory inside store will represent a redux state entity and each directory in app represent a ui module.
Constants and css are two other folders which I maintained in the same level. The name suggests the kind of files I put there.
In this way the store is kind of having its own api which the app can look onto and develop its presentation logic. Also I have the pretty famous ‘container-component’ architecture followed in the app. This will create dump presentation components and container component that carry out logic and provide data to the presentation component. These containers may be connected to store to get the data from redux state.
There is always an argument of having everything related at one place for easy access. This fact is true but debatable for different use cases. I found this architecture more maintainable and easy to use in the long run. Hope it help for someone else. Here is the link to the starter seed.