Merci beaucoup pour ces conseils. J'ai eu quelques difficultés à comprendre ces concepts lorsque j'ai commencé Typescript et ici chaque point est bien expliqué. Bravo
Salut, au top. Effectivement c’est pas évident de rentrer dans Time script, par contre ça vaut vraiment le coup si vous comptez continuer dans l’écosystème JavaScript. C’est une cross-compétence. 👍
merci Simon. le Partial me change la vie avec redux. au lieu de typer mes objets avec des ? bah je rajoute juste un type Partial à mon PayloadAction et du coup je peux n'actualiser qu'une des clés de mon objet. mortel !!! révolution !
C’est un plaisir d’entendre ça, l’objectif des vidéos étant d’aider dans la vraie vie les développeurs et de vous simplifier les journées de code ! Donc ça fait du bien de lire votre commentaire !
Bonjour, j'aimerai bien que tu nous parle de l'intelligence artificielle et de ce que tu en pense. Ce serait fort intéressant je trouve. Merci encore pour tes autres videos !
Hello, 100 % d’accord avec vous. Le sujet est très intéressant surtout pour nous en tant que développeur. Cependant pour le moment j’ai rien de très intéressant à dire puisque ces outils A nous sont interdits dans mon travail. Donc même si je joue un peu à côté avec, je n’ai pas un retour d’expérience Suffisant pour en faire une vidéo actuellement. Bon code !
Pour l'astuce 3 ça fait un moment que j'ai drop l'enum mais je faisais un object marqué "as const" et je créais l'union type à partir de l'enumObject avec typeof/keyoff. Je faisais souvent ça car je préfèrais éviter d'avoir des string en dur mais avec ce que tu montres là j'ai eu un doute... J'ai fais f2 sur une string d'un union type et OMAGAD on peut changer leur valeur comme on renommerait une variable à travers tous les fichiers du projet. Tu régales monsieur, j'avais oublié l'astuce 4 aussi, j'vais arrêter d'écrire des ternaires pour faire ça mdr. Sur la 5 je vais voir mais j'vais ptet me prendre au jeu du readonly. Merci beaucoup pour cette vidéo, on demande du typescript et on en a ❤!! Et encore un peu moins de code caca en ce monde !
Je fais pareil avec les objets as const. À mon sens ça reste utile d'avoir toutes les constantes définies à un seul endroit et de modifier ces valeurs qu'à cet endroit là si besoin. ça me fait un peur de manipuler directement les string, mais à tester...
@@paul-henryngounou5689 Ben du coup tu seras forcément ratrapé par ton compilateur. En plus le downside d'utiliser ce type d'enum c'est que l'inférence peut être un peu défoncée si tu utilise le type résultant de l'enum avec typeof/keyof pour essayer de construire d'autres structures avec. Tu auras globalement une meilleure expérience je pense avec uniquement un union type. A voir en playground mais je pense que y'a du bénéfice à faire ça. Après y'aura toujours des contre-exemples, des edge cases. Perso j'ai aucun bénéfice à switch dessus pour un projet en cours. Pour un prochain projet par contre j'essayerais d'inclure ça pendant la construction du repo.
Non, les namespace en PHP et le path mapping (ou path remapping) en TypeScript ne sont pas exactement les mêmes concepts, bien qu'ils aient des objectifs similaires en termes d'organisation du code. Les namespace en PHP sont utilisés pour organiser le code en espaces de noms logiques, évitant ainsi les conflits de noms entre les classes, fonctions et constantes. Ils permettent de regrouper le code lié dans des espaces de noms distincts. Le path mapping (ou path remapping) en TypeScript est un mécanisme permettant de spécifier une correspondance entre les chemins d'importation utilisés dans le code source et les emplacements réels des fichiers sur le disque. Cela permet de structurer le code de manière logique dans l'arborescence des fichiers, sans avoir à respecter strictement la structure des répertoires physiques. En résumé, les namespace en PHP gèrent principalement les conflits de noms et l'organisation logique du code, tandis que le path mapping en TypeScript gère la correspondance entre les chemins d'importation logiques et les emplacements physiques des fichiers.
Peux-tu faire une vidéo sur les générateur de code (de projet) tel que Jhipster ? J'ai utilisé cet outil à l'époque quand j'étais étudiant et de junior mais je me retrouvais buté sur des lignes de code que je ne comprenais pas par manque d'expertise.
Hello, le sujet est intéressant, mais je n’ai pas prévu de vidéo là-dessus, d’autant plus que je n’utilise pas cet outil en production donc je n’ai pas grand-chose d’intéressant à dire là-dessus. 👍
Bonjour Simon j'ai suivi votre cours Angular sur Udemy et cela m'a beaucoup aidé mais ce pendant avez vous fait des tuto sur les test unitaires et d'integration angular?
Hello, je ne propose pas de contenu sur les tests actuellement. J'attends de trouver un sujet de vidéo pour faire découvrir le sujet et l'intérêt associé, mais aussi les erreurs courantes dans ce domaine. Ce n'est pas simple d'initier les développeurs là-dessus.
Concernant le point numéro 1, c'est quand même beaucoup mieux de parser/valider les inputs au runtime et d'inférer les types à partir du parseur/validateur que de générer des types automatiquement. Un système de type qui ment c'est aussi grave qu'un système de type désactivé, et puis ça permet, si c'est bien fait, l'utilisation de types union discriminantes ce qui évite d'avoir un certain nombre de champs optionnels quand il y a des dépendances entre plusieurs champs : soit un group de champs couplés est présent en entier, soit il est totalement absent.
non, ce n'est pas nécessairement mieux, si par exemple on a une garantie très forte concernant la stabilité de l'API à laquelle on se connecte, en parsant on ajoute de la complexité pour rien
Je dirais qu'ils sont assez proches mais utilisable à des endroits différents. Readonly sur les instances de classe ou dans la signature d'une fonction tandis que const est utilisé ailleurs comme dans le corps de fonction
Pour faire court et être efficace : const est pour les variables dont la valeur ne change pas, tandis que readonly est pour les propriétés d’objets qui ne doivent pas être modifiées après l’initialisation.
Hello, oui ça me ferait plaisir de mettre en avantage TypeScript, malheureusement pour l’instant je n’ai pas les ressources pour produire une formation de cette envergure. Mais un jour, peut-être ! Bon code !
Concernant l’astuce 3, si on est amené à utiliser les valeurs de l’enum dans le code, pour des comparaisons ou des assignations par exemple, on ne peut pas utiliser l’alternative des union types
Hello tout à fait, mais dans ce cas cela veut dire que vous auriez probablement besoin d’une classe. Encore une fois, les énumération ne sont qu’une collection de variables en TypeScript, qui pollue le bundle final.
Oui mais tu auras un seul type assez big parfois. L'avantage qu'il présente (ou de passer par copilot) est d'obtenir un ensemble de types séparés. Donc plus modulaire
Un peu lourd de déclarer chaque paramètre de fonction en readonly. Je préfère configurer ESLint correctement pour éviter de les modifier. Bons conseils, sinon 👍
It depends. Lui présente cela comme un état transitoire. Cela signifie que par la suite, les options seront disponibles. Un pick ou omit viendrait les blacklist
Pour la 3) le problème c'est d'utiliser des types au lieu de valeurs. L'union type n'est pas enumerable. Il vaut mieux utiliser un object dont chaque propriété est un membre de l'enum en tant que tupe. On peut même faire des unions d'enums avec Object.assign
Salut, je comprends l’idée, mais je vous déconseille encore une fois d’utiliser les énumérations typescript. Passer par un objet déclaré avec « as const » si vous avez besoin des valeurs. Bon code !
Hello, le débat est intéressant, mais au boulot on est arrivé à la conclusion d’utiliser le terme immutable. Le nom francisé n’a pas fait l’unanimité !
Le problème avec typscript et copilot ou les autre ia's, c'est qu'ils sont éduqués pour que tu joue le jeu des typages bien faits, et je me retrouve à boucler dans un enfer des déclarations de types où chaque correction apporte une nouvelle erreur. Je suis pourtant fan de Java et son typage fort, sa verbosité à n'en plus finir, mais après avoir découvert les joies du scripting avec python et javascript, typescript peut surprendre. Pour des tests ou des poc, j'utilise simplement 'any' partout et basta.
Enfaite le typage est assez simple mais sert surtout pour la relecture du code et une meilleur structure de données. Après oui c'est transpiller en javascript mais sa aide quand même pour le développement. Concraitement oui j'aime aussi m'amuser avec mes scripts bash,python ou js et j'en suis bien content qu'il n'y a pas besoin de typage. Mais quand tu taffe sur un projet sérieux le typage t'aide et t'évite des erreurs. L'avantage de typescript est que TU décide de mettre du typage ou tu veux,la où Java et C++ vont te forcer (ce qui est logique évidemment ;)
Il faut rentrer dans TypeScript, pas simple au départ, car il est fortement construit par-dessus JavaScript et respecte les paradigmes de ce langage parfois étonnant. Bref, il y a un petit coût d'entrée pour le dompter, mais j'estime que cela vaut le coup pour un projet important. Pour un POC ou un petit projet "pédagogique", pas besoin de se casser le crâne là-dessus.
J'utilise Omit à la place de Partial. Plus restrictif donc plus safe
Ou Pick en fonction du nombre de valeur a récupérer.
Le "as const " est sous côté aussi
"as const" est trop sous-côté, on en parle pas assez.
Merci beaucoup pour ces conseils.
J'ai eu quelques difficultés à comprendre ces concepts lorsque j'ai commencé Typescript et ici chaque point est bien expliqué. Bravo
Salut, au top. Effectivement c’est pas évident de rentrer dans Time script, par contre ça vaut vraiment le coup si vous comptez continuer dans l’écosystème JavaScript. C’est une cross-compétence. 👍
merci Simon. le Partial me change la vie avec redux. au lieu de typer mes objets avec des ? bah je rajoute juste un type Partial à mon PayloadAction et du coup je peux n'actualiser qu'une des clés de mon objet. mortel !!! révolution !
déjà jette redux à la poubelle et installe zustand :D
C’est un plaisir d’entendre ça, l’objectif des vidéos étant d’aider dans la vraie vie les développeurs et de vous simplifier les journées de code ! Donc ça fait du bien de lire votre commentaire !
super vidéo, hyper instructif !
Merci et bon code !
Bonjour, j'aimerai bien que tu nous parle de l'intelligence artificielle et de ce que tu en pense. Ce serait fort intéressant je trouve.
Merci encore pour tes autres videos !
Hello, 100 % d’accord avec vous. Le sujet est très intéressant surtout pour nous en tant que développeur. Cependant pour le moment j’ai rien de très intéressant à dire puisque ces outils A nous sont interdits dans mon travail. Donc même si je joue un peu à côté avec, je n’ai pas un retour d’expérience Suffisant pour en faire une vidéo actuellement. Bon code !
Pour l'astuce 3 ça fait un moment que j'ai drop l'enum mais je faisais un object marqué "as const" et je créais l'union type à partir de l'enumObject avec typeof/keyoff. Je faisais souvent ça car je préfèrais éviter d'avoir des string en dur mais avec ce que tu montres là j'ai eu un doute... J'ai fais f2 sur une string d'un union type et OMAGAD on peut changer leur valeur comme on renommerait une variable à travers tous les fichiers du projet.
Tu régales monsieur, j'avais oublié l'astuce 4 aussi, j'vais arrêter d'écrire des ternaires pour faire ça mdr.
Sur la 5 je vais voir mais j'vais ptet me prendre au jeu du readonly.
Merci beaucoup pour cette vidéo, on demande du typescript et on en a ❤!! Et encore un peu moins de code caca en ce monde !
Je fais pareil avec les objets as const. À mon sens ça reste utile d'avoir toutes les constantes définies à un seul endroit et de modifier ces valeurs qu'à cet endroit là si besoin. ça me fait un peur de manipuler directement les string, mais à tester...
@@paul-henryngounou5689 Ben du coup tu seras forcément ratrapé par ton compilateur.
En plus le downside d'utiliser ce type d'enum c'est que l'inférence peut être un peu défoncée si tu utilise le type résultant de l'enum avec typeof/keyof pour essayer de construire d'autres structures avec.
Tu auras globalement une meilleure expérience je pense avec uniquement un union type.
A voir en playground mais je pense que y'a du bénéfice à faire ça. Après y'aura toujours des contre-exemples, des edge cases.
Perso j'ai aucun bénéfice à switch dessus pour un projet en cours. Pour un prochain projet par contre j'essayerais d'inclure ça pendant la construction du repo.
Merci pour votre feedback, la lutte contre le code caca continue !
Merci pour ce contenu très riche. Je fais une refacto de suite
Haha, attention à pas casser la prod !
Merci pour la vidéo ;)
Pour savoir, la notion de path making est elle la même que les namespace sur php ?
Non, les namespace en PHP et le path mapping (ou path remapping) en TypeScript ne sont pas exactement les mêmes concepts, bien qu'ils aient des objectifs similaires en termes d'organisation du code.
Les namespace en PHP sont utilisés pour organiser le code en espaces de noms logiques, évitant ainsi les conflits de noms entre les classes, fonctions et constantes. Ils permettent de regrouper le code lié dans des espaces de noms distincts.
Le path mapping (ou path remapping) en TypeScript est un mécanisme permettant de spécifier une correspondance entre les chemins d'importation utilisés dans le code source et les emplacements réels des fichiers sur le disque. Cela permet de structurer le code de manière logique dans l'arborescence des fichiers, sans avoir à respecter strictement la structure des répertoires physiques.
En résumé, les namespace en PHP gèrent principalement les conflits de noms et l'organisation logique du code, tandis que le path mapping en TypeScript gère la correspondance entre les chemins d'importation logiques et les emplacements physiques des fichiers.
@@codeursenior super merci pour l'information 👍
Peux-tu faire une vidéo sur les générateur de code (de projet) tel que Jhipster ? J'ai utilisé cet outil à l'époque quand j'étais étudiant et de junior mais je me retrouvais buté sur des lignes de code que je ne comprenais pas par manque d'expertise.
Hello, le sujet est intéressant, mais je n’ai pas prévu de vidéo là-dessus, d’autant plus que je n’utilise pas cet outil en production donc je n’ai pas grand-chose d’intéressant à dire là-dessus. 👍
Bonjour Simon j'ai suivi votre cours Angular sur Udemy et cela m'a beaucoup aidé mais ce pendant avez vous fait des tuto sur les test unitaires et d'integration angular?
Hello, je ne propose pas de contenu sur les tests actuellement. J'attends de trouver un sujet de vidéo pour faire découvrir le sujet et l'intérêt associé, mais aussi les erreurs courantes dans ce domaine. Ce n'est pas simple d'initier les développeurs là-dessus.
Concernant le point numéro 1, c'est quand même beaucoup mieux de parser/valider les inputs au runtime et d'inférer les types à partir du parseur/validateur que de générer des types automatiquement. Un système de type qui ment c'est aussi grave qu'un système de type désactivé, et puis ça permet, si c'est bien fait, l'utilisation de types union discriminantes ce qui évite d'avoir un certain nombre de champs optionnels quand il y a des dépendances entre plusieurs champs : soit un group de champs couplés est présent en entier, soit il est totalement absent.
C'est même encore plus grave ^^
non, ce n'est pas nécessairement mieux, si par exemple on a une garantie très forte concernant la stabilité de l'API à laquelle on se connecte, en parsant on ajoute de la complexité pour rien
@@franssu2229 C'est pas qu'une question d'API, il peut aussi manquer des données dans ta BDD.
@@ApprendreSansNecessite ok je vois ce que tu veux dire
Merci !
👍
quelle est la difference entre const et readonly?
Je dirais qu'ils sont assez proches mais utilisable à des endroits différents. Readonly sur les instances de classe ou dans la signature d'une fonction tandis que const est utilisé ailleurs comme dans le corps de fonction
@@xSniper974x merci infiniment
a vous ...mais j'ai l'impression que votre réponse n'est pas termine
@@xSniper974x c'est marrant en C++ le const tu peux le mettre partout.
Pour faire court et être efficace : const est pour les variables dont la valeur ne change pas, tandis que readonly est pour les propriétés d’objets qui ne doivent pas être modifiées après l’initialisation.
@@codeursenior Le readonly à été introduit par typescript par le défaut de l’utilisation du const sur un objet qui ne fonctionne pas en javascript!
Salut bro
Stp met nous en place une formation TypeScrip
Hello, oui ça me ferait plaisir de mettre en avantage TypeScript, malheureusement pour l’instant je n’ai pas les ressources pour produire une formation de cette envergure. Mais un jour, peut-être ! Bon code !
Concernant l'absolute path, pour un projet react-ts construit avec vite, il faut configurer le vite.config.ts et le tsconfig.
Hello, merci pour la précision pour les Reacteux. 👍
Concernant l’astuce 3, si on est amené à utiliser les valeurs de l’enum dans le code, pour des comparaisons ou des assignations par exemple, on ne peut pas utiliser l’alternative des union types
Ça nous obligerait à écrire en dur la valeur non ? Donc pas ouf en cas de modif d'une valeur
Hello tout à fait, mais dans ce cas cela veut dire que vous auriez probablement besoin d’une classe. Encore une fois, les énumération ne sont qu’une collection de variables en TypeScript, qui pollue le bundle final.
@@codeursenior Merci pour tes lumières 💡
Pour le 1, il suffit de déclarer une variable et l'affecter à la valeur json, puis de copier le type...
Oui mais tu auras un seul type assez big parfois. L'avantage qu'il présente (ou de passer par copilot) est d'obtenir un ensemble de types séparés. Donc plus modulaire
Merci pour votre réponse, c’est bien ça.
Merci
Avec plaisir et bon code.
Un peu lourd de déclarer chaque paramètre de fonction en readonly. Je préfère configurer ESLint correctement pour éviter de les modifier. Bons conseils, sinon 👍
Oui, excellente remarque. Est-ce que vous avez le nom de la règle ESLint en question ? Elle me paraît indispensable. 👍
Pour le point 2 j'aurais plutôt utilisé un Pick pour préciser les champs déjà présents
ou Omit
It depends. Lui présente cela comme un état transitoire. Cela signifie que par la suite, les options seront disponibles. Un pick ou omit viendrait les blacklist
Merci, je n'aurais pas répondu mieux.
10:33 après les sept-zerreurs, les cinq-zastuces 😉
Haha zetes trop fort.
Pour la 3) le problème c'est d'utiliser des types au lieu de valeurs. L'union type n'est pas enumerable. Il vaut mieux utiliser un object dont chaque propriété est un membre de l'enum en tant que tupe. On peut même faire des unions d'enums avec Object.assign
Salut, je comprends l’idée, mais je vous déconseille encore une fois d’utiliser les énumérations typescript. Passer par un objet déclaré avec « as const » si vous avez besoin des valeurs. Bon code !
@@codeurseniorchaque fois que j'ai essayé d'utiliser les enum, j'ai fini par revenir aux objets. Je ne vois vraiment pas leur intérêt
@@Domnik1968 Pareil, je compte sur vous pour faire de la propagande sur le sujet !
très bonne vidéo par contre pour info il faut dire "immuable" et non "immutable" xD
Hello, le débat est intéressant, mais au boulot on est arrivé à la conclusion d’utiliser le terme immutable. Le nom francisé n’a pas fait l’unanimité !
typescript n'est pas un méta langage
TypeScript n'est pas non plus un langage.
Et ce n'est pas non plus Meta.
À creuser !
Ma bonne pratique préférée:
🤮BAD🤮
type UserResponse = {
isLoading: boolean;
firstname?: string;
lastname?: string;
}
✅GOOD✅
type UserResponse = { isLoading: boolean } | { firstname: string; lastname: string }
Excellent, j’adore ce genre de Snippet de code. C’est un régal.
Le problème avec typscript et copilot ou les autre ia's, c'est qu'ils sont éduqués pour que tu joue le jeu des typages bien faits, et je me retrouve à boucler dans un enfer des déclarations de types où chaque correction apporte une nouvelle erreur.
Je suis pourtant fan de Java et son typage fort, sa verbosité à n'en plus finir, mais après avoir découvert les joies du scripting avec python et javascript, typescript peut surprendre.
Pour des tests ou des poc, j'utilise simplement 'any' partout et basta.
Enfaite le typage est assez simple mais sert surtout pour la relecture du code et une meilleur structure de données. Après oui c'est transpiller en javascript mais sa aide quand même pour le développement. Concraitement oui j'aime aussi m'amuser avec mes scripts bash,python ou js et j'en suis bien content qu'il n'y a pas besoin de typage. Mais quand tu taffe sur un projet sérieux le typage t'aide et t'évite des erreurs. L'avantage de typescript est que TU décide de mettre du typage ou tu veux,la où Java et C++ vont te forcer (ce qui est logique évidemment ;)
Il faut rentrer dans TypeScript, pas simple au départ, car il est fortement construit par-dessus JavaScript et respecte les paradigmes de ce langage parfois étonnant. Bref, il y a un petit coût d'entrée pour le dompter, mais j'estime que cela vaut le coup pour un projet important. Pour un POC ou un petit projet "pédagogique", pas besoin de se casser le crâne là-dessus.