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.

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.

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.