javascript - une - tutorial angularjs nodejs




Structurer une application Node.js et AngularJS (4)

Je suis sur le point de tenter mon premier projet AngularJS, et il est logique d'utiliser Node.js pour le back-end, même si cela signifie apprendre à la fois AngularJS et Node.js en même temps.

La première chose que j'essaie de faire, c'est une bonne structure de fichiers. Jusqu'à présent, mon modèle HTML / CSS pur a la structure de répertoire suivante ...

_site/
Fonts/
Javascript/
SASS/
Stylesheets/
Index.html

(_site est un répertoire de travail pour les PSD, etc.)

J'ai trouvé un exemple de structure de répertoire pour une application Node.js / AngularJS here ....

... ce qui suggère la structure de répertoire suivante.

app.js              --> Application configuration
package.json        --> For npm
public/             --> All of the files to be used in on the client side
  css/              --> CSS files
    app.css         --> Default stylesheet
  img/              --> Image files
  js/               --> JavaScript files
    app.js          --> Declare top-level application module
    controllers.js  --> Application controllers
    directives.js   --> Custom AngularJS directives
    filters.js      --> Custom AngularJS  filters
    services.js     --> Custom AngularJS services
    lib/            --> AngularJS  and third-party JavaScript libraries
      angular/
        angular.js            --> The latest AngularJS
        angular.min.js        --> The latest minified AngularJS
        angular-*.js          --> AngularJS add-on modules
        version.txt           --> Version number
routes/
  api.js            --> Route for serving JSON
  index.js          --> Route for serving HTML pages and partials
views/
  index.jade        --> Main page for the application
  layout.jade       --> Doctype, title, head boilerplate
  partials/         --> AngularJS view partials (partial jade templates)
    partial1.jade
    partial2.jade

Donc, cela me semble assez bon (sauf que je n'utiliserais pas Jade).

J'ai encore les questions suivantes ...

  1. Je veux séparer tous les fichiers frontaux et principaux. Cette solution place tous les fichiers frontaux dans le répertoire public /, ce qui est logique parce que la plupart ont besoin d'être public, mais est-il sensé de mettre les dossiers SASS et _site ici? Je pourrais juste les garder là, mais ne pas les télécharger quand je les mets en production, mais il semble mal parce qu'ils ne devraient pas être publics. Ils n'appartiennent pas non plus au niveau racine avec toutes les choses back-end.

  2. Ne serait-il pas préférable de charger AngularJS à partir d'un CDN ?

  3. Étant donné que le serveur n'aura besoin que de fournir un modèle (le modèle d'application principal) et que tous les autres HTML seront construits sur le frontal, il ne serait pas plus logique de garder le fichier index.html statique, de supprimer le dossier des vues et créer un partials / dossier sous public / comme l'application originale AngularJS Seed fait?

Je me rends compte que tout cela est une question d'opinion, et je pourrais techniquement les mettre où je veux, mais j'espère que quelqu'un de plus expérimenté que moi pourrait me conseiller sur les pièges de diverses structures de répertoires.


1) Il est généralement judicieux de rendre publics les fichiers saas/less , car vous pouvez utiliser la conversion côté client moins> css lors du débogage (less.js le fait). Vous ne savez pas ce que votre _site contient cependant (btw vous devriez utiliser le dossier minuscule pour votre projet, particulièrement pour le truc public) .

2) Il est généralement recommandé de charger AngularJS à partir de Google CDN en production, en utilisant uniquement une version locale pour le développement, vous pouvez avoir deux configurations distinctes en fonction de votre environnement.

3) Même si le rendu côté client est la solution, vous pouvez conserver le rendu du côté serveur / rendu des vues, vous en aurez probablement besoin à un moment donné (accès administrateur, rendu de courrier électronique, etc.). Cependant, il peut être utile d'utiliser le nom des partials d'AngularJS dans le dossier public pour éviter toute confusion entre les views côté serveur et les partials côté client.

Vous devriez clairement opter pour ce qui semble être la chose la plus logique à faire à l'heure actuelle, vous allez probablement déplacer les choses à mesure que vous vous familiariserez avec Express.

Vous devriez vérifier le cadre express existant pour voir comment ils structurent leur application. Par exemple, TowerJS a un dossier de config assez propre, mais ils mélangent le code côté serveur et côté client que personnellement je n'aime pas.

Vérifiez cette comparaison des frameworks NodeJS MVC pour voir comment les autres font des choses. Cependant, je voudrais clairement commencer avec le code de vanilla express afin d'être en plein contrôle et de comprendre comment les choses fonctionnent avant de s'engager trop sur l'un de ces cadres.


Comme suggéré, cela dépend surtout des préférences personnelles et de ce qui fonctionne pour le projet sur lequel vous travaillez à ce moment-là. Toutes les personnes avec qui vous parlez auront des idées différentes et chaque projet a son propre design - ce qui fonctionne pour l'un peut ne pas fonctionner pour l'autre. Je m'attends à ce que vous essayiez quelques structures différentes et en trouverai bientôt une qui soit la plus confortable - mais cela évoluera toujours avec le temps.

J'ai trouvé que la structure Angular Seed était la plus propre, mais encore une fois c'est une préférence personnelle (bien que cela aide à la conception par l'équipe Angular.)

Vous pourriez également envisager de regarder http://yeoman.io/ pour générer des squelettes de projet.

Yeoman est un ensemble d'outils, de bibliothèques et d'un flux de travail robuste et opiniâtre qui peut aider les développeurs à créer rapidement de magnifiques applications web attrayantes.

C'est un excellent outil pour amorcer et gérer des projets (de la même manière que Rails) et créer une structure de répertoires et des fichiers squelettes sur lesquels vous pouvez construire. Brian Ford a écrit un excellent article sur l'utilisation de Yeoman avec Angular.

Je suggère également de regarder les enregistrements Angular Meetup sur leur chaîne YouTube. J'ai récemment assisté à une réunion à Mountain View où ces questions ont été soulevées. Miško a recommandé Angular Seed et Yeoman (au moins comme un bon point de départ.)

Pour répondre à vos questions individuelles:

  1. Tous les fichiers compilés côté serveur doivent être conservés en dehors de votre dossier public. Je suggérerais de ne pas conserver les fichiers PSD, les maquettes ou tous les autres fichiers qui ne sont pas destinés à la consommation publique (par le navigateur ou l'utilisateur) dans les dossiers publics.

  2. Il est toujours bon de servir des ressources statiques (JS, images, CSS) à partir d'un CDN si vous vous attendez à un trafic élevé. Ce n'est pas si important pour les sites les moins visités, mais c'est toujours une bonne idée. Je commencerais par servir les fichiers localement pour le développement initial. Laissez l'optimisation des actifs lorsque vous approchez de votre date de diffusion. Lorsque cette heure arrivera, vous aurez également besoin de mettre en place votre mise en cache correctement. Yeoman, par exemple, présente un bon moyen de versionner vos assets. Cela vous donne l'avantage de disposer de caches de longue durée mais vous permet de pousser les mises à jour des fichiers vers les clients.

  3. Si votre fichier d'index ne nécessite aucun rendu côté serveur, servez-le de manière statique. J'aime garder mon backend découplé du backend autant que possible avec les applications Angular. Cela aide à maintenir la séparation des préoccupations. lors du développement des fichiers client, vous n'avez pas besoin de penser au backend (Angular est génial pour ça).

Vraiment, vous avez juste besoin de jouer autour; essayer différentes choses, lire des articles de blog, obtenir des idées d'autres, poser des questions (comme vous avez fait ici, et sur la page de la communauté Angular Google+), regarder des vidéos et, si vous le pouvez, participer à des meetups.


Je ne suis pas d'accord avec tous les messages précédents. Ils sont soit collés d'un autre endroit ou n'ont pas leur propre esprit. De mes expériences, il est préférable d'aplatir vos codes côté client. Je veux dire que le code dans votre répertoire client devrait être dans votre répertoire racine.

Pourquoi est-ce que je suggère de cette façon? Parce que si vous voulez changer votre projet JavaScript full-stack pour celui sans backend, mais seulement pour le frontend, c'est beaucoup plus simple. Je veux dire que la plupart des projets écrits avec JavaScript sont axés sur le frontend.

Il est préférable de mettre votre code backend dans un répertoire comme "server" au même niveau que "css", "image" ... L'avantage est que lorsque vous avez besoin ou non d'un backend, il suffit d'ajouter ou supprimez le répertoire "serveur" et cela n'affecterait pas la structure du projet d'origine.

Comme ça:


Les choses deviennent plus faciles au fil du temps. J'ai utilisé Yeoman pour l'interface AngularJS, et ça rend la vie beaucoup plus facile: http://yeoman.io/

Option 1, MEAN.io

MEAN est un acronyme génial! Je préfère la structure de répertoire de pile MEAN. Utilisons les gens de convention! Utilisez simplement la structure de répertoire de mean.io. MEAN est pratique aussi parce qu'il jette tous les goodies comme Grunt , Bower , etc.

Option 2, graines angulaires + Express.js

J'ai cherché GitHub pour les projets Node.js / AngularJS (probablement pas assez dur) et je n'ai rien vu de vraiment génial pour une structure de répertoire de départ. J'ai donc fusionné le Node.js Express.js (exécutant Express.js à partir de la ligne de commande en utilisant ni EJS ni Jade/Pug ) avec le projet angular-seed (le cloner depuis GitHub ). Ensuite, j'ai déménagé une tonne de choses autour. Voici ce que j'ai trouvé:

  • developer - trucs seulement le développeur (s) utilisera. N'a pas besoin d'être déployé.
    • fichiers de configuration config - karma et autres.
    • scripts - scripts développement (build, test et deploy)
    • test - e2e et tests unitaires.
  • logs
  • node_modules - cette réponse a recommandé de mettre ceci dans Git. Cependant, cela peut maintenant être obsolète .
  • public - Cela vient presque directement du dossier de l'application angular-seed.
    • css , img , js , lib , partials - assez évident et agréable et court.
  • routes - routes Node.js.
  • server - côté serveur "shebang" Node.js programmes, démons, programmes cron, peu importe.
  • server.js - renommé à partir de app.js juste pour le rendre plus évident c'est côté serveur.





node.js