Merci pour la vidéo ! Je me permets de te suggérer de réaliser une vidéo sur la partie "You Might Not Need an Effect" de la documentation React. Ce serait chouette de sensibiliser également les nouveaux devs react à ne pas faire du "useEffect" une solution à tout mais plutôt une solution "en dernier recours". Ce hook est pratique mais peut causer de nombreux problèmes de performances et de compréhenstion du code (lors des debug notamment)
Merci pour tes videos. Il y a un detail que je trouves confus pour nous débutant. Le fait de mettre "v" en paramètre de handleChange. et de le passer dans setDuration et setSecondsLeft. On se demande d'ou sort ce paramètre, qui si j'ai bien compris (avec l'aide de chatGPT lol) correspondrait a la valeur écrite dans l'input donc on pourrait mettre "e" en paramètre et écrire const v = e.target.value puis setDuration(v) ou tout simplement setDuration(e.target.value). Et on pourrait explicitement écrire dans l'input onChange={()=> handleChange(e.target.value)}. Dites moi si je me trompes... C'est peut-etre un detail pour des devs confirmés mais cela peut vraiment nous perdre quand on débute.
Bonjour. La subtilité c'est que l'input utilisé ici est un Input custom qu'il a fait lui-même dans un chapitre précédent. Et son Input custom, dans sa méthode onChange renvoi directement la valeur, et non pas un event (e). S'il avait utilisé un input natif, alors oui, il aurait dû récupérer la valeur depuis l'event en faisant: e.target.value.
J'ai une petite question : Les Setters ne fonctionnent pas en les injectant directement comme dans les eventLisner comme onChenge ( exemple : ) Lors que je commence à taper dans le champ , ça me met [object Object] dans l'input . Je me demande c'est quoi la raison
Bonjour Grafikart, j'ai vu que la doc préconisait de ne plus utiliser les composants sous forme de classe, qu'en pense tu ? Est ce un appauvrissement de la bibliothèque ou au contraire est ce bien d'unifier la façon de faire ? Merci :)
Avant React 16.8, les composants de classe étaient la principale façon de créer des composants dans React. Cependant, avec l'introduction de Hooks dans React 16.8, les composants fonctionnels ont gagné en popularité. Les Hooks permettent aux composants fonctionnels de gérer l'état local, les effets secondaires (useEffect coucou), le cycle de vie, etc., de manière similaire aux composants de classe, mais avec une syntaxe plus concise. Voici quelques avantages des composants fonctionnels par rapport aux composants de classe : Lisibilité du code : Les composants fonctionnels sont souvent plus courts et plus faciles à lire que les composants de classe. Ils réduisent la quantité de code boilerplate nécessaire. Facilité de test : Les composants fonctionnels sont plus faciles à tester car ils ne dépendent pas des instances de classe. Meilleure performance : Les composants fonctionnels sont généralement plus performants que les composants de classe, car ils évitent la création d'instances de classe inutiles. Compatibilité avec les Hooks : Les Hooks ne sont pris en charge que dans les composants fonctionnels. Si vous souhaitez utiliser des Hooks dans votre application, vous devez utiliser des composants fonctionnels. A savoir que ce passage là s'est fait en 2019, donc si vous avez un amour des classes, comme le dit la documentation, ce n'est pas ici que vous le trouverez et il faudra passer ailleurs. L'ensemble de l'eco-system a fait la bascule depuis un moment déjà.
@@koko0808008 Oui je sais déjà tout ça, je suis développeur front-end, j'utilise de base Vue.js pour les projets nouveaux (sauf contrainte du client) mais il m'arrive très souvent de travailler sur des projets existants en react. Je connais donc déjà les hooks, leur utilisation, etc. Pour substituer aux state ou encore aux methods du lifeCycle des composants sous forme de classe. Je me demandais simplement comment voyait Grafikart la suppression ou plutôt l'incitation à ne plus utiliser les composants sous forme de classes. La question des performances rentre certainement en jeu, je vous rejoins. Par contre pour la lisibilité je trouve que les classes sont toute autant compréhensible. Lire useEffect sans dependence et comprendre que c'est l'équivalent d'un componentWillMount il faut être initié de base 😅
Merci pour la vidéo ! Je me permets de te suggérer de réaliser une vidéo sur la partie "You Might Not Need an Effect" de la documentation React. Ce serait chouette de sensibiliser également les nouveaux devs react à ne pas faire du "useEffect" une solution à tout mais plutôt une solution "en dernier recours". Ce hook est pratique mais peut causer de nombreux problèmes de performances et de compréhenstion du code (lors des debug notamment)
Merci pour tes videos. Il y a un detail que je trouves confus pour nous débutant. Le fait de mettre "v" en paramètre de handleChange. et de le passer dans setDuration et setSecondsLeft. On se demande d'ou sort ce paramètre, qui si j'ai bien compris (avec l'aide de chatGPT lol) correspondrait a la valeur écrite dans l'input donc on pourrait mettre "e" en paramètre et écrire const v = e.target.value puis setDuration(v) ou tout simplement setDuration(e.target.value). Et on pourrait explicitement écrire dans l'input onChange={()=> handleChange(e.target.value)}. Dites moi si je me trompes... C'est peut-etre un detail pour des devs confirmés mais cela peut vraiment nous perdre quand on débute.
Bonjour. La subtilité c'est que l'input utilisé ici est un Input custom qu'il a fait lui-même dans un chapitre précédent. Et son Input custom, dans sa méthode onChange renvoi directement la valeur, et non pas un event (e).
S'il avait utilisé un input natif, alors oui, il aurait dû récupérer la valeur depuis l'event en faisant: e.target.value.
tu es le meilleur.
J'ai une petite question :
Les Setters ne fonctionnent pas en les injectant directement comme dans les eventLisner comme onChenge ( exemple : )
Lors que je commence à taper dans le champ , ça me met [object Object] dans l'input .
Je me demande c'est quoi la raison
il faut cree le composant ? par vous meme si nous vous utiliser callback onChange=(e)=>{
set ... (value )
}
Bonjour Grafikart, j'ai vu que la doc préconisait de ne plus utiliser les composants sous forme de classe, qu'en pense tu ? Est ce un appauvrissement de la bibliothèque ou au contraire est ce bien d'unifier la façon de faire ? Merci :)
Avant React 16.8, les composants de classe étaient la principale façon de créer des composants dans React. Cependant, avec l'introduction de Hooks dans React 16.8, les composants fonctionnels ont gagné en popularité. Les Hooks permettent aux composants fonctionnels de gérer l'état local, les effets secondaires (useEffect coucou), le cycle de vie, etc., de manière similaire aux composants de classe, mais avec une syntaxe plus concise.
Voici quelques avantages des composants fonctionnels par rapport aux composants de classe :
Lisibilité du code : Les composants fonctionnels sont souvent plus courts et plus faciles à lire que les composants de classe. Ils réduisent la quantité de code boilerplate nécessaire.
Facilité de test : Les composants fonctionnels sont plus faciles à tester car ils ne dépendent pas des instances de classe.
Meilleure performance : Les composants fonctionnels sont généralement plus performants que les composants de classe, car ils évitent la création d'instances de classe inutiles.
Compatibilité avec les Hooks : Les Hooks ne sont pris en charge que dans les composants fonctionnels. Si vous souhaitez utiliser des Hooks dans votre application, vous devez utiliser des composants fonctionnels.
A savoir que ce passage là s'est fait en 2019, donc si vous avez un amour des classes, comme le dit la documentation, ce n'est pas ici que vous le trouverez et il faudra passer ailleurs. L'ensemble de l'eco-system a fait la bascule depuis un moment déjà.
@@koko0808008 Oui je sais déjà tout ça, je suis développeur front-end, j'utilise de base Vue.js pour les projets nouveaux (sauf contrainte du client) mais il m'arrive très souvent de travailler sur des projets existants en react.
Je connais donc déjà les hooks, leur utilisation, etc. Pour substituer aux state ou encore aux methods du lifeCycle des composants sous forme de classe.
Je me demandais simplement comment voyait Grafikart la suppression ou plutôt l'incitation à ne plus utiliser les composants sous forme de classes. La question des performances rentre certainement en jeu, je vous rejoins. Par contre pour la lisibilité je trouve que les classes sont toute autant compréhensible. Lire useEffect sans dependence et comprendre que c'est l'équivalent d'un componentWillMount il faut être initié de base 😅