• Redux très utilisé, mais pas toujours de façon efficace, académique:
  • design de store
  • écriture des actions
  • usage des sélecteurs...

proposer un meetup sur les bonnes et mauvaises pratiques autour de Redux.

• Montrer des bouts de code et faire réfléchir aux problèmes qui en découlent ou aux solutions qu'ils apportent.
• proposer des outils qui facilitent l'utilisation de redux

• BAD: stocker une liste comme un tableau ; plutôt le stocker comme une map dont les clés sont les ID, et éventuellement stocker des tableaux de sortByDate. (cf. reselect)

• => problème potentiel de duplication de données dans un tableau, et de rapidité d'accès à UN élément en particulier (performance de plus en plus dégradée avec le nombre croissant d'éléments dans le tableau).

• => De l'autre côté, séparation entre les données (map) et leur représentation ordonnée (elementsByLastModificationDate: [tableau d'ID]), ce qui oblige à maintenir les deux quand on fait une modification sur un élément

• GOOD: utiliser des sélecteurs partout, de sorte que le choix d'architecture du store soit modifiable à moindre frais (impact à un seul endroit) => composer des sélecteurs à partir de sélecteurs

• => pas de map/ reduce / manip de donnée dans les Container, pour que les calculs ne soient pas réexecutés à chaque action (rappeler que les Container sont réexécutés à chaque action, et qu'en fonction d'un changement de prop, le Presenter sera rafraîchi ou non

• BAD: state non-normalisé (beaucoup de niveaux de profondeur) => indiquer les conséquences possibles

• ? ducks pour regrouper vos reducers/actionCreators/selectors d'un même périmètre fonctionnel ? inconvénient: introduire du couplage entre les actionCreator et reducers (1 pour 1), alors qu'une action peut très bien faire réagir plusieurs reducers

• VS multiples reducers can handle a single action => par exemple à l'ajout d'une tâche dans une TODO list, si on veut aussi mettre à jour la dernière date de modification de la TODO list...

• ? BAD: n'exécuter un reducer qu'occassionnellement ? On lit souvent que les reducers sont tous appelés lorsqu'une action est dispatchée (ce qui est vrai pour ceux de combineReducers)

• https://github.com/reactjs/redux/issues/857#issuecomment-380435260

• ? BAD ? https://github.com/reactjs/redux/issues/857#issuecomment-146021839: use all actions each time for a single reducer

• GOOD: collocate selectors and reducers: selectors are API for what reducers deal with

• ? tester les reducers ? On peut imaginer tester les actions faisant réagir le reducer ET les sélecteurs permettant de lire le state, ainsi si on change le format du store on n'a pas de refacto à faire (exemple: ajout de undo/redo avec redux-undo)

• ? tout dans le store ? Des states locaux ? Quelle règle ? Un composant vraiment autonome qu'on se verrait pousser sur github => state local

• redux devtools
• reselect
• redux-thunk pour des actionCreators plutôt que des actions => accès au state et au dispatch
• ? redux-saga
• ? normalizr (pour convertir une réponse d'API par exemple, en de la donnée normalisée ?)
• ? ImmutableJS (a priori surtout pertinent avant l'utilisation du spread operator sur les objets ; on faisait state.set('entries', List(entries) qui retournait un nouveau state modifié)