web-dev-qa-db-fra.com

Comment structurer les composants/conteneurs Redux

J'utilise Redux et je ne sais pas comment organiser mes composants. Je pense que le mieux est de les conserver dans des dossiers avec le nom du composant principal comme nom du dossier et tous les composants internes qu'il contient: 

Composants
 Communs/choses comme les liens, les titres d'en-tête, etc. Formulaire/boutons, entrées, etc. Lecteur/tous les petits composants constituant le lecteur 
 index.js celui-ci est le composant de disposition supérieur 
 playBtn.js 
 artistName.js 
 songName.js 
 Épisode/autre composant

Ensuite, dans le dossier conteneurs, j’ai un conteneur par page, ce sont les seuls que je connecte à Redux:

 conteneurs /
 HomePageApp.js 
 EpisodePageApp.js 
 ...

et puis les actions sont une par chaque composant supérieur, au lieu d'une par page, donc dans le conteneur de page que je connecte à Redux, je passe toutes les actions des composants utilisés dans cette page. Par exemple:

actes/
 Player.js 
 Episode.js 
 ...

Est-ce que je le fais bien? Je n'ai pas trouvé beaucoup d'informations sur Google, et celles que j'ai trouvées, je pense qu'elles se limitent à de petits projets.

Merci!

javascriptreactjsreduxreactjs-flux
43
Franco Risso

Dans les exemples officiels, nous avons plusieurs répertoires de niveau supérieur:

  • components pour "dumb" Réagir composants ignorant Redux;
  • containers pour les composants «intelligents» React connectés à Redux;
  • actions pour tous les créateurs d'action, où le nom de fichier correspond à une partie de l'application;
  • reducers pour tous les réducteurs, où nom de fichier correspond à la clé d'état;
  • store pour l'initialisation du magasin.

Cela fonctionne bien pour les applications de taille petite et moyenne.

Lorsque vous souhaitez combiner davantage de fonctionnalités modulaires et liées au groupe, Ducks ou d'autres manières de regrouper des fonctionnalités par domaine est une alternative intéressante pour structurer vos modules Redux.

En fin de compte, choisissez la structure qui vous convient le mieux. Il n’ya aucun moyen que les auteurs Redux sachent ce qui vous convient mieux que vous.

94
Dan Abramov

Il s’agit plus d’une question sur les meilleures pratiques/le style de code et la réponse n’est pas claire. Cependant, un style très soigné était proposé dans le projet React redux boilerplate . C'est très similaire à ce que vous avez actuellement.

./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
15
Kloar

Je préfère conserver les composants intelligents et stupides dans le même fichier, mais utilise l'exportation par défaut pour les composants intelligents et l'exportation pour les composants de présentation/dumb. De cette façon, vous pouvez réduire le bruit des fichiers dans votre structure de répertoires. Regroupez également vos composants par "Affichage", par exemple (Administration => [admin.js, adminFoo.js, adminBar.js], Inventory => [Inventory.js, InventoryFoo.js, InventoryBar.js], etc.). 

4
dakt

Je n'ai pas d'opinion forte sur les répertoires de composants, mais j'aime bien rassembler les actions, les constantes et les réducteurs:

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

Je alias state avec avec webpack donc dans les composants de conteneur je peux import {someActionCreator} from 'state/actions';.

De cette façon, tout le code avec état de l'application réside en un seul endroit.

Notez que reducers.js peut être divisé en plusieurs fichiers en créant simplement un répertoire reducers/ comme actions/ et vous ne devrez pas modifier les instructions d'importation.

1
w00t

Dans Redux, vous avez un point d’entrée pour vos actions (actions/dossier) et un point d’entrée pour les réducteurs (réducteurs/dossier).

Si vous optez pour une structure de code basée sur un domaine, vous simplifiez la mise en œuvre et la maintenance du domaine/des fonctionnalités ... par contre, vous compliquez les dépendances des composants et la maintenance de l'état/de la logique de l'application.

Où vas-tu mettre des composants réutilisables? dans le dossier de fonctionnalité/domaine? Donc, si vous avez besoin d'un composant réutilisable provenant d'une autre fonctionnalité/domaine, vous devez créer une dépendance entre les domaines? mmh pas si bon pour la grande application!

Lorsque vous devez combiner des réducteurs, la structure de code-domaine supprime ce qu'elle vous avait donné précédemment.

Vous créez uniquement des modules redux uniques pour chaque domaine/entité . La structure de code-domaine devrait être bonne dans certains cas, mais ce n’est pas Redux.

0
luk_z