🎬 Angular v19 - Schematic de migration vers les signaux (Signal Input, Output Function, Signal Queries) Avec la stabilisation de l'API de communication entre composants et des signal queries dans la version 19, Angular met à notre disposition un nouveau Schematic qui facilite la migration de gros projets en seulement quelques lignes de commande. Dans cette vidéo, nous verrons comment ce nouveau Schematic permet de migrer des projets, les différentes options qui s'offrent à nous, ainsi que comment corriger les problèmes que l'on peut rencontrer lors de son utilisation (par exemple, la casse du two-way data binding ou les erreurs dans les tests des inputs). Vous trouverez le lien de la vidéo complète dans les commentaires. 🧠 Stay Curious! #devPropulsor #angular #migration #Schematic #Signal #SignalInput #OutputFunction #SignalQueries

🎬 Apprendre Angular de zéro - Input, Output : Communication entre Composants Après avoir découvert les composants Angular, exploré leur structure et les actions possibles au niveau du template d'un composant, nous allons aborder dans cette vidéo les "inputs" et "outputs". Des mécanismes simples, fournis par Angular, permettant à un composant de communiquer avec son composant parent. Comme nous le verrons, Angular repose par défaut sur un système de communication unidirectionnelle pour l’échange de données entre composants parent et enfant. Il permet d'utiliser les : - input (Singal Input): pour passer des données du parent vers l'enfant. - output (Output Function): pour transmettre des données de l'enfant vers le parent. Vous trouverez le lien de la vidéo complète dans les commentaires. Cette vidéo fait partie de la série "Apprendre Angular de zéro par la pratique", destinée aux débutants ou à ceux voulant se mettre à niveau avec Angular (version ≥ 19). Vous trouverez également le lien de la playlist est en commentaire. 🧠 Stay Curious! #devPropulsor #angular #tutos #learnAngular #crashCourse #apprendreAngulardeZero #v19Plus #component #communication #parentChild #signalInput #outputFunction

@angular Writing a few components using the SignalInput. It is very simple and tidy. I suspect most of the changes I will make is have signalinput components as views, and leave most of the observable state as is. A few things I've noted. It doesn't take too long before I ran into stuff that is going to change. Like forms. The toSignal interop is quite nice. You end up with lots of type complications with observables, and having a default value removes the |null from the type. I started changing a few things in a large complicated component, but ran into some roadblocks very quickly. You write and structure data flows using the available tools; signals require a different approach. I would characterize it as 'pull'. Instead of setting or pushing values as configuration, you need to pull values from changing data. I started with some setters, and realized that I needed to start on the other end, where the data was consumed and work backwards. I can see how easy it will be to create extremely long complicated and brittle change trees.

I mean yeah, a non-rxjs one if we want to push towards a "rxjs as a non-core concept" to ease the learning curve. I wouldn't want to have: count = signalInput(0); // fn name is imaginative @Output() someOutput = ...; // decorators vs non-decorators