2015-09-17 6 views
38

Ich benutze Redux und ich bin mir nicht sicher, wie ich meine Komponenten zu organisieren, ich denke, das Beste ist, sie in Ordnern mit dem Namen der Hauptkomponente als den Namen der zu halten Ordner und alle inneren Komponenten im inneren:Wie Redux Komponenten/Container zu strukturieren

 
components 
    Common/ things like links, header titles, etc 
    Form/  buttons, inputs, etc 
    Player/ all small components forming the player 
    index.js this one is the top layout component 
    playBtn.js 
    artistName.js 
    songName.js 
    Episode/ another component 

Dann wird in dem Container Ordner, ich habe einen Container pro Seite, dass die einzigen, die ich sind bin Anschluss tatsächlich zu Redux:

 
containers/ 
    HomePageApp.js 
    EpisodePageApp.js 
    ... 

und Dann sind die Aktionen eine pro Top-Komponente, statt einer pro Seite, also im Seitencontainer, den ich Verbindung zu Redux Ich gebe alle Aktionen der auf dieser Seite verwendeten Komponenten weiter. Zum Beispiel:

 
actions/ 
    Player.js 
    Episode.js 
    ... 

Mache ich das richtig? Ich habe nicht viele Informationen über das Googlen gefunden und die, die ich gefunden habe, denke ich, dass sie auf kleine Projekte beschränkt sind.

Danke!

+0

Bitte sehen Sie sich diesen Artikel an: https://jaysoo.ca/2016/02/28/applying-code-organization-rules-to-concrete-redux-code/ – anhldbk

Antwort

85

In den offiziellen Beispielen haben wir mehrere Top-Level-Verzeichnisse:

  • components für “dumb” Komponenten reagieren nicht bewusst Redux;
  • containers für "Smart" React Komponenten mit Redux verbunden;
  • actions für alle Action-Ersteller, wobei Dateiname Teil der App entspricht;
  • reducers für alle Reduzierungen, wobei der Dateiname dem Statusschlüssel entspricht;
  • store für Store-Initialisierung.

Dies funktioniert gut für kleine und mittelgroße Anwendungen.

Wenn Sie modularer und gruppenbezogener Funktionalität zusammen gehen möchten, ist Ducks oder other ways of grouping functionality by domain eine nette alternative Möglichkeit, Ihre Redux-Module zu strukturieren.

Wählen Sie letztlich, welche Struktur für Sie am besten funktioniert.Es gibt keine Möglichkeit, dass Redux-Autoren besser wissen, was für Sie besser ist als Sie.

+0

Ich fand die Redux-Form ist sehr Bequemlichkeit. Aber es verbindet sich mit dem Staat, in welchem ​​Verzeichnis du es finden solltest. – Chris

+1

@Dan - neugierig auf Ihre Gedanken zu [dieser vorgeschlagenen Struktur] (http://marmelab.com/blog/2015/12/17/react-directory-structure.html)? Die Aufgabentrennung von "Container" und "Komponente" war mir zunächst nicht so klar, aber die "Hierarchie" von Containern und Komponenten scheint mit der Dateibenennung verbunden zu sein. – Banjer

+0

@Banjer: Ich habe keine Meinung über die Struktur :-). Nutze, was für dich funktioniert. Ich bin nicht der richtige Ansprechpartner, da ich keine Apps mit Redux erstelle. –

14

Dies ist mehr eine Frage zu Best Practices/Codestil, und es gibt keine klare Antwort. Im Projekt wurde jedoch ein sehr gepflegter Stil vorgeschlagen. Es ist sehr ähnlich zu dem, was Sie derzeit haben.

./react-redux-universal-hot-example 
├── bin 
├── src 
│ ├── components // eg. import { InfoBar } from '../components' 
│ │ ├── CounterButton 
│ │ ├── GithubButton 
│ │ ├── InfoBar 
│ │ ├── MiniInfoBar 
│ │ ├── SurveyForm 
│ │ ├── WidgetForm 
│ │ └── __tests__ 
│ ├── containers // more descriptive, used in official docs/examples... 
│ │ ├── About 
│ │ ├── App 
│ │ ├── Home 
│ │ ├── Login 
│ │ ├── LoginSuccess 
│ │ ├── NotFound 
│ │ ├── RequireLogin 
│ │ ├── Survey 
│ │ ├── Widgets 
│ │ └── __tests__ 
│ │  └── routes.js // routes defined in root 
│ ├── redux 
│ │ ├── init.js 
│ │ ├── middleware 
│ │ │ └── clientMiddleware.js // etc 
│ │ └── modules // (action/creator/reducer/selector bundles) 
│ │  ├── auth.js 
│ │  ├── counter.js 
│ │  ├── reducer.js 
│ │  ├── info.js 
│ │  └── widgets.js 
│ ├── server 
│ │ ├── middleware 
│ │ └── actions // proxy to separate REST api... 
│ └── utils 
│ │ ├── validationUtility.js // utility only (component-level definitions inside respective dir) 
│  └── createDevToolsWindow.js // etc 
├── static 
│ ├── dist 
│ └── images 
└── webpack 
1

Ich habe keine starke Meinung über die Komponente Verzeichnisse, aber Ich mag die Aktionen, Konstanten und Reduzierungen zusammen setzen:

state/ 
    actions/ 
    index.js 
    ... 
    constants.js 
    reducers.js 

I alias state mit mit webpack so in den Container Komponenten kann ich import {someActionCreator} from 'state/actions'; .

Auf diese Weise befindet sich der gesamte statusbehaftete Code in der App an einem einzigen Ort.

Beachten Sie, dass reducers.js in mehrere Dateien aufgeteilt werden kann, indem Sie einfach ein reducers/ Verzeichnis wie actions/ erstellen, und Sie müssten keine Importanweisungen ändern.

3

Ich bevorzuge, intelligente und dumme Komponenten in der gleichen Datei zu behalten, aber Standardexport für intelligente Komponente und Export für Präsentation/dumme Komponenten zu verwenden. Auf diese Weise können Sie Dateirauschen in Ihrer Verzeichnisstruktur reduzieren. Gruppieren Sie Ihre Komponenten auch nach "Ansicht", d. H. (Administration => [admin.js, adminFoo.js, adminBar.js], Inventar => [inventory.js, inventoryFoo.js, inventoryBar.js] usw.).

+0

ich mag diese Idee. –

0

In Redux haben Sie einen Eingangspunkt für Ihre Aktionen (Aktionen/Ordner) und einen Einstiegspunkt für die Reduzierungen (Reduzierer/Ordner).

Wenn Sie mit einer domänenbasierten Codestruktur arbeiten, vereinfachen Sie die Implementierung und Wartung von Domänen/Features ... andererseits erschweren Sie die Komponentenabhängigkeiten und die Wartung von App-Status/Logik.

Wo werden Sie wiederverwendbare Komponenten einsetzen? in Feature/Domain-Ordner? Wenn Sie also eine wiederverwendbare Komponente aus einem anderen Feature/einer anderen Domäne benötigen, müssen Sie eine Abhängigkeit zwischen den Domänen erstellen. mmh nicht so gut für große app!

Wenn Sie Reduzierer kombinieren müssen, nimmt die Domänencode-Struktur das, was sie Ihnen zuvor gegeben hat.

Sie erstellen nur einzelne Redux-Module für jede Domäne/Funktion. Domain-Code-Struktur sollte in einigen/meisten Fällen gut sein, aber das ist nicht Redux.