Disons que j'ai un magasin (un gros objet singleton) où je garde l'état général de l'application. Ce magasin est injecté aux composants si nécessaire. Cependant, certains composants n'utilisent qu'une seule propriété du magasin et l'utilisent pour les conditions dans leurs modèles (en lecture seule bien sûr).
Y a-t-il une pratique préférée ici? Dois-je utiliser la propriété directement à partir du magasin injecté
class MyComponent {
someFlag: boolean;
constructor(private store: Store) {
this.someFlag = store.someFlag;
}
}
// template
<div *ngIf="someFlag">...</div>
ou dois-je créer une propriété privée dans le composant puis l'utiliser dans un modèle?
class MyComponent {
constructor(private store: Store) {}
}
// template
<div *ngIf="store.someFlag">...</div>
Je suis surtout préoccupé par les performances - l'accès aux données d'un gros objet dans un modèle affecte-t-il les performances des cycles de détection de changement angulaire?
3 Réponses :
Tout d'abord, je préfère utiliser directement store.someFlag car cette propriété peut être modifiée et elle sera immédiatement reflétée sur la page alors que si vous l'assignez à une variable locale, cette variable ne change pas les heures supplémentaires (sauf si vous faites quelque chose ). L'affectation à une variable a du sens si vous prévoyez de modifier cette valeur localement et ne souhaitez pas que la modification soit propagée vers le magasin. Je le fais lorsque je veux que ma date d'application s'applique initialement à cet écran, mais l'écran peut changer la date déjà locale et forcer l'utilisateur à le faire.
Et deuxièmement, si vous prévoyez d'utiliser le magasin dans le modèle, assurez-vous que vous le rendre public dans le constructeur (et non privé) car il ne passera pas de règles de production plus strictes.
class MyComponent {
constructor(public store: Store) {}
}
class MyComponent {
constructor(public store: Store) {}
}
// template
<div *ngIf="store.someFlag">...</div>
This will be the better option. As if you make a local copy of that variable then on change detection it may happen that your value when changed from different module/component will not be reflected in this component.
Je voudrais signaler un problème différent que je vois avec l'approche: vous liez les composants à la façon dont vous avez implémenté l'état global. En faisant cela, vous les associez étroitement.
Supposons que vous souhaitiez modifier la structure de votre état global. Par exemple, vous souhaitez déplacer un objet d'un niveau vers le bas dans la hiérarchie de l'état. Avec votre approche, vous devrez toucher chaque composant, éventuellement plusieurs fois par composant.
Je recommanderais de laisser les composants aussi stupides que possible. Donnez-leur un objet réel qu'ils peuvent lire ou modifier en tant que @Input () . Laissez-les travailler dessus. Ajoutez un @Output () quand / si l'objet change.
De cette façon, vous séparez plus clairement les préoccupations: les composants ont juste besoin de savoir comment gérer une classe spécifique, pas avec l'état général.
Mais que se passe-t-il si j'ai besoin de cet état dans à peu près tous les composants, ne deviendra-t-il pas fastidieux et complexe de gérer la propriété / @ Input et l'événement / @ Output?
Si c'est un "gros objet singleton" comme mentionné dans la question, et que vous avez besoin de ce gros objet singleton dans chaque composant, je pense que quelque chose ne va pas avec l'architecture. Dans ce cas, oui, ce serait fastidieux et complexe, mais ce ne serait qu'un indicateur d'un problème ailleurs.
Oui, il est vrai que tous les composants ne nécessiteraient pas le même «gros objet singleton» mais pas pour les composants avec un niveau de hiérarchie supérieur à 3. Existe-t-il d'autres moyens possibles de partager des données au niveau 4-5 en dessous de la hiérarchie des composants autres que les entrées / sorties?
Vous pouvez, bien sûr, fournir de plus grandes parties de votre état à vos composants. C'est toujours un compromis où vous devez trouver la meilleure option pour votre cas d'utilisation concret. J'éviterais simplement de passer le même objet d'état géant à chaque composant et par conséquent perdre a) flexibilité, b) testabilité, c) vue d'ensemble.