Quelles sont les meilleures pratiques pour structurer une application Meteor grande avec de nombreux fichiers de modèle HTML ?

Question

Dans tous les exemples (classement, jeux de mots, etc.), ils ont un seul fichier de modèle HTML. Y a-t-il certains grands opensource Meteor projet avec plusieurs fichiers modèles HTML différents, que nous pouvons utiliser comme un exemple de pratique exemplaire ? Ne semble pas pratique de mettre le tout a besoin d’un grand app tous dans un fichier.

Answer 1

Comme dans le titre officieux de meteor faq, je pense que c'est à peu près explique comment la structure d'un grand app:

Where should I put my files?
The example apps in meteor are very simple, and don't provide much insight. Here's my current thinking on the best way to do it: (any suggestions/improvements are very welcome!)

lib/                    # <- any common code for client/server. 
lib/environment.js      # <- general configuration
lib/methods.js          # <- Meteor.method definitions
lib/external            # <- common code from someone else
## Note that js files in lib folders are loaded before other js files.

collections/                 # <- definitions of collections and methods on them (could be models/)

client/lib              # <- client specific libraries (also loaded first)
client/lib/environment.js   # <- configuration of any client side packages
client/lib/helpers      # <- any helpers (handlebars or otherwise) that are used often in view files

client/application.js   # <- subscriptions, basic Meteor.startup code.
client/index.html       # <- toplevel html
client/index.js         # <- and its JS
client/views/<page>.html  # <- the templates specific to a single page
client/views/<page>.js    # <- and the JS to hook it up
client/views/<type>/    # <- if you find you have a lot of views of the same object type

server/publications.js  # <- Meteor.publish definitions
server/lib/environment.js   # <- configuration of server side packages

Pour des applications plus importantes, discret fonctionnalité qui peut être divisé en sous-répertoires qui sont eux-mêmes organisés en utilisant le même modèle. L'idée ici est que, finalement, le module de la fonction pourrait être pris en compte dans un autre smart package, et, idéalement, de partage.

feature-foo/               # <- all functionality related to feature 'foo'
feature-foo/lib/           # <- common code
feature-foo/models/        # <- model definitions
feature-foo/client/        # <- files only sent to the client
feature-foo/server/        # <- files only available on the server

En savoir plus: non officiels Meteor FAQ

Answer 2

Je suis d’accord avec yagooar, mais au lieu de :

client/application.js

Utilisation :

client/main.js

les fichiers principaux sont chargés de la dernière. Cela aidera à faire en sorte que vous n’avez pas des problèmes de commande de charge. Consultez la documentation de Meteor, http://docs.meteor.com/#structuringyourapp, pour plus de détails.

Answer 3

Meteor a été conçu pour vous la structure de votre application assez bien de toute façon que vous voulez. Donc, si vous n'aimez pas votre structure, vous pouvez simplement déplacer un fichier dans un nouveau répertoire, ou même de diviser un fichier en plusieurs morceaux, et à Meteor son joli beaucoup tout de même. Il suffit de noter le traitement spécial de client, le serveur et les annuaires publics, comme spécifié dans la documentation principale de la page: http://docs.meteor.com/.

Juste de regrouper le tout dans un HTML de remplissage ne sera certainement pas émerger comme une meilleure pratique.

Voici un exemple d'une structure possible: dans une de mes applications, un forum de discussion, j'organise par module ou "type de page" (accueil, forum, sujet, un commentaire), en mettant .css, .html, et .fichier js pour chaque type de page ensemble dans un répertoire. J'ai aussi une "base" du module, qui contient de la commune .css et .code js et le maître modèle, qui utilise {{renderPage}} à rendre à l'un des autres modules selon le type de routeur.

my_app/
    lib/
        router.js
    client/
        base/
            base.html
            base.js
            base.css
        home/
            home.html
            home.js
            home.css
        forum/
            forum.html
            forum.js
            forum.css
        topic/
            topic.html
            topic.js
            topic.css
        comment/
            comment.html
            comment.js
            comment.css

Vous pouvez également organiser en fonction

my_app/
    lib/
        router.js
    templates/
        base.html
        home.html
        forum.html
        topic.html
        comment.html
    js/
        base.js
        home.js
        forum.js
        topic.js
        comment.js
    css/
        base.css
        home.css
        forum.css
        topic.css
        comment.css

J'espère que certains plus spécifiques meilleures pratiques des structures et des conventions de nommage faire émerger.

Answer 4

Pour tous ceux qui Googler sur ce sujet:

L' em outil de ligne de commande (par EventedMind, le gars derrière le Fer Routeur) est très utile lorsque le gréement d'une nouvelle Application de Météore. Il va créer un fichier de nice/structure de dossier. Si vous avez déjà travailler sur une application et que vous voulez ré-organiser, il suffit de définir un nouveau projet avec em et vous pouvez l'utiliser pour trouver l'inspiration.

Voir: https://github.com/EventedMind/em

Et ici: Quelle est la meilleure façon d'organiser les modèles dans Meteor.js?

Answer 5

Je pense que le fichier de structure de la Découvrir Meteor Livre est vraiment bon et un début solide.

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections

• Code dans le répertoire du serveur ne s'exécute sur le serveur.
• Code dans le répertoire du client ne s'exécute sur le client.
• Tout le reste fonctionne à la fois le client et le serveur.
• Les fichiers dans le répertoire /lib sont chargés avant toute autre chose.
• Tout principal.* le fichier est chargé après tout le reste.
• Votre statique actifs (polices, images, etc.) aller dans le répertoire /public.