Struttura del progetto frattale con React e Redux - pro/contro

Question

Vorrei sapere quali sono i pro e i contro dell'uso di una struttura frattale in un progetto React + Redux e mi chiedevo se qualcuno ha qualche esperienza con questo approccio o se ci sono insidie ​​che non sono immediatamente visibili dai documenti.

(struttura frattale) Conosciuto anche come: Indipendente Apps, ricorsiva percorso Gerarchia, fornitori, ecc

Contesto: sto guardando react-redux-starter-kit e suggerisce di usare un fractal structure per organizzare le cartelle. Se ho capito bene, questo approccio richiede di organizzare le cartelle del progetto per feature e annidare il percorso in modo ricorsivo.

Quindi, se ho una risorse "eventi" dove

• /events elenca tutti gli eventi
• /events/new mostrano un modulo per inserire un nuovo evento
• /events/1/details mostrano i dettagli sull'evento con id 1

A partire dallo standard, devo aggiungere la nuova cartella di percorso come:

├── 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 
~ 

Con New e Details cartelle nidificate sotto la cartella principale Event.

La documentazione evidenziano questa principali vantaggi:

• È scalabile meglio di una struttura di directory piatta, con le cartelle per componenti, contenitori, ecc
• percorsi possono essere essere impacchettati in "blocchi" usando algoritmo di suddivisione e fusione del codice webpack
• Poiché la logica è autonoma, i percorsi possono essere facilmente suddivisi in repository separati e referenziati con il plugin DLL di Webpack per flessibile, sviluppo ad alte prestazioni e d scalabilità.

Answer 1

L'uno svantaggio o contro che ho incontrato con una struttura simile è se/quando le cose inizia a essere utilizzate al di fuori di esso è la gerarchia, quindi è necessario utilizzare un sacco di ../../.. nelle importazioni.

Ad esempio, supponiamo di avere il requisito che sulla rotta StartPage sia necessario mostrare i dettagli dell'evento più recente.

così ora sembra che:

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

Non è la fine del mondo, ma la gerarchia bello non è più altrettanto rigorosamente gerarchico.

Answer 2

L'unico inconveniente a cui posso parlare non è la possibilità di visualizzare tutti i percorsi disponibili e i rispettivi componenti, at a glance, questo può essere mitigato facendo alcuni commenti descrittivi, ma aumenta la complessità della configurazione del percorso. Vorrei anche provare a mantenere le cartelle di nidificazione al minimo in quanto vi è un carico cognitivo associato all'ottenimento dei livelli di nidificazione direttamente nelle istruzioni di importazione i.e ../../../../../ queste possono sfuggire di mano se si hanno molte rotte nidificate.