Struttura della directory dell'applicazione ReactJS Flux

Question

Il mio team sta attualmente lavorando su una grande applicazione scritta in ReactJS utilizzando l'architettura Flux di Facebook. È ancora nella sua infanzia in questo momento, ma sta per diventare grande molto presto. Avrà più di 50 piccole visualizzazioni di componenti, un sacco di azioni, negozi e creatori di azioni.

Attualmente, la nostra struttura di directory assomiglia -

App 
|___ module_1 
| |___ components 
| | |___ component1.react.js 
| | |___ component2.react.js 
| |___ module1ActionCreators.js 
| |___ module1Constants.js 
| |___ module1store.js 
| 
|___ module_2 
    |___ ... (same structure as above) 

Uno dei problemi con questo approccio è che le cartelle module_x diventeranno sempre più grandi in numero come questo app cresce.

Qualcuno ha qualcosa da condividere su come hanno strutturato la loro app? Nella nostra esperienza, le app di esempio di Facebook (todo e chat) hanno un'architettura adatta per le piccole app, ma una volta che tali negozi, componenti e azioni crescono di numero, diventa più difficile da gestire.

Grazie in anticipo.

Answer 1

La solita struttura di directory è più simile a questo:

 
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 

La directory css di solito appare come uno specchio della directory componenti, con un file css per componente. Alcune persone in questi giorni preferiscono fare tutto il loro stile in linea sul componente, tuttavia.

Non pensare troppo tutto ciò che - non c'è non sempre un rapporto 1: 1 tra i negozi e un'interrogazione-view o "sezione", in quanto v'è in questo esempio.

E in realtà devi solo fare ciò che è giusto per la tua app. Questo non è dogma. Il flusso di dati, l'inversione del controllo e il disaccoppiamento dei negozi - sono idee molto più importanti di come organizzi i tuoi file.

Answer 2

Ho anche faticato a decidere sulla struttura iniziale per una grande applicazione. Mi sono ritrovato con una struttura molto simile alla tua dopo aver trascorso del tempo con l'applicazione divisa in cartelle basate sul ruolo di flusso (cioè azioni, negozi, costanti, ecc.).

Per uno, se si utilizza qualcosa come Broswerify, il percorso relativo alle chiamate di richiesta è piacevole. In secondo luogo, non dover cacciare i file in varie cartelle quando si lavora su un particolare componente è un enorme risparmio di tempo.

Per problemi di taglio trasversale, come il dispatcher, le funzioni di supporto, il bootstrapper, ecc., Ho un modulo App equivalente. Sembra sempre che ci sia un posto sensato per ogni file con cui sto lavorando, e i nuovi sviluppatori non hanno difficoltà a trovare file correlati (problematico quando i tuoi moduli potrebbero condividere un prefisso).

Dal momento che il passaggio non ho guardato indietro.