- Passer l'ensemble des appels aux store dans un dossier
API
rangé par store avec un fichier par entité ou par query / mutation sigraphQL
- Les services de chargement des master data doivent aussi être insérés dans le dossier de l'api liée avec que les enums associées
api
candidate
job
booking
query
loadCandidateResponse.js
...
mutation
...
masterdData
enums
bookingStatus.js
Ceci devrait pouvoir être généré ou publié par version avec les paquets `npm
-
Chaque nouvelle feature fait l'objet d'une conception en équipe avec une définition de:
- Les composants de la page et l'agencement
- La structure du
state
redux - Les sélecteurs mis à disposition
- Un test unitaire sur la structure du state et les actions doit être écrit (sauf pour les cas génériques load / save.
-
Dans le cas d'une page complexe (avec plusieurs blocs ), il ne faut pas hésiter à mettre plusieurs niveau de
Routeur
-
Les tests sont toujours dans un dossier
__tests__
-
La structure au sein de l'application (en fonction de la taille de l'application on fait une ou plusieurs dossiers dans
views
- `index.js` // Le fichier principal de la vue
- `vue-action.js` // Les actions de la vue et des compsants liés
- `vue-reducer`
* `index.js` => le reducer
* `selector` => les selecteurs
* `normalizer` => la fonction potentielle de normalisation de state (cf [doc de redux](http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html) )
- containers // Les composants qui connectent le state avec des selecteurs et des compsants pures (1 fichier par composant)
- components // Les composants purs de la page
composannts => composants
-
index.js
// Le fichier principal de la vue à supprimerPour Api on avait pas dit services et masterData. Le query / mutation est hyper spé ?