Structure de projet AngularJS évolutive recommandée?
J'ai vu plusieurs modèles de projets AngularJS: le projet de départ sur le site officiel, Yeoman est généré et AngularFun .
Y a-t-il d'autres modèles (non) avisés que je devrais consulter, ou tout modèle connexe que vous suggéreriez pour un projet AngularJS évolutif?
Par évolutif, je veux dire
- pouvoir diviser des contrôleurs, des directives, des filtres, etc. dans leurs propres fichiers;
- pouvoir charger ces fichiers à la demande plutôt que de faire tout charger par le navigateur;
- être en mesure d'avoir des composants communs à plusieurs projets (par exemple, des directives, des filtres ou des services communs).
Vous pouvez jeter un œil à une application de démonstration que Pawel Kozlowski et moi-même mettons en place: https://github.com/angular-app/angular-app .
Il ne fournit aucune prise en charge pour le chargement de fichiers à la demande, mais vous pouvez voir que nous répartissons les modules dans des fichiers séparés et 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 à la sortie) 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 d'applications fonctionnelles et de code de bibliothèque transversal commun, plutôt qu'une simple division en directives, filtre, services, etc. À côté d'un domaine fonctionnel, nous pourrions avoir certains services, directives, contrôleurs et modèles.
Cela facilite le développement par rapport à un domaine fonctionnel, car tous les éléments pertinents sont au même endroit.
Le projet s'appuie sur un simple serveur nodeJS pour délivrer les fichiers (supportant le deep linking en mode HTML5) et également pour fournir des services d'authentification et d'autorisation.
Vous devriez essayer ng-passe-partout. Le modèle de démarrage le plus prometteur pour les grands projets AngularJS: http://joshdmiller.github.io/ng-boilerplate/#/home
Je dirais que tous vos points peuvent être facilement atteints, au moins sans aucune modification d'Angular.
- pouvoir diviser des contrôleurs, des directives, des 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 type de configuration: https://github.com/elsom25/angular-requirejs-html5boilerplate-seed
- pouvoir charger ces fichiers à la demande plutôt que de faire tout charger par le navigateur;
Comme pkozlowski l'a suggéré dans les commentaires, il y a déjà une entrée avec une description du problème, vous verrez que je travaillais également pour résoudre ce problème, et en fait 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 le paramètre résout la configuration de l'itinéraire.
- être capable d'avoir des composants communs et inter-projets (par exemple des directives, des filtres ou des services communs)
Une fois les points précédents résolus, il pourrait être facilement réalisé en utilisant les modules RequireJs.
Je me demandais si le démarrage d'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 à partir 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 sûr, votre candidature devrait alors être très volumineuse pour que faire tout ce travail supplémentaire soit logique;)
Je suis d'accord avec les points que d'autres ont dit jusqu'à présent; il est très facile de diviser les choses en modules séparés et de faire dépendre les modules les uns des autres avec des trucs AngularJS réguliers. Ensuite, votre code JS peut être divisé en tous les 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 qui est basé sur AngularJS. Nous avons poussé la modularité à un extrême :) hawtio utilise plugins qui peuvent être découverts lors de 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 lors de l'exécution). Donc, sur la base d'une requête REST ou d'une détection JMX, nous pouvons dynamiquement et/ou supprimer des plugins.
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 partiels html (html) et tout le reste (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 qui peut alors dépendre d'autres modules.
Nous n'avons pas encore trouvé beaucoup de choses utiles conventions de dénomination pour les fichiers source jusqu'à présent :). 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 au module général), nous n'avons pour l'instant trouvé aucune autre convention de dénomination significative.
Avertissement: prise sans vergogne.
Vous devriez certainement vérifier generator-angular-xl .
Il vise en particulier à créer des applications AngularJS à grande échelle en regroupant le code de manière logique, en échafaudant des tests unitaires et en injectant automatiquement vos fichiers js et css dans index.html, etc. un bon choix lors du développement de prototypes qui peuvent également devenir des applications complètes. Il ne génère PAS de code back-end, vous êtes donc libre de choisir la technologie back-end que vous souhaitez.
Ce projet semble prometteur http://vesparny.github.io/ng-kickstart
Il vous permet de diviser votre base de code par fonctionnalité et de conserver votre code réutilisable, ainsi que le chargement du foie grâce à une tâche Grunt personnalisée pour cela.
Le projet est également axé sur les tests unitaires et est livré avec une "tâche dist" personnalisée qui vous permet de créer une version optimisée et prête pour la production.