Folder organization of components vs containers

[sammylupt]

I'm writing a React Native / React Router / Redux app that has 6 main screens, each of which is its own route and is powered by a connected React component.

This is my file organization structure:

components/
    foo/
        componentA.js
        componentB.js
    bar/
        componentC.js
        componentD.js
    sharedComponentA.js
    sharedComponentB.js
containers/
    fooContainer.js
    barContainer.js

My app is small enough that the only components that are connected to the Redux store are those that live in my containers folder. Those containers pass their props down to their children, which live in the components/ subfolder that matches the name of the container.

If I eventually want to connect a component, ie components/foo/componentA, my organizational structure's division of component vs container implies that I should move componentA to the containers/ folder. I don't like that I will have to change all of my file paths in my imports/exports inside this component just because I have connected it to the Redux store.

I've begun to view the components inside my containers/ folder as top level concepts or scenes in the app and accordingly thinking about how to structure my app with that in mind.

Here's one idea I am thinking of:

scenes/
    foo/
        index.js (container)
        componentA.js
        componentB.js
    bar/
        index.js (container)
        componentC.js
        componentD.js
components/
    sharedComponentA.js
    sharedComponentB.js

In the above structure, files such as componentA or componentB could be components or containers, though index.js is always clearly the top level container for the given scene.

I know there's no right answer to this question. Interested in hearing anyone's experiences with this problem and how they addressed it. Thanks!

[markerikson]

The Redux FAQ has some discussion and links on folder structure: http://redux.js.org/docs/FAQ.html#structure-file-structure . Also, non-Redux-specific, but https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33 is pretty good too.

While the "container" vs "presentational" component distinction is great conceptually, I'm definitely leaning away from it as a file structure approach. I can see some reasons to keep folders for "actions" and "reducers", say, but if nothing else, I'd lean towards organizing components by feature or something.

[johnsoftek]

I much prefer organization by feature rather than file type. I have an app
with 17 "features", many of them with just two files each, but some with 9
or 12 files.

Redux is only one among many technologies where the example apps use the,
imo, less scalable breakdown by file type rather than feature.

On 15 April 2016 at 11:57, Mark Erikson notifications@github.com wrote:

The Redux FAQ has some discussion and links on folder structure:
http://redux.js.org/docs/FAQ.html#structure-file-structure . Also,
non-Redux-specific, but
https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33
is pretty good too.

While the "container" vs "presentational" component distinction is great
conceptually, I'm definitely leaning away from it as a file structure
approach. I can see some reasons to keep folders for "actions" and
"reducers", say, but if nothing else, I'd lean towards organizing
components by feature or something.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1618 (comment)

[gaearon]

File structure for examples was chosen when Redux was one week old for tiny small apps that those examples were. It was never intended as a “definitive file structure” because Redux is a state management library, not a file organization recipe. Same for using Webpack, or semicolons: this is just what was convenient for example authors, and has nothing to do with how you’d write your apps. You don’t ask Backbone or Lodash to pick file structure for you; why is Redux any different?

Perhaps, the reason why the file structure of the initial examples was adopted was because it solidify visually, what people had not solidify mentally. I know for me observing the file structure assisted me in my understanding of redux. That being said, I dont think thats a compelling reason for a "definitive file structure." Especially, since there is a multitudes of different file structures out there, which out of all of them i've enjoyed the ducks methodology the most. https://github.com/erikras/ducks-modular-redux

[gaearon]

The problem I have with “ducks” is it groups action creators together with reducers, thus often making people assume those map one to one. One of the strengths of Redux (and Flux) is that distant parts of the state may update in response to the same action. Putting action creators with reducers make it seem like actions are local to the module, and “snooping” on actions from another module is an anti-pattern, but this just isn’t true.

Great thoughts @gaearon, I guess this only further proves that to demand a file structure from redux would be misleading. This seems to be one of those things that evolve within the community either way. As boilerplates arise and get refined, so do file structure suggestions.

[sunyang713]

@gaearon In regards to 'ducks,' what if actions are 1-1 with reducers, and any 'action' that would affect two or more reducers would be written into a 'saga' via 'redux-saga'?

[gaearon]

I think this is significantly more complex than just having multiple reducers handle the same action, especially considering this just works out of the box already.

[aweary]

FWIW what we do with "ducks" is re-export all the actions from a singular actions.js file so that any action can be imported into another reducer without feeling like we're reaching into another "scope" or whatever

[mmazzarolo]

Hey, just wanted to let you know that you can find an interesting discussion on folder organization here and here.

@skellock

[markerikson]

@mmazzarolo , @skellock : Hmm. Skimmed those quickly, and they do look interesting. I'll have to re-read those in more depth later. Any chance you could maybe turn those into some blog posts summarizing what you've come up with? Any similarities with https://www.smashingmagazine.com/2016/09/how-to-scale-react-applications/ ?

[mmazzarolo]

@skellock did you already wrote something about it? Otherwise I would gladly write a blogpost in the next few days. Let me know 🎱

[skellock]

All yours @mmazzarolo! Thanks dude. Much of this refactor was inspired by your comments.

[markerikson]

Cool. Ping me when it's done - always looking for more articles on Redux architecture and organization.