Je ne comprends pas trop le point du subscribe/unsubscribe pour le cas du count. Tout ça est géré par le pipe async. Imaginons qu'on ait un gros traitement avec plusieurs opérateurs RxJS (switchmap, map, shareReplay), à aucun moment il est nécessaire de subscribe ou unsubscribe à la main.
Hello, effectivement la vidéo n'est pas très claire sur ce sujet. Ce que souhaitait expliquer, c'est que pour développer un moteur de réactivité basé sur les Observables, c'est une vraie galère.
Tout à fait, c’est d’ailleurs un de leurs rôle détourné, et il y a une librairie officielledont le rôle va être de faire du state management avec les signals : ngrx signal store. Bon code !
Bonjour à tous, donc si j'ai bien compris à pars la fonction computed() qui permet de créer facilement des side effect. Les signals n'apportent qu'un gain de performance. Avec les signals nous ne sommes pas capable en tant que développeur de créer des choses plus puissances mais juste les même choses qu'avant mais en plus performant ?
Salut, non, c'est la méthode Effect qui permet de créer des side effects. Computed sert à calculer un état dérivé à partir d'autres Signals. Et oui, nous pouvons recréer la même chose qu'avec la librairie RxJS, mais avec un gain de performance est un gain de temps et de maintenabilité aussi.
Hello, je suis entrain de me renseigner sur le sujet. Je vous recommande de regarder du côté des Signal Based Component. Dans ce cas, oui toutes les propriétés seront des signals. 👍
Salut, merci pour ton retour. Je n’ai pas prévu de faire une application complète sur le sujet. Par contre c’est sûr que d’autres vidéos devront être faites sur le sujet des Signals, notamment leur intégration avec les formulaires ou RxJs. Bon code !
Mon jugement actuel est que les Signals et les Observables vont cohexister. Le Signal sera par contre de plus en plus présent sur la partie template/rendering et state management.
Ok, on le savait déjà. Mais *comment* les utiliser ? Comment tirer parti au maximum de leurs capacités ? Quel design pattern adopter ? Quel data flow adopter et notamment la frontière entre rxjs et les signaux ? Leur utilité pour collections ? La seule chose qui est rapidement montrée c'est un input signal. Mais ça ne fait rien de plus qu'un input classique au sein du composant. Et ce qui est bound à l'input c'est quoi ? Un autre signal ?? La valeur d'un signal ? Bref, il aurait été intéressant d'avoir la réponse à la question posée dans le titre de cette vidéo. Là, après cette longue vidéo, on reste très largement sur notre faim 😢
La vidéo n'est pas technique, car c'est un second point. La première question, c'est POURQUOI/Quel problème ça résout. Les Signals sont là pour permettre de mettre en place des composants avec une réactivité "Signal Based" à l'avenir dans Angular. Une autre vidéo technique sera prévue dans le prochain tutoriel Angular 17, où on mettra ça en place.
@@codeursenior Excellent ! Ce serait bien de faire un exemple concret avec un arbre de composants, une collection, des appels WS, etc.. un projet un peu étoffé pour voir où laisser rxjs et où mettre des signaux. La doc d'Angular est complètement lacunaire sur les use cases où les utiliser. On se contente d'improviser. Ont-ils parlé de leur utilisation concrète dans cette fameuse conférence ?
@@TTxR2 Hello, entièrement d'accord. Ou en est l'état de l'art avec l'apparition des Signaux ? Notamment la cohabitation RxJS et Signals... Aucun mention dans la conférence sur les futures applications industrielles de tout ça.
@@codeursenior Le boss décide qu'au lieu de passer par la 16, on passerait direct a la 17 une fois qu'elle sera stable. Je crois que la version actuelle est la 12. Autant dire que ça va pas être une tache simple ✋🏼🧔🏼♂️🤚🏼
@@CreativeeteaHello, la montée jusqu'à la version 15 se fait. On a chiffré une journée par montée de version jusque-là. Le passage à la version 16 est plus costaud, si vous avez de vielles dépendances il faut les passer sur Ivy. Cela nous a couté 1 mois de notre côté à titre d'exemple. Bon courage !
@@R.e.n.e Ma question est de savoir si "Signal" est vraiment traduisible. Comme le terme "Observer", je n'ai jamais entendu dire "Il faut modifier le code de ton Observateur".
J'apprends beaucoup grâce à toi Simon, salut depuis le Cameroun
Super, merci pour ton message.
J'espère vous proposer d'autres vidéo prochainement,
Simon.
Moi aussi depuis le Cameroun t'es le meilleur 😊...
@@dessinfacile8960 💪
Merci beaucoup! C'est comme d'habitude expliqué d'une façon bien simple et claire :)
Je ne comprends pas trop le point du subscribe/unsubscribe pour le cas du count.
Tout ça est géré par le pipe async. Imaginons qu'on ait un gros traitement avec plusieurs opérateurs RxJS (switchmap, map, shareReplay), à aucun moment il est nécessaire de subscribe ou unsubscribe à la main.
Hello, effectivement la vidéo n'est pas très claire sur ce sujet. Ce que souhaitait expliquer, c'est que pour développer un moteur de réactivité basé sur les Observables, c'est une vraie galère.
Un grand merci pour la vidéo! J’avais pas encore pris le temps de creuser le sujet depuis la release. Faut s’y mettre 😅
Et oui, l'heure approche à grands pas ! Le plus dur sera les montées de version dans un premier temps, en passant les dépendances à full-IVY.
Merci beaucoup, est-il possible d'aoir un jour un tutoriel basé sur les signals?
Le prochain gros tutoriel de la chaîne sur Angular 17 inclura les Signals par défaut. 👍
Bonjour M. SIMON , j'aimerais moi savoir si les signaux peuvent etre utiliser pour gerer la réactivité de notre application au lieu d'utiliser ngrx
Tout à fait, c’est d’ailleurs un de leurs rôle détourné, et il y a une librairie officielledont le rôle va être de faire du state management avec les signals : ngrx signal store. Bon code !
@@codeursenior d'accord merci infiniment M.SIMON ...
la bibliothèque ngrx signal store est elle deja
disponible ?
@@aboubakardosso3481 Oui, mais toujours en Developer Preview.
Merci Simon
Avec plaisir, bon code !
C'est génial !!!
Je suis d'accord avec vous !
Merci, c'était très intéressant.
Salut, merci pour ton retour. Bon code, Simon.
Bonjour à tous, donc si j'ai bien compris à pars la fonction computed() qui permet de créer facilement des side effect. Les signals n'apportent qu'un gain de performance. Avec les signals nous ne sommes pas capable en tant que développeur de créer des choses plus puissances mais juste les même choses qu'avant mais en plus performant ?
Salut, non, c'est la méthode Effect qui permet de créer des side effects. Computed sert à calculer un état dérivé à partir d'autres Signals. Et oui, nous pouvons recréer la même chose qu'avec la librairie RxJS, mais avec un gain de performance est un gain de temps et de maintenabilité aussi.
j'ai commencé a les utiliser mais pour remplacer les properties en pipe async, mais du coup, le but c'est de créer toute ses propriétés en signals ?
Hello, je suis entrain de me renseigner sur le sujet. Je vous recommande de regarder du côté des Signal Based Component. Dans ce cas, oui toutes les propriétés seront des signals. 👍
super vidéo merci
Au top, bon code à vous.
Bonjour et merci beaucoup pour cette vidéo très claire pour moi; S'il vous plait vous pouvez nous faire une petit app très présentative dans ce sens ?
Salut, merci pour ton retour. Je n’ai pas prévu de faire une application complète sur le sujet. Par contre c’est sûr que d’autres vidéos devront être faites sur le sujet des Signals, notamment leur intégration avec les formulaires ou RxJs. Bon code !
interessant merci Simon ^^
Merci pour ton retour, bon code.
Simon.
Merci beaucoup senior
Vous pouvez m'appeler "codeur seigneur" également.
8:44 Oui, malheureusement j'ai vu ça dans quasi tous les projets initialisés par des "pro programmation réactive", et je confirme, cauchemar assuré.
top du top merci
Merci pour ton excellent commentaire.
Bon code !
Merci beaucoup
💪
Tu es sur que RXJS ne va pas coexister avec les signaux ? J'avais entendu comme quoi RXJS n'allait pas disparaitre ....
Mon jugement actuel est que les Signals et les Observables vont cohexister. Le Signal sera par contre de plus en plus présent sur la partie template/rendering et state management.
Ok, on le savait déjà. Mais *comment* les utiliser ? Comment tirer parti au maximum de leurs capacités ? Quel design pattern adopter ? Quel data flow adopter et notamment la frontière entre rxjs et les signaux ? Leur utilité pour collections ?
La seule chose qui est rapidement montrée c'est un input signal. Mais ça ne fait rien de plus qu'un input classique au sein du composant. Et ce qui est bound à l'input c'est quoi ? Un autre signal ?? La valeur d'un signal ?
Bref, il aurait été intéressant d'avoir la réponse à la question posée dans le titre de cette vidéo.
Là, après cette longue vidéo, on reste très largement sur notre faim 😢
La vidéo n'est pas technique, car c'est un second point. La première question, c'est POURQUOI/Quel problème ça résout. Les Signals sont là pour permettre de mettre en place des composants avec une réactivité "Signal Based" à l'avenir dans Angular.
Une autre vidéo technique sera prévue dans le prochain tutoriel Angular 17, où on mettra ça en place.
@@codeursenior Excellent ! Ce serait bien de faire un exemple concret avec un arbre de composants, une collection, des appels WS, etc.. un projet un peu étoffé pour voir où laisser rxjs et où mettre des signaux.
La doc d'Angular est complètement lacunaire sur les use cases où les utiliser. On se contente d'improviser.
Ont-ils parlé de leur utilisation concrète dans cette fameuse conférence ?
@@TTxR2 Hello, entièrement d'accord. Ou en est l'état de l'art avec l'apparition des Signaux ? Notamment la cohabitation RxJS et Signals...
Aucun mention dans la conférence sur les futures applications industrielles de tout ça.
Merci bien expliqué merci
Au top, merci !
Bon code,
Simon
Deja on va essayer de passer a la version 16 d'Angular 😊
Hello, effectivement Angular 16 impose IVY, ce qui nécessite souvent un gros effort de montée de version des dépendances. Bon courage !
Les gens qui sont sur un projet angular < 13, levez la main ✋
@@codeursenior Le boss décide qu'au lieu de passer par la 16, on passerait direct a la 17 une fois qu'elle sera stable. Je crois que la version actuelle est la 12. Autant dire que ça va pas être une tache simple ✋🏼🧔🏼♂️🤚🏼
@@ascensionspirituelle7287 Pro tips : Monter qu'une version de major à la fois. Donc viser la 13. 👍
@@CreativeeteaHello, la montée jusqu'à la version 15 se fait. On a chiffré une journée par montée de version jusque-là. Le passage à la version 16 est plus costaud, si vous avez de vielles dépendances il faut les passer sur Ivy. Cela nous a couté 1 mois de notre côté à titre d'exemple. Bon courage !
Finalement JavaScript est une école.😅
Il était temps !
Un signal, des signaux…
On dit les signaux ! 😂
Dsl 🥲
Les Signals ou les Signaux ? Le débat reste ouvert.
@@codeursenior Si on parle de l'API, Signals me semble plus cohérent, mais pour le concept en lui même, je dirais les signaux
@@fredV35 Ok, pourquoi pas. Merci pour la précision !
Ça dépend surtout si on veut utiliser le thermes français ou anglais. C'est comme library vs bibliothèque.
@@R.e.n.e Ma question est de savoir si "Signal" est vraiment traduisible. Comme le terme "Observer", je n'ai jamais entendu dire "Il faut modifier le code de ton Observateur".