Je suis tellement confus. Angularjs nécessite des services, des contrôleurs et des directives à créer dans des modules. Mais ces services, contrôleurs et directives peuvent être injectés dans tout autre service, contrôleur ou directive indépendamment du module qu'ils existent! Correct? Et, je n'ai vu aucun ID ou outils qui se soucient des noms de module ... autres que NG-APP. Alors, pourquoi créer plusieurs modules? La création de modules a-t-elle un avantage autre que la capacité de lecture dans le code source?
Exemple ... P>
(function(module) {
var dir = function(something) {
return {
};
};
module.directive("myDirective", dir);
}(angular.module("pointlessModuleName")));
3 Réponses :
Il est possible de créer un gros module qui fait tout, mais Angular a été configuré afin que vous puissiez distribuer la responsabilité sur différents modules.
~ la création de modules a réellement un avantage autre que la lecture-capacité?
Vous voudrez peut-être lire un peu ce que les différentes choses en matière angulaire. Par exemple, un service peut être considéré comme un singleton qui renvoie toujours les mêmes données. C'est génial pour créer une demande HTTP de recevoir des données d'une API.
Une directive est faite de manière à ce qu'il ait accès à la DOM à l'aide de JQLite, ce qui le rend important pour la création de composants de l'interface utilisateur. Puis angulaire a un tas d'autres choses que vous pouvez créer dans un module comme des constantes.
Il y a des tonnes d'introductions à l'angular disponibles où toutes ces choses sont expliquées. Si vous recherchez un bon IDE, j'utilise personnellement une zone Web qui a un grand support angulaire.
J'ai mal compris / mal interprété votre question un peu j'avais.
Vous seriez capable de créer un module appelé «application» qui contient toutes vos directives, toutes vos directives, toutes vos directives, toutes vos directives, vos contrôleurs, etc. Permettez-moi de lier aux avantages des modules du site Web angulaire ( https://docs.angularjs.org/guide/module ):
Point 1 est votre lisibilité.
2 signifie une facilité d'utilisation. Vous seriez capable de créer une bibliothèque avec des widgets HTML par exemple que vous pouvez utiliser dans différents projets. Notez que si vous voulez des bibliothèques tiers, vous utilisez déjà le système de module.
3 signifie flexibilité avec le chargement de modules.
4 + 5 signifie testabilité. Si vous auriez un module avec tout votre code là-bas, vous ne serez pas en mesure de tester des éléments séparés de votre application aussi simple. Vous pouvez plus facilement remplacer les paramètres, mais également injecter des objets simulés dans vos modules.
Cela n'aide pas vraiment. J'ai construit plusieurs applications angulaires jusqu'à présent. Et, j'ai regardé plusieurs tutoriels angulaires (vient de terminer le livre de jeu angulaire de Scott Allen). La création de directives ou de services n'est pas la question. J'essaie de trouver un avantage direct du module.
Autant que je sache, les seules raisons de disposer de plusieurs modules sont de satisfaire la modularité de code, d'atteindre un accouplement en vrac et de réaliser un entretien facile à l'avenir.
Par exemple, vous pouvez avoir un module d'application qui dépend d'autres modules qui mettent en œuvre des zones fonctionnelles spécifiques. Ces modules ignorent quoi que ce soit externe à eux-mêmes et ne devrait pas se soucier de manière idéale.
Disons que vous disposiez d'un module de référentiel de données comprenant des services et des usines qui traitent des API de repos de certains services Web. Vous pouvez essentiellement réutiliser ce module dans plusieurs applications. C'est plug-and-jouer essentiellement. Mettre tous les services dans un module séparé qui peut être injecté dépeccencieusement est un moyen de l'emballer bien et de le rendre réutilisable.
Votre exemple de code d'utilisation du module n'est pas idéal à mon avis, ni Souhaitez-vous qualifier une NIFE comme module? Je ferais quelque chose de plus comme ceci: aussi, voici un bon article Vous pouvez regarder. Faites défiler jusqu'à la section sur les modules de regroupement par fonctionnalité.
Bien sûr, je l'obtiens. Mais j'attends quelque chose pour accuser réellement la présence du module. Par exemple, en Java et C #, il y a un espace de noms. IDES ne montre que ce qui est disponible dans les espaces de noms qui ont été inclus. Je supposerais qu'un module devrait fonctionner de la même manière. Cependant, tous les IDIQUES que j'ai utilisés (zones Web, crochets, etc.) ne filtrent rien sur la base des modules inclus. Et, le module n'a pas à préfixer quoi que ce soit lors de l'injection d'un service ou d'un contrôleur. C'est comme si le module n'existe tout simplement pas. Alors, quel est le point?
@ G.Deward Vous voulez dire que vous attendez quelque chose d'ailleurs un Human pour accuser réception de la présence d'un module. Vous semblez trop révéler l'argument de la lisibilité, que vous reconnaissez dans votre question.
J'ai édité ma réponse pour inclure un exemple de code. Il reconnaît la présence des modules dépendants par son nom lorsqu'il est utilisé de cette façon. Je ne sais pas ce que vous entendez par IDE reconnaissant le nom du module. Vous attendez-vous à un soutien IntelliSense?
@Brett: Merci pour la mise à jour. Je suppose que je cherche autre chose que la lisibilité. Mettre en place une syntaxe supplémentaire dans un fichier est généralement mauvais si cela ne fait rien. Cela semble plus approprié pour un commentaire. Même la syntaxe ci-dessus, où vous y compris datepo , cela pourrait être un service avec exactement le même avantage. Je ne vois pas comment utiliser un module accorde spécifiquement quoi que ce soit.
@ G.deward Même si datepo est simplement un service. Le fait que vous puissiez simplement l'injecter dans un autre module n'est-il pas une bonne fonctionnalité pour les modules? Souvent, je suis capable de réutiliser des codes à travers les applications simplement parce que je suis séparé dans des modules. Des modules séparés rendent également les tests beaucoup plus plus facilement.
@ G.deward Il existe de nombreux avantages pour modulariser le code - encapsulation, cachette d'informations, abstraction, testabilité, etc. datapepo pourrait contenir plus de fonctionnalités qu'un simple service et traite de la séparation des préoccupations. Indiquant que datarepo pourrait être implémenté comme un service est vrai, mais ce service serait explicitement lié au module MyApp . datapepo sous forme modulaire n'est pas. Vous constaterez que cette "syntaxe supplémentaire" est très minime par rapport à toutes les autres méthodes de mon expérience et ne nécessite aucun commentaire à comprendre.
Je pensais exactement la même chose et j'ai décidé de marcher du côté sauvage et de tout fusionner sous un seul module. Bien sûr, seulement pour découvrir quelques minutes plus tard pourquoi ce n'était pas une bonne idée :) Je voudrais donc prendre le temps d'expliquer où je pense que les modules jouent un très bon rôle, indépendamment de "l'opinion générale". < P> J'ai commencé avec quelque chose dans le sens de: Je voulais ajouter une vue offrant une liste de serveurs. Une vue, en essence, n'est pas beaucoup plus qu'une combinaison d'un contrôleur avec un itinéraire, donc j'ai ajouté ceux au code. Voici ce que j'ai obtenu (et puis je vais expliquer pourquoi ce n'est pas si agréable et comment un sous-module résout): Bien que ce soit certainement un ensemble valide up, ce que je n'aime pas à propos, c'est que Donc, un peu dans le même vein que votre ife, j'ai ajouté une méthode statique sur et Je pensais que cela semblait légèrement mieux, mais maintenant l'utilisation de Puis il m'a eu lieu que, si je peux écrire un ife pour prendre Donc, en conclusion, je pense que le grand avantage d'utiliser des sous-modules n'est pas nécessairement que d'autres peuvent réutiliser mon code (je ne peux pas 'T Pense que tout le monde sera jamais intéressé par la vue de ma liste de serveurs), mais que chaque bit de code peut se tenir seul, réutiliser le code des autres personnes, sans exiger que le module principal inclure tout cela. Le note de pied. Il semble toujours un peu étrange d'avoir main.js définit le contrôleras et les propriétés de templatef-templateL . Pour moi, cela estime que ces propriétés devraient vraiment être définies lorsque le code dépend de celui-ci est défini --- './ vues / liste-liste-liste-vue' , peut-être même sur le ServerListView classe elle-même. ServerListView pour ajouter la vue sur le module: 'serverdata' me dérangeait. Après tout, il n'a pas été déclaré dans Server-List-View.js n'importe où. De même, si la vue aurait besoin d'un module externe supplémentaire, je devrais modifier main.js pour l'ajouter. Cela se sent hors de la place. module comme argument, pourquoi pas seulement le laisser prendre angulaire < / code> comme argument? Ensuite, cela peut définir son propre module mais il plaît et inclure toutes les dépendances nécessaires. De plus, si vous êtes toujours fanatique sur un seul module - tout, utilisez simplement le nom du module 'Serverload' et déposez la déclaration de dépendance. C'est la seule et entière différence! main.js reste maigre pendant que le serveur-liste-visualiser.js peut tirer dans toutes sortes de choses. Serverload comme une dépendance (pour atteindre l'usine serverData usine). Dans la version 4, cette usine vivra également dans son propre sous-module, bien sûr; -)
Pour séparer tous les composants tels que le service, l'usine, le contrôleur, etc..is les mêmes que comme des espaces de noms dans le code qui séparent les modules
Bien sûr, mais rien n'a jamais reconnu le module. Les IDes ne se soucient pas du nom du module. Angulaire ne se soucie pas du nom du module. Je peux utiliser des services et des contrôleurs sans jamais spécifier un module. Alors, quel est le point?
La plus grande avantage de plusieurs modules est la portabilité du code. Très facile de prendre un de vos modules à un autre projet ou de déposer des modules trouvés via n'importe quel nombre de ressources en ligne.
@ G.deward angular se soucie du nom du module. Si vous souhaitez utiliser quelque chose à partir d'une bibliothèque 3ème partie, vous devez d'abord faire référence au module de la bibliothèque par son nom. Dire que vous pouvez utiliser des services et des contrôleurs sans jamais spécifier un module n'est pas toujours vrai.