👋

Gabriel Vergnaud

Héticien de la P2017

Frontend engineer

@gvergnaud on

@GabrielVergnaud on

🗺

I. qu'est ce que les side effects

II. les effects en React

III. gérer les erreurs

IV. les side effects et le state reducer pattern

I

les side effects ?

mais qu'est-ce donc

Le code qui intéragit avec le monde extérieur

Mais extérieur à quoi ?

Au scope de la fonction

let imInTheUpperScope = true

function sideEffectFunction(params) {
  // tout ce qui est défini ici
  // fait partie du scope de la function `sideEffectFunction`

  const imPartOfTheFunctionScope = true

  // si je modifie quelque chose
  // du scope parent, alors je fais un side effect:

  imInTheUpperScope = false // /!\ Side effect!

  // Modifier les paramètres est également un side effect
  params.hello = '👋'
}

// l'ordre des définitions n'a pas d'importance
let imAlsoInTheUpperScope = true

{}

Le scope de la function est determiné par ce qui est défini à l'intérieur de ses brackets

Quelques exemples de side effects :

Modifier des variables du scope extérieur
Les requètes HTTP
L'accès à une base de donnée
Cookies, localStorage
Web APIs (DOM, WebAudio, WebGL...)
File system

Les side effect en react

// in native: side effect
const view = () => {
  document.body.innerHTML = `
    <div class="container">
      <p>Hello world!</p>
    </div>
  `
}

// in React: no side effect
const View = () => {
  return (
    <div className="container">
      <p>Hello world!</p>
    </div>
  )
}

React rend les intéractions avec le DOM pures et déclaratives

Oui mais...

Le web, ce n'est pas seulement intéragir avec le DOM

quelques side effects, du dévelopement frontend

Les network requests (HTTP ou WebSocket la plupart du temps)

L'url et l'History pour le routing

Le localStorage ou les cookies pour la persistence

Les event listener globaux (scroll, drag & drop, etc)

les autres threads (service workers / web workers)

la console (seulement pour le débugging a priori)

Cependant, lorsque l'on fait du web, on gère d'autres types de side effects que ceux du DOM.

- Des network requests (HTTP ou WebSocket la pluspart du temps)
- le localStorage ou les cookies pour la persistence
- L'url et l'History pour le routing
- les autres threads (service workers / web workers)
- parfois on a besoin d'ajouter des event listener à la main sur la window (scroll, drag & drop, etc)
- la console (seulement pour le débugging a priori)

pour tout ça, on utilise useEffect

const App = () => {
  useEffect(() => {
    // effects
  })
}

On place le code relatif aux effects dans un callback Ce callback sera runné de manière asynchrone, une fois que react a updaté le DOM.

const App = () => {
  useEffect(() => {
    // i can use 'user' and 'isAdmin'
  }, [user, isAdmin])
}

Les dépendances sont données en deuxième paramètre À chaque fois que l'une de ses dépendances va changer, le callback sera re-exécuté Le tableau de dépendances est optionelle si il n'est pas fourni, le callback sera exécuté après chaque render

const App = () => {
  useEffect(() => {
    window.addEventListener('scroll', handler)
    return () => window.removeEventListener('scroll', handler)
  }, [handler])
}

À l'intérieur du useEffect, je peux retourner une fonction de cleanup Elle sera exécutée si notre composant est retiré du DOM ou si les dépendances ne sont plus à jour

à vos claviers

Créer un custom hook

Il est possible de composer plusieurs hooks ensemble
pour créer un nouveau hook.

Les custom hooks permettent d'encapsuler la complexité de notre code.

En résumé

useEffect est une manière de rendre déclaratif du code effectful et impératif.

Déclaratif car le code est dépendant de la data.

La gestion des erreurs

Les side effects sont par nature imprevisibles.

une request HTTP peut échouer un acces au cookie peut échouer (environement sandboxé, iframes...) une manipulation de DOM peut échouer (plusieurs modifications incompatibles)

Il faut donc considérer les cas d'erreur dans le code.

Les promises

const p = new Promise((resolve, reject) => {
  // make some effect
  if (itSucceeds)
    resolve(someData)

  if (itFails)
    reject(someError)
})

2 branches : une pour le succès et une pour l'erreur

fetchUser() // returns a promise
  .then(user => fetchFriends(user)) // chains a second promise
  .then(friends => {}) // when all the side effects are done

on peut séquencer plusieurs effets

Donc, pourquoi ne pas créer un hook pour utiliser des promises dans nos components ?

TUTO construire un promise based useSideEffect hook

const usePromise = (getPromise, deps) => {
  const [type, setType] = useState('pending')
  const [data, setData] = useState(null)
  const [error, setError] = useState(null)
  useEffect(() => {
    let isCancelled = false
    setType('pending')
    setData(null)
    setError(null)

    getPromise()
      .then(data => {
        if (isCancelled) return
        setData(data)
        setType('resolved')
      })
      .catch(err => {
        if (isCancelled) return
        setError(err)
        setType('rejected')
      })

    return () => {
      isCancelled = true
    }
  }, deps)

  return [type, data, error]
}

Side effect et state reducer pattern

On a un problème.

puisque notre reducer est une fonction pure, elle ne doit pas avoir de side effect.

Son type est trop restrictif

(state, action) => state

Mais pourquoi pas le changer ?

(state, action) => [state, callback]

C'est l'approche de plusieurs langages fonctionelles comme Elm ou Reason

Deuxième solution :

Utiliser des middlewares

C'est l'approche de Redux

La plus courante en javascript

Commencer par expliquer ce qu'est un middleware

faire un logger middleware
simple thunk middleware
effect middleware avec promises

Ou exécuter des side effect dans le contexte d'un state reducer ?

utiliser un middleware

le middleware prend une fonction qui retourne une promesse et la transform en actions:


const someEffectAction = {
  type: 'SOME_EFFECT_ACTION',
  async effect() {
    // do stuff
  }
}

dispatch(someEffectAction)

Le middleware intercepte l'action et va remplacer la function effect par de la data:

{
  type: 'SOME_EFFECT_ACTION',
  effect: {
    type: 'pending',
    error: null,
    data: null
  }
}

puis

{
  type: 'SOME_EFFECT_ACTION',
  effect: {
    type: 'resolved',
    error: null,
    data: {...} // data returned by the promise
  }
}

ou

{
  type: 'SOME_EFFECT_ACTION',
  effect: {
    type: 'rejected',
    error: Error{...},  // error thrown by the promise
    data: null
  }
}

C'est l'approche prise par plusieurs projets open sources, dont Hyper, le terminal de zeit.co

TUTO construire ce middleware

Quel sont les bénéfices de cette approche ?

Nos effets deviennent inspectables car ils sont représentés par des actions On peut implémenter des optimistic updates automatiques

Quels sont les bénéfices ?

optimistic updates for free

Puisque l'on peut clairement identifier les actions qui représentent des effets, on peut créer une logique d'error handling commune.

L'optimistic update est le fait de faire comme si l'effect avait déjà eu lieu avant que la requete ai fini pour donner l'impression à l'utilisateur que notre application est super rapide.

cependant, si l'action fail, il faut rollback les changements sur le state pour bien indiquer qu'il y a eu une erreur!

Puisque l'on sait différentier une action 'pending' d'une action 'rejected', on peut automatiser ce processus pour toutes nos actions. il suffit de :

stocker le diff du state au pending
en cas d'erreur, réappliquer le state précédent
en cas de succès, on peut enlever le diff que l'on avait stocké.

Tester les side effects

Les side effects sont la partie compliqué à tester. Comment simplifier le testing de notre app ?

les mocks & dependency injection

On peut encore améliorer notre middleware:

Au lieux d'importer la logique de nos side effect directement dans notre code, on peut se créer des services qui vont se charcher de faire les side effect pour nous, et les injecter via notre middleware.

Comme ça, si on est dans un contexte de testes automatisé, dans lequel on a pas envie de vraiment faire des requests, on peut injecter un mock de notre service.

// inside our code

const apiService = {
  getUser(id) {
    return fetch(<code>/users/${id}</code>).then(res => res.json())
  }
}

effectMiddleware(apiService)

// Inside an automated test
const apiMock = {
  getUser(id) {
    return new Promise(resolve => {
      resolve({ name: 'Gabriel', id })
    })
  }
}

effectMiddleware(apiMock)

Merci

de votre attention

Gabriel Vergnaud

React

Side Effects