React-boilerplate: Suggestions for folder structure in a large app

[loicginoux]

Hello,
First, thank you for this boilerplate which is really solid and it's saving us a lot of work for the setup.
I am starting with this boilerplate and after few hours of development, I already have about 20 containers and components and few pages. it seems like using just a separation between containers and components is not enough and too flat. I am thinking ahead and I guess, when the app will be finished, this file structure will be hard to use.

I wanted to know if anyone has adopted a different structure when dealing with an app with hundreds of containers and components.
I read few issues talking about the subject (the major one being #27, I guess) and people seems to go with the stucture described in this gist which seems to be cleaner and easier to manage.

I wanted to know if people working with larger apps have used this structure, what do you think of it ? any downside ? Did you try another organization ?

note: I put this here as well, the LIFT structure principle which is from angular but can be applied to any file structure.

[justingreenberg]

i wrote this last year, based on my experience building a huge app, you may find it helpful:

https://github.com/davezuko/react-redux-starter-kit#application-structure
https://github.com/davezuko/react-redux-starter-kit/wiki/Fractal-Project-Structure

let me know if you have any questions :)

[loicginoux]

Thank you, that's some food for thoughts. I remember having read about this fractal project structure, I like the way everything is well encapsulated but for now I would rather have one file describing the routes, it's easier to follow at a glance.
I will refactor and split routes in their own files when I have too many of them.
I am also thinking about modifying the routes from POJO to JSX, just for clarity. I don't see for now the advantage to have them defined as plain javascript...

[justingreenberg]

I remember having read about this fractal project structure, I like the way everything is well encapsulated but for now I would rather have one file describing the routes, it's easier to follow at a glance.

this is _actually_ how i structure my projects too ;) with a huge app, eventually you will want to create split points that return a different set of child routes based on state ie. using getChildRoutes which is usually where i break them into separate files

I am also thinking about modifying the routes from POJO to JSX, just for clarity. I don't see for now the advantage to have them defined as plain javascript...

POJO route route definitions are more amenable to async matching and code splitting, since JSX routes cannot define getChildRoutes or getIndexRoute

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.