Fractal Project Structure with React and Redux - pros/cons [closed]

Question

I would like to know what are the pros and cons of using a Fractal Structure in a React + Redux project and I was wondering if anyone has any experience with this approach or if there are pitfalls which are not immediately visible from the docs.

(Fractal structure) Also known as: Self-Contained Apps, Recursive Route Hierarchy, Providers, etc

Context: I'm looking at react-redux-starter-kit and it suggests to use a fractal structure to organize the folders. If I understood well, this approach require to organize the project folders by feature and nest the route recursively.

So, if I have a "events" resources where

• /events lists all the events
• /events/new show a form to insert a new event
• /events/1/details show the details about the event with id 1

Starting from the boilerplate, I have to add the new route folder like:

├── src                      # Application source code │   ├── main.js              # Application bootstrap and rendering │   ├── components           # Reusable Presentational Components │   ├── containers           # Reusable Container Components │   ├── layouts              # Components that dictate major page structure │   ├── static               # Static assets (not imported anywhere in source code) │   ├── styles               # Application-wide styles (generally settings) │   ├── store                # Redux-specific pieces │   └── routes               # Main route definitions and async split points │       ├── index.js         # Bootstrap main application routes with store │       ├── Root.js          # Wrapper component for context-aware providers ~       ~ │       ├── Events           # Fractal route │       │   ├── index.js     # Route definitions and async split points │       │   ├── components   # Presentational React Components │       │   ├── container    # Connect components to actions and store │       │   ├── modules      # Collections of reducers/constants/actions or single DUCK module │       │   └── routes       # Fractal sub-routes (** optional) <------------- │       │       │ │       │       └── New │       │       │   ├── index.js     # Route definitions and async split points │       │       │   ├── assets       # Assets required to render components │       │       │   ├── components   # Presentational React Components │       │       │   ├── container    # Connect components to actions and store │       │       │   ├── modules      # Collections of reducers/constants/actions or single DUCK module │       │       │   └── routes       # Fractal sub-routes (** optional) <------------- │       │       │ │       │       └── Details │       │           ├── index.js     # Route definitions and async split points │       │           ├── assets       # Assets required to render components │       │           ├── components   # Presentational React Components │       │           ├── container    # Connect components to actions and store │       │           ├── modules      # Collections of reducers/constants/actions or single DUCK module │       │           └── routes       # Fractal sub-routes (** optional) <------------- ~       ~ │       └── NotFound         # Capture unknown routes in component ~ 

With New and Details folder nested under the root Event folder.

The docs highlight this main pros:

• It scales better than a flat directory structure, with folders for components, containers, etc.
• Routes can be be bundled into "chunks" using webpack's code splitting and merging algorithm
• Since logic is self-contained, routes can easily be broken into separate repositories and referenced with webpack's DLL plugin for flexible, high-performance development and scalability.

Answer 1

The one drawback or con I've encountered with a similar structure is if/when things starts being used outside of it's hierarchy, then you have to use a lot of ../../.. in your imports.

For example, say that you get the requirement that on your StartPage route you should show the details for the most recent event.

so now it looks like:

routes ├─Events │     ├─New │     ├─Details ├─StartPage        ├─ components   // here somewhere you import ../../Events/Details 

It's not the end of the world, but your nice hierarchy isn't quite as strictly hierarchical anymore.

Answer 2

The one drawback that I can speak to is not being able to at a glance view all available routes and their respective components, this can be mitigated by making some descriptive comments, but it does increase the complexity of your route configuration. I would also try to keep nesting folders to minimum since there is cognitive load associated with getting the levels of nesting right in your import statements i.e ../../../../../ these can get out of hand if you have many nested routes.