conventions.md

• Passer l'ensemble des appels aux store dans un dossier API rangé par store avec un fichier par entité ou par query / mutation si graphQL
• 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 à supprimer

• Pour Api on avait pas dit services et masterData. Le query / mutation est hyper spé ?

disagree for the last item