J'étais entrain de suivre ton tuto hier et je me suis rendue compte que j'avais la version 17 et j'ai vite été perdue. J'espère trouver un bon tuto avec cette nouvelle version d'Angular
Il est possible de suivre le tuto avec la version 17, je l'ai fait récemment. Tu trouveras dans les commentaires du tuto des astuces pour prendre en compte la 17. Notamment, il faut utiliser "- -no-standalone" pour se retrouver dans le cadre des modules sans utiliser le mode "standalone" qui n'existait pas à l'époque du tuto.
Mon prochain « gros » tutoriel sera sûrement une mise à jour pour Angular 17, avec un nouveau tournage vidéo prévu. 👍 En attendant, comme indiqué dans le commentaire ci-dessus, eh bien je vous invite à utiliser l’option--no-standalone pour suivre le tutoriel.
Hello, oui je pense que cette fois je ne vais pas mettre à jour le tutoriel Angular, mais complètement tourner à nouveau les 9h de tutoriels ! 👍 (Je ne sais pas si j’aurais le temps de faire ça cette année)
Salut, tu penses que c'est mieux pur moi d'attendre ta nouvelle vidéo tuto Angular.js ou bien, je peux suivre la vidéo actuelle ? Je ne veux vraiment pas regarder 9 heures de tuto si c'est outdated@@codeursenior
@@hassanekonate9941 Hello, si tu utilises l'option --no-standalone à la génération du projet, 90% du contenu te servira sur Angular 17. A toi de voir, je ne serai pas en mesure de produire un nouveau tutoriel de 9h avant Juin 2024. A toit de voir selon tes objectifs ! Bon code, Simon.
J’avais du mal avec le mode standalone mais j’ai pu refaire le site Pokédex avec les standalone j’ai eu quelques difficultés au niveau de la directive mais j’ai finalement opté pour les Hostbinding. Quand j’ai pu faire fonctionner la directive j’ai mangé dans un restau chic 😂😂😂
Merci pour cette vidéo Simon. J'ai essayé d'utiliser les signaux mais je trouvais que c'était plus complexe pour moi que rxjs. Ça peut effectivement être plus utile pour résoudre des problèmes de performance dans des projets complexes. Si on commence à les utiliser maintenant on sera plus apte à détecter dans quelles situations les utiliser.
10 місяців тому
Apparemment les signaux pour la partie composants template et on garde les observables pour la partie composants services et le module @angular/core/rxjs-interop pour transformer de l'un à l'autre et inversement... @JoshuaMorony a fait des vidéos pas mal la dessus en anglais même si je trouve qu'il va trop vite dans ces explications.
D’accord, mais j’ai des warnings qui s’allument dans ma tête. Quel intérêt d’utiliser 2 API différentes ? C’est comme Observable/Promesse. Même si théoriquement, on pourrait utiliser les promesses pour des cas simples, c’est au final préférable de tout uniformiser sur une seule api des observables. Je ne vois pas le gain à venir utiliser une Api de Signals séparés actuellement, à part ce que j’ai mentionné dans la vidéo. Avez-vous un lien vers les vidéos que vous mentionnez ? Bon code !
10 місяців тому
@@codeursenior Pour commencer : Angular is about to get its most IMPORTANT change in a long time : ua-cam.com/video/4FkFmn0LmLI/v-deo.html Un premier essai : I used Angular's signals to build an actual app ua-cam.com/video/p2RJ7xXIRII/v-deo.html Pour continuer : Why didn't the Angular team just use RxJS instead of Signals? ua-cam.com/video/iA6iyoantuo/v-deo.html
10 місяців тому+1
@@codeursenior il y a des avantages apparemment sur les signals mais il faut se faire sa propre opinion et son propre découpage méthodologique si on souhaite combiner RxJS pour l'asynchrone et les signals pour la gestion d'état synchrone.
C’est moins verbeux à utiliser que les observables et ça sera plus performant pour le futur algo de changement de détection, donc y’a juste plus d’intérêt à utiliser des observables à part dans les sections de code où tu ne « peux pas » te passer d’un observable. Par là je veux dire quand ça sort du domaine de « compétence » des signaux. En tous cas j’utilise les signaux depuis quelques semaines et c’est un pur kiff. Le système de signal computed c’est du bonheur 😊
Je suis dev Vue mais c'est cool de voir qu'Angular rattrape son retard sur les autres frameworks. Les signals sont le standard pour la réactivité (excepté chez React) pour une bonne raison, tu vas vite y adhérer je pense. Par contre, le passage à Vite aurait permis d'utiliser Vitest pour les units tests au lieu de Jest. Y'a du gain de perf à aller cherche de ce côté là. ✌
Salut, d’accord pour ton retour sur Vite/Jest, je ne connais pas encore la raison de ne pas l’avoir intégrer directement. Concernant les Signals, mon point est sur le double emploie avec RxJS déjà très répandu dans l’écosystème Angular. J’ai l’impression que cela va apporter plus de confusion qu’autre chose pour le moment : Observable ou Promesse ? observable ou Signal ? Etc. Le fait que la dépendance sur RxJS soit forcée dans un projet Angular le pousserai à favoriser en priorité cette librairie.
10 місяців тому
@@codeursenior j'ai le même ressenti sur les Signals, super outil mais avec RXJS déjà bien installé dans notre quotidien, pour le moment, le seul plus (qui n'en est pas un) c'est de me demander quand privilégier l'un plutôt que l'autre. Quel est la volonté de l'équipe Angular, je me trompe certainement mais aujourd'hui à part me dire que ça ressemble à "nous aussi on sait faire du "reactive dev tools" je ne vois pas pourquoi venir marcher sur les plats de bandes de RXJS. Je serai ravi d'être contredit et convaincu par l'utilité par de vrais cas d'utilisations. PS: Je te suis depuis quelques mois et je trouve ta chaîne très intéressante et sujets bien présentés. Au plaisir d'avoir d'autres retours sur les Signals ;)
Hello @ . Tu t'exprimes mieux que moi, car c'est exactement mon ressenti également sur les Signals. Si j'ai des retours intéressants sur l'API des Signals en production, je n'hésiterai pas à vous faire un retour en vidéo. Bon code à toi !
Salut, pour le moment je dirai que rien n’a changé. Angular montre juste sa volonté de rester dans la course du « top 3 frontend », ce qui me semble être une bonne chose. On a vite fait de devenir un framework JavaScript dépassé de nos jours. 😉
Le schematics pour le nouveau Control Flow fonctionne pas mal. Par contre avec 2 espaces pour l'indentation par défaut. Faut aussi penser à mettre à jour eslint/prettier
Bonjour Simon tu pense refaire un tuto complet avec un nouveau projet angular 17 ou tu va reprendre Pokedex pour nous expliquer les changement des grande ligne de angular17 parceque je sort tous juste de la formation angular sur openclassrooms et je vous faire le tuto Pokedex mais avec la version 17 je c pas trop........
10 місяців тому+1
Je suis un peu étonné pour ta "v3" de la syntaxe des Control Flow : tu positionne @if et @else sur les balises à conditionner en affichage alors que dans la doc officiel et autres articles de blog qui parlent de cette nouvelle fonctionnalité, on voit toujours la syntaxe que tu as mis en intro du point 3, c'est à dire que les balises à conditionner sont à l'intérieur des blocs @if et @else, c'est à dire entre accolades... Est ce une possibilité non documentée ou une coquille ? 🙂
10 місяців тому
Je pencherais plutôt pour une coquille car avec un @ sur une balise, Angular attends apparemment un trigger d'animation
Salut Cédric, merci pour ton retour. Effectivement, après vérification, il s’agit bien d’un coquille. 👍 Le lien est en description de la vidéo vers la documentation officielle sur ce sujet.
Je ne pense pas qu'il soit vraiment possible qu'angular reprenne le lead sur REACT, Il se peut qu'il redevienne un framework populaire dans certains type de dev ,type app metier, mais sur l'ensemble c'est a mon avis trop tard.
Angular est depuis longtemps le framework le plus utilisé pour faire des app par la majorité des grosses entreprises.... Il faut utiliser chaque framework pour son domaine de prédilection : React/nextjs c est fait pour faire du site web, Angular c est fait pour faire de l app web....
Hello, effectivement je pense que React restera le framework frontend le plus populaire. Angular ne semble ps vouloir prendre cette place, pour se concentrer sur les projets d’applications web « grand groupe », qui sont les clients de prédilection. Bon code !
Merci Simon pour votre debrief. Je suis un dev Angular & React. Le soucis actuel est que la plupart des boites utilisent encore Angular 12.X.X sortis depuis 2021. je me demande comment la team Angular pourra faire adopter ses new best partices une bonne fois. comme l'a été le cas de React v16 avec les function component.
Hello, merci pour ton retour. Il me semble que les boîtes qui restent bloqué sur une trop ancienne version de Angular finiront par avoir une version du framework qui n’est plus supporté, et donc devront se mettre à jour. Qu’en penses tu ?
Bah ça va être tjs la même histoire... On va upgrader le legacy en Angular 16 sans utiliser les nouvelles fonctions (vu que la compatibilité ascendante marche plutôt bien avec l outil de migration Angular). L utilisation en production d Angular 17 avec les nouveautés (nouvelle syntaxe template, signals, etc...) Ce sera pour les nouveaux projets en 2026/2027 (tjs 3 ans de retard en gros dans les gros SI ce qui est raisonnable pour laisser les petits boîtes éponger les bugs et s assurer que la version est viable)
Hello, certains grands principes que je présente s’applique à toutes les applications web quel que soit le framework choisir. Mais la chaîne reste orienté Angular en priorité. Bon code !
Bonjour, normalement vous ajoutez vos nouveaux composants dans vos routes, avec une balise dans le composant racine AppComponent. Il n’y a pas besoin de toucher au index.html. Bon code !
Hello effectivement. De ce que j’ai pu voir, la Angular Team prendra en charge build-in Vite et Jest, mais pas vitest. Cela demandera potentiellement de la configuration supplémentaire. Bon code !
@@codeursenior Après quelques recherches, j'ai trouvé réponse à la question du "pourquoi" sur une issue du repo GitHub d'Angular CLI qui est intéressante, tu peux rechercher sur Google "[Unit Testing] Why not use vitest instead of jest · Issue #25217" (Puisqu'on ne peut pas mettre de liens dans les commentaire youtube :D) Happy coding !
Mmmm pas vraiment d'accord avec les standalone components, c'est une tentative de simplification pour rendre Angular plus accessible. Mais honnêtement, ça ne simplifie rien, au contraire, beaucoup de redondance.
Merci beaucoup !! je viens de commencer Angular je suis un peu perdu avec les tutos qui date avant Angular 17 maitenant c'est plus claire🙂
Il y a trop peu de youtuber francophone dont la techno principale est Angular, merci Simon pour ta veille Angular et de nous tenir à jour :)
Merci, à bientôt pour de prochaines vidéos !
J'étais entrain de suivre ton tuto hier et je me suis rendue compte que j'avais la version 17 et j'ai vite été perdue. J'espère trouver un bon tuto avec cette nouvelle version d'Angular
Il est possible de suivre le tuto avec la version 17, je l'ai fait récemment. Tu trouveras dans les commentaires du tuto des astuces pour prendre en compte la 17. Notamment, il faut utiliser "- -no-standalone" pour se retrouver dans le cadre des modules sans utiliser le mode "standalone" qui n'existait pas à l'époque du tuto.
La Doc officielle est un bon tuto. Dans le get started il y a un projet pas à pas avec des explications à chaque étape !
Mon prochain « gros » tutoriel sera sûrement une mise à jour pour Angular 17, avec un nouveau tournage vidéo prévu. 👍
En attendant, comme indiqué dans le commentaire ci-dessus, eh bien je vous invite à utiliser l’option--no-standalone pour suivre le tutoriel.
@@codeursenior oh ce serait le top vraiment 🎉🥳🎊 effectivement je vais finir le tutoriel mais en adaptant à Angular 17 tout de même
@@AA-nu7ht Avec un peu de courage et 70h devant moi c'est jouable ! 💪
J’attendais tellement ta réaction concernant A17 😊
Et bien ça y est, plutôt enthousiaste pour la suite donc 😉
Merci pour les infos. En attente. De vos super vidéo sur la version 17.
Hello, oui je pense que cette fois je ne vais pas mettre à jour le tutoriel Angular, mais complètement tourner à nouveau les 9h de tutoriels ! 👍
(Je ne sais pas si j’aurais le temps de faire ça cette année)
Salut, tu penses que c'est mieux pur moi d'attendre ta nouvelle vidéo tuto Angular.js ou bien, je peux suivre la vidéo actuelle ? Je ne veux vraiment pas regarder 9 heures de tuto si c'est outdated@@codeursenior
@@hassanekonate9941 Hello, si tu utilises l'option --no-standalone à la génération du projet, 90% du contenu te servira sur Angular 17. A toi de voir, je ne serai pas en mesure de produire un nouveau tutoriel de 9h avant Juin 2024. A toit de voir selon tes objectifs !
Bon code,
Simon.
❤ ta vidéo tombe bien je dois bosser sur un combo back/front maven/angular
Au top, enjoy ! 🙂
J’avais du mal avec le mode standalone mais j’ai pu refaire le site Pokédex avec les standalone j’ai eu quelques difficultés au niveau de la directive mais j’ai finalement opté pour les Hostbinding. Quand j’ai pu faire fonctionner la directive j’ai mangé dans un restau chic 😂😂😂
😂
Mdrr excellent.
Merci pour cette vidéo Simon.
J'ai essayé d'utiliser les signaux mais je trouvais que c'était plus complexe pour moi que rxjs. Ça peut effectivement être plus utile pour résoudre des problèmes de performance dans des projets complexes. Si on commence à les utiliser maintenant on sera plus apte à détecter dans quelles situations les utiliser.
Apparemment les signaux pour la partie composants template et on garde les observables pour la partie composants services et le module @angular/core/rxjs-interop pour transformer de l'un à l'autre et inversement... @JoshuaMorony a fait des vidéos pas mal la dessus en anglais même si je trouve qu'il va trop vite dans ces explications.
D’accord, mais j’ai des warnings qui s’allument dans ma tête. Quel intérêt d’utiliser 2 API différentes ? C’est comme Observable/Promesse. Même si théoriquement, on pourrait utiliser les promesses pour des cas simples, c’est au final préférable de tout uniformiser sur une seule api des observables. Je ne vois pas le gain à venir utiliser une Api de Signals séparés actuellement, à part ce que j’ai mentionné dans la vidéo. Avez-vous un lien vers les vidéos que vous mentionnez ? Bon code !
@@codeursenior Pour commencer : Angular is about to get its most IMPORTANT change in a long time : ua-cam.com/video/4FkFmn0LmLI/v-deo.html
Un premier essai : I used Angular's signals to build an actual app ua-cam.com/video/p2RJ7xXIRII/v-deo.html
Pour continuer :
Why didn't the Angular team just use RxJS instead of Signals? ua-cam.com/video/iA6iyoantuo/v-deo.html
@@codeursenior il y a des avantages apparemment sur les signals mais il faut se faire sa propre opinion et son propre découpage méthodologique si on souhaite combiner RxJS pour l'asynchrone et les signals pour la gestion d'état synchrone.
C’est moins verbeux à utiliser que les observables et ça sera plus performant pour le futur algo de changement de détection, donc y’a juste plus d’intérêt à utiliser des observables à part dans les sections de code où tu ne « peux pas » te passer d’un observable. Par là je veux dire quand ça sort du domaine de « compétence » des signaux.
En tous cas j’utilise les signaux depuis quelques semaines et c’est un pur kiff.
Le système de signal computed c’est du bonheur 😊
Je suis dev Vue mais c'est cool de voir qu'Angular rattrape son retard sur les autres frameworks. Les signals sont le standard pour la réactivité (excepté chez React) pour une bonne raison, tu vas vite y adhérer je pense. Par contre, le passage à Vite aurait permis d'utiliser Vitest pour les units tests au lieu de Jest. Y'a du gain de perf à aller cherche de ce côté là. ✌
Du gain de perf sur des tests ?
Est-ce vraiment intéressant ?
Salut, d’accord pour ton retour sur Vite/Jest, je ne connais pas encore la raison de ne pas l’avoir intégrer directement. Concernant les Signals, mon point est sur le double emploie avec RxJS déjà très répandu dans l’écosystème Angular. J’ai l’impression que cela va apporter plus de confusion qu’autre chose pour le moment : Observable ou Promesse ? observable ou Signal ? Etc. Le fait que la dépendance sur RxJS soit forcée dans un projet Angular le pousserai à favoriser en priorité cette librairie.
@@codeursenior j'ai le même ressenti sur les Signals, super outil mais avec RXJS déjà bien installé dans notre quotidien, pour le moment, le seul plus (qui n'en est pas un) c'est de me demander quand privilégier l'un plutôt que l'autre. Quel est la volonté de l'équipe Angular, je me trompe certainement mais aujourd'hui à part me dire que ça ressemble à "nous aussi on sait faire du "reactive dev tools" je ne vois pas pourquoi venir marcher sur les plats de bandes de RXJS. Je serai ravi d'être contredit et convaincu par l'utilité par de vrais cas d'utilisations.
PS: Je te suis depuis quelques mois et je trouve ta chaîne très intéressante et sujets bien présentés. Au plaisir d'avoir d'autres retours sur les Signals ;)
Hello @ . Tu t'exprimes mieux que moi, car c'est exactement mon ressenti également sur les Signals. Si j'ai des retours intéressants sur l'API des Signals en production, je n'hésiterai pas à vous faire un retour en vidéo. Bon code à toi !
Merci pour ce résumé
Merci à vous, bon code.
Simon.
Pour la nouvelle syntaxe du control-flow à 6:44, on aurait pas plutôt cela ? :
@if (role ===admin) {
You're logged in as admin.
}
Tu es très bon vendeur :)
Et du coup, comment se positionne Angular par rapport à Vue et React, avec ces nouveautés ?
Salut, pour le moment je dirai que rien n’a changé. Angular montre juste sa volonté de rester dans la course du « top 3 frontend », ce qui me semble être une bonne chose. On a vite fait de devenir un framework JavaScript dépassé de nos jours. 😉
@@codeursenior Merci beaucoup pour le feedback !
@@v-sig2389 De rien, bon code !
Le schematics pour le nouveau Control Flow fonctionne pas mal. Par contre avec 2 espaces pour l'indentation par défaut. Faut aussi penser à mettre à jour eslint/prettier
Hello, merci pour le feedback. Je me note de update notre configuration ESLint après la migration. 👍
Bon code, Simon.
Bonjour Simon tu pense refaire un tuto complet avec un nouveau projet angular 17 ou tu va reprendre Pokedex pour nous expliquer les changement des grande ligne de angular17 parceque je sort tous juste de la formation angular sur openclassrooms et je vous faire le tuto Pokedex mais avec la version 17 je c pas trop........
Je suis un peu étonné pour ta "v3" de la syntaxe des Control Flow : tu positionne @if et @else sur les balises à conditionner en affichage alors que dans la doc officiel et autres articles de blog qui parlent de cette nouvelle fonctionnalité, on voit toujours la syntaxe que tu as mis en intro du point 3, c'est à dire que les balises à conditionner sont à l'intérieur des blocs @if et @else, c'est à dire entre accolades...
Est ce une possibilité non documentée ou une coquille ? 🙂
Je pencherais plutôt pour une coquille car avec un @ sur une balise, Angular attends apparemment un trigger d'animation
Salut Cédric, merci pour ton retour. Effectivement, après vérification, il s’agit bien d’un coquille. 👍
Le lien est en description de la vidéo vers la documentation officielle sur ce sujet.
Je ne pense pas qu'il soit vraiment possible qu'angular reprenne le lead sur REACT, Il se peut qu'il redevienne un framework populaire dans certains type de dev ,type app metier, mais sur l'ensemble c'est a mon avis trop tard.
Angular est depuis longtemps le framework le plus utilisé pour faire des app par la majorité des grosses entreprises.... Il faut utiliser chaque framework pour son domaine de prédilection : React/nextjs c est fait pour faire du site web, Angular c est fait pour faire de l app web....
Hello, effectivement je pense que React restera le framework frontend le plus populaire. Angular ne semble ps vouloir prendre cette place, pour se concentrer sur les projets d’applications web « grand groupe », qui sont les clients de prédilection. Bon code !
Merci Simon pour votre debrief. Je suis un dev Angular & React. Le soucis actuel est que la plupart des boites utilisent encore Angular 12.X.X sortis depuis 2021.
je me demande comment la team Angular pourra faire adopter ses new best partices une bonne fois. comme l'a été le cas de React v16 avec les function component.
Hello, merci pour ton retour. Il me semble que les boîtes qui restent bloqué sur une trop ancienne version de Angular finiront par avoir une version du framework qui n’est plus supporté, et donc devront se mettre à jour. Qu’en penses tu ?
Bah ça va être tjs la même histoire... On va upgrader le legacy en Angular 16 sans utiliser les nouvelles fonctions (vu que la compatibilité ascendante marche plutôt bien avec l outil de migration Angular). L utilisation en production d Angular 17 avec les nouveautés (nouvelle syntaxe template, signals, etc...) Ce sera pour les nouveaux projets en 2026/2027 (tjs 3 ans de retard en gros dans les gros SI ce qui est raisonnable pour laisser les petits boîtes éponger les bugs et s assurer que la version est viable)
@@codeursenior Merci effectivement mais puisque ça marche donc ils font avec 😎.
Salut. Je vis au Canada. Ici, c'est React et Vue. Les enseignes tu?
Hello, certains grands principes que je présente s’applique à toutes les applications web quel que soit le framework choisir. Mais la chaîne reste orienté Angular en priorité. Bon code !
Comment ajouter un composant standalone à index. Html ou app. Html ?
Bonjour, normalement vous ajoutez vos nouveaux composants dans vos routes, avec une balise dans le composant racine AppComponent. Il n’y a pas besoin de toucher au index.html. Bon code !
@@codeursenior super merci
Dommage de passer sur Vite mais de ne pas bénéficier de Vitest pour lancer les tests unitaires, non ?
Hello effectivement. De ce que j’ai pu voir, la Angular Team prendra en charge build-in Vite et Jest, mais pas vitest. Cela demandera potentiellement de la configuration supplémentaire. Bon code !
@@codeursenior Après quelques recherches, j'ai trouvé réponse à la question du "pourquoi" sur une issue du repo GitHub d'Angular CLI qui est intéressante, tu peux rechercher sur Google "[Unit Testing] Why not use vitest instead of jest · Issue #25217" (Puisqu'on ne peut pas mettre de liens dans les commentaire youtube :D)
Happy coding !
J'ai l'impression que tu as rangé ton étagère
A l'image de tes vidéos. Clair , carré
A l’image de mon code aussi !
mddrr, j'en reviens pas, tout ça ne me donne toujours pas envie de faire du front end.
Haha, ok ! La vidéo n’avait absolument pas pour but de vous donner envie de faire du frontend, le contraire aurait été étonnant. Bon code !
Perso je trouve que Jasmine c'est bien mieux que Jest.
Mmmm pas vraiment d'accord avec les standalone components, c'est une tentative de simplification pour rendre Angular plus accessible.
Mais honnêtement, ça ne simplifie rien, au contraire, beaucoup de redondance.