Angular v4: Stocke-t-on des données dans un service, un composant ou les deux?
Angular v4: Stocke-t-on des données dans un service, un composant ou les deux?
Après avoir lu pas mal de tutoriels et lu la documentation de Angular, je ne comprends toujours pas ce sujet.
https://angular.io/tutorial/toh-pt2 Le didacticiel d'Angular montre clairement les données stockées dans le composant.
https://angular.io/guide/architecture#services La section Architecture> Services de Angular affiche le code avec le service contenant un tableau de données (est-ce correct?).
Si nous stockons des données dans Components, nous utiliserions fortement @Input et @Output pour déplacer des données entre des composants enfants (en supposant que nous voulions ces données au début du processus). Toutefois, cela pose un problème lorsque nous utilisons le routage. besoin de notre nouveau composant qui a été chargé à partir du routeur-prise pour faire un nouvel appel à notre service en échange d’une promesse de faire en sorte que l’API appelle notre serveur pour stocker des données. Peut-être dans ce cas, nous aurions 2 composants contenant les mêmes données - mais ils pourraient ne pas correspondre.
Si nous stockons des données dans un service, nous utiliserons fortement nos services pour récupérer des données et manipulerons des données (en supposant que nous souhaitons ces données au début du processus) de cette manière, notre service contient un ensemble de données, et chaque composant peut Faites appel aux données de service à tout moment pour obtenir des données cohérentes.
-
Quelle est la bonne manière de stocker des données? L’un des autres est-il déconseillé?
En règle générale, vous souhaitez stocker des données dans un service si de nombreux composants utilisent les mêmes données. De cette manière, il est extrêmement facile d’accéder aux mêmes données à partir de différentes parties de votre application. Si un composant modifie les données du service, il sera modifié pour tous les composants utilisant les données, ce qui est généralement très utile. Toutefois, il est parfois inutile de ne transmettre que des données d’un composant à un autre, l’un étant le parent de l’autre. Dans ce scénario, l'utilisation d'entrées/sorties serait conseillée.
Si vous n'avez pas besoin d'envoyer les données spécifiques entre différents composants, alors stocker les données dans un composant est parfaitement acceptable! N'oubliez pas qu'il ne sera pas accessible à partir d'autres composants, sauf si vous utilisez des entrées/sorties.
Les contrôleurs de composants doivent uniquement gérer les interactions d'interface utilisateur pour ce composant spécifique.
Les services, d’autre part, gèrent les interactions entre les composants, le mappage des données, la gestion des événements entre les composants qui n’ont pas de relation directe (parent> enfant, frères et soeurs, etc.).
L'idée derrière ceci est qu'un service une fois créé, il reste dans la portée et n'est pas détruit. Les composants de l’autre main sont supprimés du DOM après leur destruction. Cela dit, si vous utilisez votre composant pour effectuer, par exemple, des appels d'API pour collecter des données, cet appel d'API sera effectué chaque fois que le composant est initialisé dans le cycle de vie de la structure, alors que les services, comme déjà mentionné, seront persistants.
La persistance des services nous permet également d’utiliser des éléments tels que les observables, de toujours conserver cette ligne directe entre le serveur principal et le serveur principal.
Espérons que cela aide.
MODIFIER
N'oubliez pas que le didacticiel Angular.io est divisé en plusieurs sections pour vous aider à donner une introduction complète au cadre lorsque l'utilisateur suit le didacticiel.
Si plusieurs composants partagent des données, mettez-les dans un service ... lorsque cela est possible. Je dis quand c'est possible, car en obligeant le service à gérer les données, vous devez maintenant vous soucier des données obsolètes. Mon emplacement de stockage de données goto se trouve dans le composant, mais vous devez être prudent, car vous ne voulez pas obliger le site à extraire à nouveau les données à tout moment.
Personnellement, la plupart de mes composants gèrent leurs propres données afin d'éviter les problèmes de données obsolètes.
Si cela ne vous inquiète pas, vous pouvez même utiliser un service de mise en cache qui, au lieu de stocker les données dans la RAM, les stockera dans le stockage local ou le stockage de session, afin de vous assurer que le site ne soit pas ralenti les données étant mises dans les ordinateurs Ram.
Je ne suis certes pas un expert en la matière, ce n’est que mon opinion.
Vous savez que @Output est lié à un droit EventEmitter, les données sont partagées entre les composants en se liant à des événements . Les services vous permettent généralement de faire quelque chose comme une requête HTTP - quelque chose comme RESTFUL api . Stockage, connectivité réseau ou en tant que compartiment permettant de stocker l'état pendant l'exécution de l'application . Les composants sont généralement associés à Vues et utilisent le DOM fantôme.