Component-basierte React-Redux-Projekt Verzeichnisstruktur

Question

Ich weiß, dass es einige Fragen über die react-redux Projektcode Struktur gibt, aber ich hoffe, einen anderen Ansatz zu diskutieren. Die Hauptbibliotheken, die wir verwenden werden, sind: webpack - react - redux - mocha - karma.

Die klassische Ordnerstruktur dafür scheint zu sein:

js 
├── actions 
│ ├── action-for-componentA.js 
├── components 
│ ├── componentA.js 
├── reducers 
│ ├── reducer-for-componentA.js 
└── stores ... 

Dies scheint zu sein, was alle anderen und alle Generatoren da draußen tun. Aber ich denke, das ist nicht die reaktive Art, ein Projekt zu strukturieren. Der Fokus sollte auf der Komponente und nicht auf den einzelnen Konstrukten von react oder redux liegen. Ich würde gerne auf diese Weise darüber nachdenken, wenn Sie eine Schaltfläche in PageX ändern müssen, die in einer Komponentenhierarchie enthalten ist, die mit ComponentX -> ChildOfX beginnt - ich sollte in der Lage sein, die Verzeichnisse genau so zu durchlaufen.

Anstatt einen Komponenten-Ordner mit allen darin geworfen Komponenten würde ich eher wie etwas haben:

js 
├── PageX 
│ ├── action-for-pagex.js 
    ├── componentX.js 
    ├── containerX.js 
    ├── reducerX.js 
    ├── children 
     ├── childrenC 
     ├── childrenB 
      ├── componentB.js 
      ├── reducerB.js 
      ├── ... 
├── PageY 
│ ├── ... 
├── PAgeZ 
│ ├── ... 

Dies wird leichter zu durchqueren und es macht mehr Sinn, wenn man bedenkt, in „reagieren“. Kann jemand etwas sehen, das mit diesem Ansatz schief gehen könnte?

Related reading: http://engineering.kapost.com/2016/01/organizing-large-react-applications/

Answer 1

TL; DR Es gibt keine Standard oder richtige Art und Weise Ihrer Anwendung Code zu strukturieren; Es geht hauptsächlich um deinen Geschmack.

Ich gebe Ihnen eine Antwort aufgrund meiner Erfahrung mit React und Redux. Gerade jetzt bin ich in ein riesiges Projekt involviert, das den R & R Stack nutzt. Unser Tech-Team hatte viel Zeit damit verbracht, über die Ordnerstruktur zu sprechen, da wir eine lineare und skalierbare Art der Kodierung beibehalten sollten.

Grundsätzlich verwenden wir Hybrid-Ansatz, der die beiden von Ihnen zur Verfügung gestellten Beispiele mischt. Der zweite Ansatz wird als "Ordnerstruktur nach Merkmal" bezeichnet, das erste heißt "Ordnerstruktur nach Typ".

Da der React/Redux-Stack einen standardisierten Satz von Dateien verwendet, ist es sehr einfach, den Anwendungsbaum so sauber und skalierbar wie möglich zu halten.

Unser technisches Team hat sich bereit erklärt, dass:

• Jede Hauptkomponente steht unter dem pages Ordner aus.
• Jede Seite kann auch einige Unterkomponenten enthalten.
• Komponenten werden mit einem component.js Einspeisepunkt und kann ein Reduktionsmittel als auch
• Sub-Komponenten, die tatsächlich vererbt werden und aus mehr als einem übergeordneten Komponenten verwenden, werden unter dem shared Ordner abgelegt
• wir auch einige Hilfsfunktionen Ordner pflegen und ein Ordner, der einige Konstanten und Dienstprogramme enthält. Dies liegt vor allem daran, dass unsere Aktions-Dispatcher in unserem Anwendungslebenszyklus gemeinsame Aktionen verwenden.
• Die Anwendung wird von einem einzelnen Container, einem einzelnen Speicher und einem einfachen Einstiegspunkt (app.js) gestartet.
• Wir verwenden ES6-Importanweisungen, um alles an seinem Platz zu halten.

Hier ist eine schematische Version unserer Dateistruktur:

constants 
    -- const.js 
    -- const2.js 
helpers 
    --helperfunc1.js 
shared 
    --Shared Element1 
    --- component.js 
    --- reducer.js 
    --Shared Element2 
    --- component.js 
    --- reducer.js 
specs 
    -- spec1.js 
    -- spec2.js 
pages 
-Page1 
-- Subpage1 
    --- component.js 
    --- reducer.js 
    -- Subpage2 
    --- component.js 
    --- reducer.js 
    -- component.js 
-- reducer.js 
-Page2 
-- component.js 
-- reducer.js 
... 
container.js 
app.js 
reducer.js 

Wie wir Codierung gehalten, das Hinzufügen von Funktionen und unsere Anwendung erhalten, schrieben wir einige Vor diesem Ansatz nach unten: - Dateinamen sind ziemlich kurz und einfach zu lesen. - Die Dateistruktur ist einfach zu folgen. - Testen hat verdammt einfach gemacht wie das Importieren der Komponente und des Reduzierers aus einem Ordner - Benennung Engpässe wurden weggeworfen. - Wir hatten weniger Benennungsprobleme und unter demselben Ordner. - Noch einmal, TableDataComponent.js ist ausführlicher und schwer zu folgen als table/component.js. - Da verschachtelte React-Komponenten ein wesentlicher Bestandteil des Frameworks sind, verfolgt die Ordnerstruktur diese Logik. Innere Codeebenen werden von den oberen gerenderten Elementen übernommen. - Action Reducer sind auch problemlos bootstrapped.

Ich würde vorschlagen, etwas Zeit zu verbringen, dieses wundervolle Reddit thread und dieses article außerdem zu lesen, einige ehrfürchtige Punkte werden oben erwähnt.

Answer 2

Ich habe kam mit dieser Struktur und es funktioniert ziemlich gut