3 trucs que j'aurais voulu savoir quand j'ai commencé React
Il y a quelques semaines, j'ai commencé React. J'adore, mais par contre, il y a 2-3 choses qui m'ont surprise, comme les double render, les erreurs et les imbrications de useState.
Il y a deux mois, je me suis mise à React. D'abord seule, car c'est une librairie dont la logique m'intéressait particulièrement et qu'elle était citée dans nos fiches de cours sur la différence librairie/framework.
Puis, en groupe, lors du projet collectif Wonderflower, qui m'a permis de monter en compétence sur React, car nous n'étions que deux personnes sur le 10 du groupe à y avoir vaguement touché (ça fait apprendre rudement vite).
Durant ces premières semaines, j'ai été confrontée à plusieurs choses que j'aurais bien aimé savoir tout de suite.
Donc voilà, c'est cadeau, avec une ressource pour aller plus loin à chaque fois, car je ne suis toujours pas très sûre des explications théoriques derrière tout ça.
Mais pourquoi ca rerender deux fois, nom d'une pipe ?
React fonctionne sur un principe de cycle de vie des composants avec des mises à jour d'état. Bon, donc ça "render" des choses. Sur certains projets React, je me suis retrouvée avec des éléments en double, sans comprendre pourquoi. L'explication est simple : avec react 18, si l'index.js est en React.StrictMode, les composants sont render 2 fois, en guise de protection dans un environnement de dev.
ReactDOM.render(
<React.StrictMode>
<App />
</React.StrictMode>,
document.getElementById("root")
);
Ne me remercie pas. Enlève-le si tu veux ou garde le en connaissance de cause. Si tes composants se render deux fois, tu peux lire cet article d'Andreas Heissenberger (car c'est aussi possible que ce ne soit pas StrictMode, mais un autre problème).
Destroy n'est pas un vilain mot.
'Destroy is not a function' est certainement l'erreur qui m'a fait le plus peur lorsqu'elle m'est apparue, je ne sais pas pourquoi, l'effet "destroy". Et en ce temps-là, j'utilisais React sur un projet en Laravel dont une route de l'api s'appelait évidemment destroy, donc j'ai fait un raccourci en me disant 'omg ma route'. Raccourci inutile. "Destroy is not a function" veut simplement dire que tu as mal utilisé useEffect en y mettant une fonction sans ses moustaches, surtout si elle est async (par exemple lors d'un API call)....
const getData = async () => {
//fetch tes trucs ici
};
useEffect(() => {
//N'OUBLIE PAS LES ACCOLADES :)
getData();
}, []);
Aryan Mittal en parle bien ici !
On ne set pas des states avec des states
Celle-là elle est plutôt récente et elle est intéressante. Quand on commence à vraiment s'amuser avec React, on met des states partout et, au début, on ne comprend pas toujours comment ça fonctionne ces histoire de cycle de vie et de render.
Dans un projet récent, j'utilisais plusieurs states dans un composant Calendar
(le state de la date sélectionnée et le state d'une date future calculée à partir de cette date sélectionnée) et mon 2e state ne s'affichait pas tout de suite. Logique, React devait rerender le premier pour pouvoir calculer le second. C'est donc là que j'ai remis l'église au milieu du village : les states de React gèrent l'affichage dynamique. Quand on fait des calculs, on ne les fait avec des states, et on n'imbrique pas des states dans des states.
Corréler le changement d'un state à un autre state, c'est mal, on ne fait pas ça. Kevin Cordier l'explique aussi sur son blog.
Pour comprendre les bonnes pratiques de l'usage des states, tu peux aussi te rendre sur le blog de Thibaud Vouillon et potasser ses exemples, simples mais efficaces !
En bonus : check deux fois la doc que tu utilises, même si elle a l'air officielle
Quand j'ai commencé React, leur dernière doc n'était pas encore sortie. Donc, en bonne élève, je me suis rendue sur le site officiel pour faire le tuto proposé par react.org. Oui mais sauf que c'etait avant d'apprendre que la doc de react était mise à jour sur un site en béta depuis plus de 2 ans (beta.react.dev) et que donc la doc sur le site react.org n'était pas vraiment, vraiment à jour. Pas grave, je sais faire un tictact toe avec des classes maintenant. (la bonne doc, c'est react.dev et heureusement, aujourd'hui il y a un joli "legacy" devant l'url de l'ancienne doc).