Angular 1.5 - Communication inter composants fils et Bindings

Bonjour,

Je travaille actuellement sur un projet et je me retrouve dans la situation suivante :

J'affiche dans ma page web un composant père. Ce dernier a deux composants fils.
Je souhaiterais communiquer entre mes deux composants fils, en effet l'un des composants fils est dépendant de ce que l'utilisateur à entré dans le premier composant fils pour afficher correctement des informations.

Après plusieurs recherches, j'ai tenté l'utilisation de bindings en faisant passer l'information à travers mon composant parent ( j'ai tenté d'utiliser un binding "=" sur mon composant fils pour que une fois la donnée modifiée elle le soit aussi dans mon composant père). Cela n'a rien donné :D

Comme vous l'avez surement deviné, je suis plutôt débutant sur Angular, notamment sur l'usage des components que nous venez a peine d'intégrer dans le projet. J’aimerais donc avoir dans un premier temps vos avis sur quels moyens utiliser pour répondre à mon besoin (Est-il possible de communiquer directement entre les deux composants fils sans passer par le père ? Si je dois passer par le père, dois-je utiliser le bindings "=" ou le "&" avec le callback ? ).


Je suis à disposition pour répondre à vos questions si je n'ai pas été clair :D

Cordialement,
JCTurboo

Citation:

---

Envoyé par JCTurboo

J'affiche dans ma page web un composant père. Ce dernier a deux composants fils.
Je souhaiterais communiquer entre mes deux composants fils, en effet l'un des composants fils est dépendant de ce que l'utilisateur à entré dans le premier composant fils pour afficher correctement des informations.

Après plusieurs recherches, j'ai tenté l'utilisation de bindings en faisant passer l'information à travers mon composant parent ( j'ai tenté d'utiliser un binding "=" sur mon composant fils pour que une fois la donnée modifiée elle le soit aussi dans mon composant père). Cela n'a rien donné :D

---

Pour les bindings, c'est probablement parce que tu passes en paramètre des primitives au lieu de passer un littéral. Si tu passes un littéral il sera manipulé par référence, donc l'instance dans tes composants fils sera identique.

Mais le problème des bindings c'est que ça modifie le contrat d'interface de ton composant, et lorsque tu commences à avoir un niveau de plus dans ta hiérarchie, les composants du milieu se retrouvent à servir de passe plat pour des composants plus bas dans la hiérarchie. Ils ont donc des parties de leur contrat d'interface qui ne les concernent absolument pas. C'est mal.

La meilleure pratique reste pour moi de passer par un service qui va porter les données. L'idéal c'est d'avoir RxJS dans le projet pour pouvoir utiliser les observables (cf exemple doc Angular2+), sinon il suffit de faire porter les données à l'instance du service puisque ces derniers sont des singletons. L'inconvénient c'est qu'il ne faut pas oublier de réinitialiser les valeurs portées par le service lorsque la vue contentant ta famille de composants est affichée.

Tout d'abord merci pour cette réponse rapide !

Concernant l'utilisation de services pour la communication des infos, je vais proposer cela à ceux qui sont en charges de l'architecture du projet.

Je dois cependant en attendant me contenter des bindings :)
J'ai tenté de comprendre ce que vous m'avez dit concernant les paramètres primitifs et littéraux mais je pense avoir échoué... haha
Je comprends dans l'idée qu'il faille passer une référence mais je ne vois pas comment.. ni où ? :/

Voici comment s'organise mon code (J'ai simplement mis ce qui concerne la partie binding):

Code:

---

1 2 3 4 5 6

ComposantFilsComponent.js :   bindings: { foo: '=?' },

---

Code:

---

1 2 3 4

ComposantFils.html <input type="text" ng-model="boo"> <button href="" ng-click="$ctrl.function(boo)">Rechercher</button>

---

Code:

---

1 2 3 4 5 6

ComposantFilsController :   this.function= function(boo){ this.foo=boo; };

---

Code:

---

1 2 3 4

ComposantPere.html   <case-details case="$ctrl.foo"></case-details>

---

Code:

---

1 2 3

ComposantPereController.js this.foo= 'Hello';

---

Excusez-moi pour le côté barbare, j'ai tenté d'adapter pour le rendre le plus explicite possible mais voici ce que je fais. Lorsque je clique sur mon bouton, la fonction "function" est bien appelée et la valeur de foo dans le composantFils est bien valorisé à boo. Cependant du côté de mon composantParent, il ne se "met pas à jour" et garde l'ancienne valeur ("Hello").

Je suis vraiment désolé de ne pas avoir réussi a comprendre directement votre solution et de vous exposer mon code d'une manière aussi moche mais je ne vois pas vraiment comment faire sinon :oops:
Merci beaucoup en tout cas et bonne journée.
Cordialement,
JCTurboo

Autant pour moi, l'erreur venait principalement du fait que je suis un abruti :D (faute d'étourderies, je passais mon paramètre à un autre composant...)


Merci !

C'est très simple, au lieu de faire ça this.foo = 'Hello'; dans ton composant père, tu fais ça : this.foo = { bar: 'Hello' };.

Et dans le js de ton fils :

Code:

---

1 2 3 4

this.function= function(boo){ this.foo.bar = boo; };

---

Le reste n'a pas besoin de changer.

Citation:

---

Concernant l'utilisation de services pour la communication des infos, je vais proposer cela à ceux qui sont en charges de l'architecture du projet.

---

Du coup si tu as des gens au dessus qui gèrent l'archi (plusieurs ?!?) leur as-tu posé la question ? Ils relisent ton code ? Ils t'ont donné des bonnes pratiques à suivre ? Ils t'ont fourni un projet starter avec des exemples pour démarrer ?

Yes j'avais finalement réussi a le comprendre :D Merci encore pour la solution !

C'est assez spécial haha Nous sommes dans un grand projet et nous développons une nouvelle IHM.
C'est surtout un archi et un dev expérimenté qui se charge de l'architecture et des outils utilisés selon leurs envies et les besoins :)
On utilise un webstarter pack gulp qui est assez répandu pour Angular1.5.

Ils ne relisent pas mon code dans le sens où personne n'étant encore à l'aise avec les component, nous découvrons et codons un peu "ensemble" haha, concernant les bonnes pratiques on se fie à celles que nous avions pour les versions antérieures d'angular et de ce que l'on peut glané comme info sur le net.

Concernant lees services. Ils ne sont pas très chauds, nous utilisons des services pour que notre IHM communique avec d'autres composants mais notre IHM sera assez basique donc il ne devrait pas y avoir plus de 2 niveaux hiérarchiques, pour cette raison ils préfèrent ne pas les utiliser pour de la communication inter-composants, du moins pour le moment.


JCTurboo

Par contre il faut que je précise un truc, il manquait une information dans ton post initial, il ne s'agit pas de partager des données, mais de partager le résultat d'un évènement utilisateur (le clic sur le bouton rechercher).

C'est très différent. Dans ce cas de figure, il est recommandé de binder non pas la valeur mais la fonction du clic. Tu comprends bien que ton composant contenant le bouton ne doit pas implémenter le comportement. C'est au composant container de ta vue de gérer ça. Donc il faut lui passer la fonction à exécuter au clic et pas la valeur du champ rechercher.

C'est assez bien expliqué dans le developper guide AngularJS de la 1.5.

Citation:

---

Envoyé par JCTurboo

On utilise un webstarter pack gulp qui est assez répandu pour Angular1.5.

---

AngularJS et encore plus la 1.5 c'est complètement obsolète. Gulp est aussi en forte perte de vitesse. AngularJS sera freeze cet été, il n'y aura plus aucun développement dessus après la sortie de la 1.7. Le "standard" sur les technos Google c'est Angular + Webpack.

Citation:

---

Envoyé par JCTurboo

Concernant lees services. Ils ne sont pas très chauds, nous utilisons des services pour que notre IHM communique avec d'autres composants mais notre IHM sera assez basique donc il ne devrait pas y avoir plus de 2 niveaux hiérarchiques, pour cette raison ils préfèrent ne pas les utiliser pour de la communication inter-composants, du moins pour le moment.

---

Dommage, les services + RxJS et les observables pour communiquer c'est l'état de l'art.

Merci beaucoup de l'info, je vais me pencher sur ce lien pour corriger mon erreur :)

Citation:

---

AngularJS et encore plus la 1.5 c'est complètement obsolète. Gulp est aussi en forte perte de vitesse.

---

Ehhhehe c'est bien malheureux mais c'est déjà une évolution pour nous. Notre IHM principale est en Angular 1.4, de mémoire.. le projet n'a que 2 ans mais les outils utilisés ne sont pas ceux à la pointe de la technologie haha. Les joies des grosses SSII avec de gros projets j'imagine.

En fait tu avais indiqué la solution dans ton post initial :

Citation:

---

Si je dois passer par le père, dois-je utiliser le bindings "=" ou le "&" avec le callback ? ).

---

Citation:

---

Notre IHM principale est en Angular 1.4, de mémoire.. le projet n'a que 2 ans mais les outils utilisés ne sont pas ceux à la pointe de la technologie haha. Les joies des grosses SSII avec de gros projets j'imagine.

---

T'inquiète je suis exactement dans le même cas de figure, par contre on reste pas en 1.5 on monte 1.6 asap.

Deux ans sur un dev web de nos jours c'est très long !

Haha nice merci :) J'essaye de mettre ça en place.

Force à toi ! Merci en tout cas pour cette résolution et cette discussion c'était très instructif !

Après discussion avec mes collègues, nous avons une petite question !

Le but d'utiliser des composants est la modularité, c'est de pouvoir réutiliser ces composants de manière indépendante sur plusieurs "écrans".

Dans notre cas on aura potentiellement 4 composants pères qui appelleront le même composant fils (sur 4 "pages" différentes). Mais si on utilise le callback, le traitement que devait faire notre composant fils sera pris en charge par le composant père.
Nous perdons donc le côté indépendant et modulaire, nous serions obligé de dupliquer la partie traitement dans les 4 composants pères qui vont l'appeler non ?

Ou alors je n'ai pas compris quelque chose ? :D

Si jamais tu peux m'éclairer la dessus !

Citation:

---

Le but d'utiliser des composants est la modularité, c'est de pouvoir réutiliser ces composants de manière indépendante sur plusieurs "écrans".

---

Pas seulement, c'est aussi un moyen de structurer une SPA qui devient alors un arbre de composants ("tree of components" sur Google ça renvoie pas mal de résultats). Certains sont réutilisables mais pas tous.

Il faut considérer 3 types de composants :

- les composants gérant les vues
- les composants gérant les containers
- les composants gérant le visuel

Si on fait un tableau des responsabilités ça peut donner ceci :

Responsabilités	Comp. Vues	Comp. Containers	Comp. Visuels	Stateless ou Statefull ?
Lire les paramètres des routes	OUI	NON	NON	Statefull
Utiliser les stores et les services	NON	OUI	NON	Statefull
Gérer l'affichage et le style	NON	NON	OUI	Stateless

Les composants vues sont des containers spécialisés qui ne gèrent que les vues. Donc c'est ce type de composant que tu vas instancier dans ta route ui-router. Ils lisent les paramètres des routes si besoin (path param ou/et query param) pour les transmettre aux containers qui vont bien.

Ensuite ta vue est décomposée en containers (on aurait pu nommer ça bloc aussi). Si tu n'en as qu'un seul tu peux considérer que ta vue est le container en elle-même si tu ne veux pas faire un sous-container unique.

Les composants containers gèrent l'état de leur container. C'est depuis ces composants que tu centralises la gestion de ton bloc, l'injection des services, le passage de fonctions / data aux composants stateless, la gestion des API REST, etc ... Ils n'affichent pas de données directement ni de boutons, champs ou autre. En terme html la balise racine pourrait être du div, du section, du article, etc ...

Les composants visuels prennent de la data en entrée et se content de l'afficher en gérant le visuel. Ils prennent également en entrée les callbacks des fonctions à exécuter sur les évènements (ng-click, ng-change, ng-if, etc ...). On essaiera au max d'utiliser la notation "one time binding" ({{ ::$ctrl.obj.prop }}) pour avoir des composants réellement stateless. Il va de soit que des composants gérant un formulaire ne peuvent pas être stateless c'est un cas d'exception mais ça se gère très bien.

Comme les composants d'affichage sont stateless avec un contrat d'interface clair, et que les évènements sont passés sous forme de callback, ils ne contiennent aucune implémentation (c'est vital), et ils sont hautement réutilisables.

Les autres composants (vues et containers) ne sont pas réutilisables et on ne devrait pas chercher à le faire, ils représentent des composants à usage uniques qui agrègent des composants visuels ou même d'autres containers, la vue bidule, le bloc machin de la vue bidule, le sous bloc truc du bloc machin de la vue bidule, ...

Pour réutiliser de la logique métier on passe toujours par des services.

En fait on n'écrit jamais de la logique dans un composant. On passe toujours par un service. Si tu as un branchement conditionnel ou une boucle ou même une résolution de promesse dans un controller de composant ou même dans un life-cycle hook (onInit, onChange, ...) c'est que tu fais mal. On fait tout ça dans des services uniquement, c'est beaucoup plus facile à tester et à réutiliser.

Donc pour ta question sur la duplication des traitements on ne les code pas dans les composants mais dans des services qui seront injectés dans les composants au besoin.


Pour tout ceci, je m'inspire des articles suivants :

- The 3 component categories in Angular
- Presentational and Container Components : Dan Abramov (ReactJS team, Redux author)
- Best Practices de Todd Motto

Il y en a beaucoup d'autres et il y a des différences de point de vue selon les personnes, par exemple pour Todd Motto il n'y a que 2 types de composants, les stateless et les statefull.

Si vous avez d'autres questions hésitez pas :)