Structure de projet AngularJS évolutive recommandée?

J’ai vu plusieurs modèles de projet AngularJS: le projet initial sur le site officiel, Yeoman généré et AngularFun .

Y a-t-il d’autres modèles (non) sans opinion que je devrais examiner ou tout modèle que vous suggéreriez pour un projet AngularJS évolutif?

Par scalable je veux dire

  • être capable de séparer les contrôleurs, les directives, les filtres, etc. dans leurs propres fichiers;
  • être capable de charger ces fichiers à la demande plutôt que de tout charger avec le navigateur;
  • être capable d’avoir des composants communs à plusieurs projets (par exemple, directives, filtres ou services communs).

Vous pouvez jeter un oeil à une application de démonstration que Pawel Kozlowski et moi mettons en place: https://github.com/angular-app/angular-app .

Il ne fournit aucun support pour le chargement de fichiers à la demande, mais vous pouvez voir que nous crachons des modules dans des fichiers distincts et que nous configurons les tests en tant que composant de première classe. Nous avons un processus de construction (utilisant Grunt) qui concatène (et réduit au minimum) les fichiers js et peut exécuter des tests unitaires et de bout en bout.

Nous avons choisi de diviser nos modules en deux groupes de domaines d’application fonctionnels et de code de bibliothèque transversal commun, plutôt qu’un simple fractionnement en directives, filtre, services, etc. Dans un domaine fonctionnel, nous pouvons avoir des services, des directives, des contrôleurs et des modèles.

Cela facilite le développement par rapport à un domaine fonctionnel car tous les éléments pertinents se trouvent au même endroit.

Le projet s’appuie sur un simple serveur nodeJS pour fournir les fichiers (prenant en charge le lien profond en mode HTML5) et pour fournir des services d’authentification et d’autorisation.

Je dirais que tous vos points peuvent être facilement atteints, du moins sans aucune modification de Angular.

  • être capable de séparer les contrôleurs, les directives, les filtres, etc. dans leurs propres fichiers;

Cela peut bien sûr être fait avec Angular de base, car vous pouvez inclure autant de balises de script avec des contrôleurs / services que vous le souhaitez. Bien sûr, ce n’est pas du tout évolutif, donc la meilleure option serait d’utiliser des modules AMD, comme RequireJS. C’est l’une des graines qui ont ce genre de configuration: https://github.com/elsom25/angular-requirejs-html5boilerplate-seed

  • être capable de charger ces fichiers à la demande plutôt que de tout charger avec le navigateur;

Comme l’a suggéré pkozlowski dans les commentaires, il y a déjà et une entrée avec une description du problème, vous verrez que je travaillais aussi pour résoudre ce problème et que j’ai eu quelques résultats. J’ai un exemple pratique de chargement de contrôleurs, de modèles et de directives à la demande à l’aide de RequireJS et de la configuration du paramètre de configuration de la route.

  • être capable d’avoir des composants communs à plusieurs projets (par exemple, directives, filtres ou services communs)

Ayant résolu les points précédents, il pourrait être facilement réalisé en utilisant les modules RequireJs.


Je me demandais si lancer un projet agularjs-lazy-seed serait une bonne idée? Y a-t-il une demande pour cela? Nous pourrions même aller plus loin et déplacer les configurations de routes en dehors de la configuration habituelle, disons que vous avez un fichier views.json (idéalement un service qui répond avec json) avec les vues que vous souhaitez inclure dans votre application:

{ "views" : { .... "account" : { "path" : "/account" // route path "name" : "Account", // view name "partial" : "views/account/account.html", // partial file "controller" : "account/main" // RequireJS module "directives" : [ "directives/version", "directives/menu" ] // directives used in the view } .... } } 

De cette façon, vous pourriez:

  • développer les vues en séparation et construire l’application en fonction de ce bootstrap json
  • avoir des directives et des composants communs
  • Lorsque bootstrap après la connexion, vous pouvez filtrer les vues que l’utilisateur est autorisé à voir
  • tout à l’intérieur du ngView serait chargé à la demande

Bien entendu, votre candidature devrait être très importante pour que tout ce travail supplémentaire soit logique;)

Vous devriez essayer ng-passe-partout. Le template kickstart le plus prometteur pour les projets AngularJS plus importants: http://joshdmiller.github.io/ng-boilerplate/#/home

Je suis d’accord avec les points que les autres ont déjà exprimés. il est très facile de diviser les éléments en modules distincts et de faire en sorte que les modules dépendent les uns des autres avec des éléments AngularJS standard. Ensuite, votre code JS peut être divisé en fichiers et arborescences de répertoires que vous préférez.

Je pensais juste mentionner ce que nous faisons dans le projet open source hawtio basé sur AngularJS. Nous avons pris la modularité un peu à l’extrême 🙂 hawtio utilise des plugins qui peuvent être découverts à l’exécution sur le serveur en cours d’exécution (par exemple, déployer et annuler le déploiement des fonctions de l’interface utilisateur au moment de l’exécution). Donc, sur la base de certaines requêtes REST ou de la détection JMX, nous pouvons dynamicment ou supprimer des plug-ins.

par exemple, voici tous nos plugins par défaut actuels

En termes de mise en page, chaque plugin a ses propres répertoires pour le code (js), les partals html (html) et toute autre chose (par exemple les répertoires css / img), ce qui permet de garder les choses agréables et modulaires. Par exemple, voici le plugin camel qui a ses propres dossiers html, js et img.

Ensuite, un plugin spécifique définit son propre module AngularJS, ses directives, ses filtres et peut alors dépendre d’autres modules.

Cependant, nous n’avons pas encore trouvé beaucoup de conventions de nommage utiles pour les fichiers sources :). Nous trouvons que l’écriture d’un fichier par contrôleur semble la plus simple; mais à part le fichier fooPlugin.ts et le fichier helpers.ts (pour les fonctions d’assistance spécifiques aux modules généraux), nous n’avons pas encore trouvé d’autres conventions de nommage significatives.

Ce projet semble prometteur http://vesparny.github.io/ng-kickstart

Il vous permet de diviser votre code par fonction et de conserver votre code réutilisable, ainsi que de charger le foie grâce à une tâche Grunt personnalisée.

Le projet est également orienté vers les tests unitaires et comprend une “tâche dist” personnalisée qui vous permet de créer une version optimisée et prête pour la production.

Attention: bouchon sans vergogne.

Vous devez absolument vérifier générateur-angular-xl .

Il vise en particulier à créer des applications AngularJS à grande échelle en regroupant les codes logiquement, en testant les unités d’échafaudage et en injectant automatiquement vos fichiers js et css dans index.html, etc. un bon choix lors du développement de prototypes pouvant également devenir des applications à part entière. Il ne génère aucun code de back-end, vous êtes donc libre de choisir la technologie de back-end souhaitée.