Skip to content

Home

Jump to bottom
euZebe edited this page Apr 16, 2018 · 1 revision

Atelier Redux

contexte

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

Objectif à moyen terme:

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

Objectifs de ce soir:

  • 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

Quelques exemples

  • 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

? Quels libs connexes utilisez-vous, et pour quel apport ?

  • 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é)
Clone this wiki locally