ReactJS Flux Application directory structure

Question

My team is currently working on a large application being written in ReactJS using Facebook's Flux architecture. It is still in its infancy right now but it is going to grow big very soon. It will have more than 50 small component views, plenty of actions, stores and action-creators.

Currently, our directory structure looks like -

App
|___ module_1
|    |___ components
|    |    |___ component1.react.js
|    |    |___ component2.react.js
|    |___ module1ActionCreators.js
|    |___ module1Constants.js
|    |___ module1store.js
|
|___ module_2
     |___ ... (same structure as above)

One of the problems with this approach is that module_x folders will become increasingly large in number as this app grows.

Does anyone have anything to share about how they structured their app? In our experience, Facebook's example apps (todo and chat) have an architecture suited for small apps but once those stores, components and actions grow in number, that becomes harder to manage.

Thanks in advance.

Jiggle

If a component is general enough and reusable enough, then break it out into its own npm module. If you're generous, open-source it and list it on react-components.com – Dextrad

I think this is the way to go for large apps. But your modules might be too small. My app is currently ordered by type, as shown in @fisherwebdev's answer and every single flux example, but I believe this doesn't really scale well. I already have 25 stores in the store folder. I'm planning to 'order by feature' instead of 'order by type', each of these features will actually be a small 'app', which will plug into the 'core' app. Each of these should only depend on the 'core' module. This is just an idea though. Not designed yet. – Ledezma

@Ledezma did you design something yet to try out? I think this is the right approach though. This is how we did it, except we also again ordered by type inside a feature, causing a huge load of extra folders with only a few files in there. – Lipoid

@Lipoid yes, we finally did this last month. We moved the whole app into a 'core' folder, and are now moving modules out one by one. We also order by type inside the modules, which I agree feels a bit much. Each module has 1 to 5 stores atm. The modules can be left out of the application by removing them from the application entry point, where they are imported and loaded. They only depend on the core. When the core or other modules need to use code from a module, they have to check that the module is available through a facade (modules are also shared on the context in React views). – Ledezma

Answer 1

The usual directory structure is more like this:

js
├── AppBootstrap.js
├── AppConstants.js
├── AppDispatcher.js
├── actions
│   ├── AppActions.js
│   ├── FriendActions.js
│   └── PhotoActions.js
├── components
│   ├── AppRoot.react.js
│   ├── friends
│   │   ├── Friend.react.js
│   │   ├── FriendList.react.js
│   │   └── FriendSection.react.js // a querying-view, AKA controller-view
│   └── photos
│       ├── Photo.react.js
│       ├── PhotoCategoryCard.react.js
│       ├── PhotoCategoryCardTitle.react.js
│       ├── PhotoGrid.react.js
│       └── PhotoSection.react.js // another querying-view
├── stores
│   ├── FriendStore.js
│   ├── PhotoStore.js
│   └── __tests__
│       ├── FriendStore-test.js
│       └── PhotoStore-test.js
└── utils
    ├── AppWebAPIUtils.js
    ├── FooUtils.js
    └── __tests__
        ├── AppWebAPIUtils-test.js
        └── FooUtils-test.js

The css directory usually looks like a mirror of the components directory, with one css file per component. Some folks these days prefer to do all of their styling inline on the component, however.

Don't overthink all that -- there is not always a 1:1 between stores and a querying-view or "section", as there is in this example.

And really you just need to do what is right for your app. This is not dogma. The data flow stuff, the inversion of control and the decoupling of the stores -- these are much more important ideas than how you organize your files.

Lyublin

Indeed, other things are more important than the folder structure. On the other hand the folder structure can give you (or future developers) a very good idea of what's going on. I almost think that the folders/subfolders/files model is not enough, and perhaps an IDE that provides more flexibility would be useful (for example, a folder graph instead of a folder tree). – Fried

vouched here as well: andrewcallahan.com/towards-a-simpler-react-folder-structure – Ragsdale

So wait... whenever you use an action, you have to import "../../someActions"? Same if you need any of your utilities, you'd have to walk up a few folders. Granted, it's already way flatter than my folder structure though. – Lipoid

Answer 2

I also struggled with deciding on initial structure for a large application. I wound up with a very similar structure to yours after having spent time with the application divided into folders based on flux role (ie actions, stores, constants, etc).

For one, if you are using something like Broswerify, relative pathing on your require calls is lovely. Second, not having to hunt down files in various folders when you are working on a particular component is a huge time saver.

For cross cutting concerns, like the dispatcher, helper functions, bootstrapper, etc, I have an equivalent App module. It always feels like there is a sensible place for every file I'm working with, and new devs don't struggle to find correlated files (problematic when your modules might share a prefix).

Since switching I have not looked back.

Ragman