pour modifier seulement certains champs d'un objet puis mettre a jour son state, vous pouvez faire: setUser(prev => { return {...prev, name: "Jean"} }) ou setUser({...user, name: "Jean"})
pour l'utilisation d'un seul objet au-lieu de plusieurs useState, c'est bien pour des formulaires. pour d'autres cas ou il y aurait trop de useState, useReducer est une bonne alternative.
Hello, pour l’erreur 1, je ne capte pas en quoi utiliser un useEffect avec une dependance sur une state est un mauvais pattern pour trigger un event (2:24) ? Tu ne donnes pas ton alternative. J’utilise ce pattern pour listen et trigger des events, perso…
Oui je montre ma solution. useEffect est fait pour SYNHRNOISER nos composants avec d'autre chose. Ici j'utilise le pattern "d'action" qui est bien plus react-friendly. th-cam.com/video/bGzanfKVFeU/w-d-xo.html
10:11 les objets sont passés par référence (addrese) alors que les types primitifs (number, string ect ...) sont passés par valeur. Quand tu fais { id:"1"} tu demande à javascript de crée un nouvel object en terme informatique on alloue un emplacement mémoire. Dans le cas du "==" ça regarde si l'addrese mémoire est la même, dans notre cas c'est un nouvel emplacement mémoire donc il répond toujours "false".
16eme erreur ne pas gérer ses inputs comme pour l'erreur 4. Tu met un name à ton input et rien d'autre, on passe ne passe pas la clé et la value à la fonction en parametre.... tu geres ton changement avec l'event plutot, genre comme ça. const handleUpdate = (event: ChangeEvent) = > { const { name, value } = event.target const updatedProduct = { ... product } updatedProduct[name] = value setProduct(updatedProduct) }
Sur l'erreur 14 dans le useState, plutôt que de mettre une arrow function on ne peut pas juste retirer les parenthèse de fin et juste nommer la fonction ?
Pour l'erreur5 , le useEffect n'est pas utile car le composant ne dispose que des 2 states utilisées mais si le composant contenait d'autres states, cela aurait plus de sens car cela éviterait de refaire le calcul de fullName à chaque modification d'une autre state? Je pense notamment à des propriétés dérivées d'une autre state et utilisant sort ou filter
Non, le useEffect n'est VRAIMENT pas fait pour ça du tout et il n'y a aucun cas ou c'est utile. Au pire tu voudrais utiliser le useMemo mais l'optimisation dans mon cas est trop minimum pour rendre le useMemo utiles, même avec 45 states.
Je n'ai pas totalement compris non plus pourquoi on arrête d'avoir les event listener. Je comprend qu'il fallait aller chercher la valeur de counter, alors que maintenant on dit juste valeur précédente. Mais je ne vois pas pourquoi ca permet de ne plus appeler
Merci@@melvynxdev. Voici ce que j'ai compris: Sans le counter en dépendance, le use effect est appelé une seule fois. Ainsi le addEventListner écoute en permance l'événement onMouseMove tant que la vue n'est pas détruite. Je comprend aussi que le useEffect conserve toujours la valeur initiale de counter, c'est pourquoi il est recommandé d'utiliser la prevValue lorsqu'on veut accéder à la dernière valeur modifiée counter.
Merci de cette vidéo, cela démontre qu'il y a encore du boulot.
ahaha merci et keep pushing
merci pour la vidéo, tu peux parler du strict mode dans la prochaine stp
ah oui c'est vrai
pour modifier seulement certains champs d'un objet puis mettre a jour son state, vous pouvez faire:
setUser(prev => { return {...prev, name: "Jean"} })
ou
setUser({...user, name: "Jean"})
oui
pour l'utilisation d'un seul objet au-lieu de plusieurs useState, c'est bien pour des formulaires.
pour d'autres cas ou il y aurait trop de useState, useReducer est une bonne alternative.
oui, après moi je conseil un bon react-hook-form
Salut Melvyn. Pour l'erreur 13, tu parles de la gestion du edge case et du happy path ?
bah je crois pas malheureusement
Hi Melvyn
Quel est le thème de couleur que tu utilises pour ton éditeur ?
Hello, GitHub dark
Hello, pour l’erreur 1, je ne capte pas en quoi utiliser un useEffect avec une dependance sur une state est un mauvais pattern pour trigger un event (2:24) ? Tu ne donnes pas ton alternative.
J’utilise ce pattern pour listen et trigger des events, perso…
Oui je montre ma solution. useEffect est fait pour SYNHRNOISER nos composants avec d'autre chose. Ici j'utilise le pattern "d'action" qui est bien plus react-friendly. th-cam.com/video/bGzanfKVFeU/w-d-xo.html
@@melvynxdevmerci, vidéo très intéressante, faut que je m'approprie ces schémas mentaux qui m'échappent encore un peu 😓
10:11 les objets sont passés par référence (addrese) alors que les types primitifs (number, string ect ...) sont passés par valeur. Quand tu fais { id:"1"} tu demande à javascript de crée un nouvel object en terme informatique on alloue un emplacement mémoire. Dans le cas du "==" ça regarde si l'addrese mémoire est la même, dans notre cas c'est un nouvel emplacement mémoire donc il répond toujours "false".
exacte
Super astuces, thanks.👍
Merci bcp
Reacrquery(transtack query) c'est très bien aussi pour faire des requêtes à la place swr
Oui totalement, juste un peu plus compliqué pour la demo car je dois utiliser le queryClient
hello, swr est-il aussi vraiment utile sur next ? dans le cadre où on a des pages en SSR quoi ...
Moi j’utilise à tjr react query dans mes app Next
@@melvynxdev En effet un pote m'a dit pareil donc je vais vous suivre et comme ça on sera au moins 3
16eme erreur ne pas gérer ses inputs comme pour l'erreur 4.
Tu met un name à ton input et rien d'autre, on passe ne passe pas la clé et la value à la fonction en parametre.... tu geres ton changement avec l'event plutot, genre comme ça.
const handleUpdate = (event: ChangeEvent) = > {
const { name, value } = event.target
const updatedProduct = { ... product }
updatedProduct[name] = value
setProduct(updatedProduct)
}
Yes j’imagine
Sur l'erreur 14 dans le useState, plutôt que de mettre une arrow function on ne peut pas juste retirer les parenthèse de fin et juste nommer la fonction ?
non non c'est mieux de mettre une arrow function comme ça
Hello, pour l'erreur n°1, useCallback n'est pas adapté ?
Non, useCallback n'est vraiment pas utiles dans ce cas.
Pour l'erreur5 , le useEffect n'est pas utile car le composant ne dispose que des 2 states utilisées mais si le composant contenait d'autres states, cela aurait plus de sens car cela éviterait de refaire le calcul de fullName à chaque modification d'une autre state? Je pense notamment à des propriétés dérivées d'une autre state et utilisant sort ou filter
Non, le useEffect n'est VRAIMENT pas fait pour ça du tout et il n'y a aucun cas ou c'est utile. Au pire tu voudrais utiliser le useMemo mais l'optimisation dans mon cas est trop minimum pour rendre le useMemo utiles, même avec 45 states.
Hello, stp à l'erreur 5 (8:15) je n'ai pas compris pourquoi on a 4 Render lorsque tu dis "à cause du stric mode". C'est quoi ce mode?
Le StrictMode est le mode de développement en React pour détecter les erreurs
Merci.
Concernant l'erreur 12 je n'ai pas compris pourquoi le removeEventListner n'est plus appelé 😅
Je n'ai pas totalement compris non plus pourquoi on arrête d'avoir les event listener. Je comprend qu'il fallait aller chercher la valeur de counter, alors que maintenant on dit juste valeur précédente. Mais je ne vois pas pourquoi ca permet de ne plus appeler
Si tu return au début de la function « rien » le useEffect ne vas pas appeler la « cleanup » function car il ne la retourne pas
Merci@@melvynxdev. Voici ce que j'ai compris: Sans le counter en dépendance, le use effect est appelé une seule fois. Ainsi le addEventListner écoute en permance l'événement onMouseMove tant que la vue n'est pas détruite. Je comprend aussi que le useEffect conserve toujours la valeur initiale de counter, c'est pourquoi il est recommandé d'utiliser la prevValue lorsqu'on veut accéder à la dernière valeur modifiée counter.
Est ce qu'on peut avoir une video sur les test en React
J’en ai déjà !
@@melvynxdev est ce que je peux avoir le lien
Cherche et trouve
Salut, t'as une coquille dans ton titre, y a pas de s à font 😉
Bravo, le SWR et les custom hooks sont limite obligatoires 😉
oui !
T'es un bon mec
Toi aussi
Dans l'erreur 8 le composant fait 2 rendus à cause du StrictMode (actif seulement en développement)
Yes exacte