Quelles sont les meilleures pratiques pour structurer une grande application Meteor avec de nombreux fichiers HTML template? [fermé]

comme dans la faq non officielle de meteor, je pense qu'il explique assez bien comment structurer une grande application:

Où dois-je mettre mes fichiers?

les applications d'exemple dans meteor sont très simples, et ne fournissent pas beaucoup de perspicacité. Voici mes réflexions actuelles sur la meilleure façon de le faire: (toutes les suggestions/améliorations sont les bienvenues!)

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
client/stylesheets/        # <- css / styl / less files

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

public/                    # <- static files, such as images, that are served directly.

tests/                     # <- unit test files (won't be loaded on client or server)

pour les applications plus grandes, les fonctionnalités discrètes peuvent être brisées en sous-répertoires qui sont eux-mêmes organisés en utilisant le même modèle. L'idée ici est qu'éventuellement le module de fonctionnalité pourrait être intégré dans un paquet smart séparé, et idéalement, partagé autour.

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: FAQ non officiel sur les météores

je suis d'accord avec yagooar, mais au lieu de:

client/application.js

utiliser:

client/main.js

principal.* les fichiers sont chargés en dernier. Cela permettra de s'assurer que vous n'avez pas d'ordre de chargement des problèmes. Voir la documentation du météore, http://docs.meteor.com/#structuringyourapp , pour plus de détails.

Meteor a été conçu de sorte que vous structurer votre application à peu près tout ce que vous voulez. Donc, si vous n'aimez pas votre structure, vous pouvez simplement déplacer un fichier vers un nouveau répertoire, ou même le diviser en plusieurs morceaux, et à Meteor its à peu près tout de même. Il suffit de noter le traitement spécial des répertoires client, serveur et public tel que spécifié dans la page principale de la documentation: http://docs.meteor.com / .

en unissant tout en un HTML fill ne sera certainement pas une pratique exemplaire.

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, commentaire), putting .CSS. ,html, et .fichier js pour chaque page tapez ensemble dans un répertoire. J'ai aussi un module "base", qui contient common .css et .le code js et le modèle maître, qui utilise {{renderPage}} pour rendre l'un des autres modules en fonction du 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 pourriez aussi organiser par 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 des structures de meilleures pratiques et des conventions de nommage plus spécifiques émergeront cependant.

pour tous ceux qui Googlent sur ce sujet:

l'outil en ligne de commande em (par EventedMind, les gars derrière le routeur en fer) est très utile pour truquer une nouvelle application Meteor. Il va créer une structure de fichier/dossier agréable. Si vous travaillez déjà sur une application et que vous voulez la réorganiser, il suffit de mettre en place un nouveau projet avec em et vous pouvez l'utiliser comme source d'inspiration.

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

et ici: https://stackoverflow.com/questions/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

je pense que la structure du fichier du livre Discover Meteor est vraiment bonne et un bon début.

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

• le code dans le répertoire /server ne s'exécute que sur le serveur.
Le Code
• dans le répertoire /client ne s'exécute que sur le client.
• tout le reste tourne à la fois sur le client et le serveur.
Les fichiers
• dans /lib sont chargés avant toute autre chose.
• principal.* le fichier est chargé après tout le reste.
• vos actifs statiques (polices, images, etc.) aller dans le répertoire /public.

créer des paquets

bien sûr, tout ne correspond pas à cette approche, mais dans les grandes applications, vous aurez beaucoup de fonctionnalités qui peuvent être isolées. Tout ce qui est séparable et réutilisable entre dans les paquets, le reste va dans la structure de répertoire habituelle, comme mentionné dans d'autres réponses. Même si vous ne faites pas de paquets pour éviter les frais généraux, structurer le code de manière modulaire est une bonne idée (voir ces suggestions )

Meteor permet un contrôle précis de la façon dont vous chargez vos fichiers (ordre de chargement, où: client/Serveur/les deux) et de ce que le paquet exporte.

je trouve particulièrement très pratique la manière facile de partager la logique entre les fichiers associés. Par exemple, vous voulez créer une fonction util et l'utiliser dans différents fichiers. Vous faites juste "global" (sans le var ) et Meteor l'enveloppera dans l'Espace-nom du paquet, donc il ne polluera pas l'espace-Nom global

Ici l'officiel doc

après un certain temps à l'extérieur de meteorjs codage, je suis heureux d'avoir un peu de temps libre à consacrer à la construction d'un jeu en ligne assez complexe. App structure a été l'une de mes premières préoccupations, et il semble que plusieurs très bons programmeurs ont défendu la méthode package-only de structurer une application, ce qui vous permet de vaguement coupler des paquets fonctionnellement distincts. Il y a d'autres avantages à l'approche, et 2 très bons articles expliquant l'approche peuvent être trouvés ici:

http://www.matb33.me/2013/09/05/meteor-project-structure.html http://www.manuel-schoebel.com/blog/meteorjs-package-only-app-structure-with-mediator-pattern

nous avons un grand projet (probablement l'un des plus grand projet de météore n'importe qui a construit à ce jour car il était dans le développement à temps plein pendant 1,5 ans). Nous utilisons le même ensemble de noms de fichiers dans chaque vue. Il est très cohérent et nous aide à naviguer rapidement pour obtenir exactement ce que nous recherchons:

• des événements.js
• helpers.js
• modèles.html
• itinéraires.js
• les styles.peu
• etc.

ressemble à ceci dans un projet:

       ├── consolidationRequests
       │   ├── events.js
       │   ├── helpers.js
       │   ├── routers.js
       │   └── templates.html
       ├── customerSpoof
       │   └── routers.js
       ├── dashboard
       │   ├── events.js
       │   ├── helpers.js
       │   ├── onDestroyed.js
       │   ├── onRendered.js
       │   ├── routers.js
       │   └── templates.html
       ├── emailVerification
       │   ├── events.js
       │   ├── helpers.js
       │   ├── routers.js
       │   └── templates.html
       ├── loading
       │   ├── styles.css
       │   └── templates.html
       ├── mailbox
       │   ├── autoform.js
       │   ├── consolidationRequestConfirmation
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onCreated.js
       │   │   ├── onRendered.js
       │   │   └── templates.html
       │   ├── events.js
       │   ├── helpers.js

modèles connexes sont simplement stockés ensemble dans le même fichier. Contenu de view/order/checkout/templates.html collapsé ici:

<template name="orderCheckout"></template>

<template name="paymentPanel"></template>

<template name="orderCheckoutSummary"></template>

<template name="paypalReturnOrderCheckout"></template>

nous utilisons des sous-dossiers lorsque les vues deviennent complexes avec beaucoup de pièces:

       ├── cart
       │   ├── addItem
       │   │   ├── autoform.js
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onRendered.js
       │   │   ├── routers.js
       │   │   ├── styles.less
       │   │   └── templates.html
       │   ├── checkout
       │   │   ├── autoform.js
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onRendered.js
       │   │   ├── routers.js
       │   │   └── templates.html
       │   └── view
       │       ├── autoform.js
       │       ├── deleteItem
       │       │   ├── events.js
       │       │   ├── helpers.js
       │       │   └── templates.html
       │       ├── editItem
       │       │   ├── autoform.js
       │       │   ├── events.js
       │       │   ├── helpers.js
       │       │   └── templates.html
       │       ├── events.js
       │       ├── helpers.js
       │       ├── onDestroyed.js
       │       ├── onRendered.js
       │       ├── routers.js
       │       ├── styles.less
       │       └── templates.html

nous développons aussi avec WebStorm, un éditeur extrêmement puissant et flexible pour le développement de météore. Nous trouvez-le immensément utile lors de la recherche et de l'organisation de notre code et de travailler de façon productive.

heureux de partager les détails sur demande.

utiliser un échafaudage CLI. Rendre les choses très faciles.

https://github.com/iron-meteor/iron-cli

une fois installé. utiliser iron create my-app pour créer un nouveau projet. Il va créer la structure suivante pour vous. Vous pouvez également l'utiliser sur des projets existants. utilisez iron migrate dans le répertoire des projets.

my-app/    
 .iron/    
   config.json    
 bin/    
 build/    
 config/    
   development/    
     env.sh    
     settings.json    
 app/    
   client/    
     collections/    
     lib/    
     stylesheets/    
     templates/    
     head.html    
   lib/    
     collections/    
     controllers/    
     methods.js    
     routes.js    
   packages/    
   private/    
   public/    
   server/    
     collections/    
     controllers/    
     lib/    
     methods.js    
     publish.js    
     bootstrap.js

je suis le format mattdeom boilerplate, qui comprend déjà le routeur en fer et le modèle (Collection2) . Voir ci-dessous:

client/                 # Client folder
    compatibility/      # Libraries which create a global variable
    config/             # Configuration files (on the client)
    lib/                # Library files that get executed first
    startup/            # Javascript files on Meteor.startup()
    stylesheets         # LESS files
    modules/            # Meant for components, such as form and more(*)
    views/              # Contains all views(*)
        common/         # General purpose html templates
model/                  # Model files, for each Meteor.Collection(*)
private/                # Private files
public/                 # Public files
routes/                 # All routes(*)
server/                 # Server folder
    fixtures/           # Meteor.Collection fixtures defined
    lib/                # Server side library folder
    publications/       # Collection publications(*)
    startup/            # On server startup
meteor-boilerplate      # Command line tool

il existe de nombreuses approches différentes pour structurer votre application. Par exemple, si vous avez un routeur et des gabarits de page différents, et si vous êtes à l'intérieur de chaque gabarit de page, vous avez de nombreuses parties de page, et ainsi de suite, je la structurerai en fonction de la sémantique du niveau supérieur > inférieur..

Par Exemple:

client
  views
    common
      header
        header.html
        header.js
        header.css
      footer
        footer.html
        footer.js
        footer.css
    pages
      mainPage
        mainPage.html
        mainPage.js
        mainPage.css
        articles
          articles.html
          articles.js
          articles.css
        news
          news.html
          news.js
          news.css
     ...

bien sûr, vous pouvez mettre vos gabarits de nouvelles dans le dossier commun, comme vous pouvez utiliser votre gabarit de nouvelles sur des pages différentes.

je pense que c'est la meilleure façon de structurer votre application d'une manière qui vous convient.

j'ai écrit une petite application ici: http://gold.meteor.com Et c'est tellement petit que je n'utilise qu'un seul fichier html et un seul modèle.fichier js.. :)

j'espère que ça aide un peu

il y a une nouvelle classe sur Evented Mind appelé mise en place de projets Meteor qui traite de cela, mais aussi parle de la configuration du projet et de la mise en place de votre environnement de développement.

De la Structure de l'Application de la vidéo dans la classe: Meteor n'ont pas une très forte opinion sur la façon dont votre application doit être structuré, mais voici quelques règles de base:

1) Charge ordre-Meteor va à l'emplacement le plus profond dans le répertoire de fichiers d'abord et traite les fichiers dans l'ordre alphabétique

2) client et serveur sont des dossiers spéciaux que Meteor reconnaît

notre structure ressemble à ceci:

both/
    collections/
        todos.js
    controllers/
        todos_controller.js
    views/
        todos.css
        todos.html
        todos.js
    app.js - includes routes
client/
    collections/
    views/
        app.js
server/
    collections/
    views/
        app.js
packages/
public/

le todos_controller étend RouteController, quelque chose qui vient avec Iron Router.

l'outil em mentionné ci-dessus est également obtenir une grande mise à jour droit maintenant et devrait être beaucoup mieux et disponible à: https://github.com/EventedMind/em

je suis également à la recherche de meilleures pratiques pour améliorer et adapter mes applications grâce à une architecture bien conçue. Les pratiques de travail pour les petites et moyennes applications, mais échoue lorsque vous travaillez dans une plus grande équipe. Il y a plusieurs façons que j'ai essayées:

1) j'ai suivi cette stratégie: https://github.com/aldeed/meteor-autoform pour dimensionner et réutiliser les gabarits. L'auteur a une très bonne idée de la conception des composants et du terrain. Je suis actuellement la mise en œuvre parce que la communauté a développé 36 paquets qui couvrent presque tous les cas et je peux utiliser TypeScript pour être dactylographié sûr pendant la phase de développement.

<template name="autoForm">
  {{#unless afDestroyUpdateForm this.id}}
  {{! afDestroyUpdateForm is a workaround for sticky input attributes}}
  {{! See https://github.com/meteor/meteor/issues/2431 }}
  <form {{atts}}>
    {{> Template.contentBlock ..}}
  </form>
  {{/unless}}
</template>

voici un bon billet de blog sur la façon de le faire: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability / ainsi qu'ici: http://meteorpedia.com/read/Blaze_Notes

2) celui-ci semble si prometteur mais n'a pas été mis à jour récemment. C'est un paquet écrit dans le script café appelé. Blaze Components ( ) https://github.com/peerlibrary/meteor-blaze-components ) pour Meteor sont un système pour développer facilement des éléments D'interface utilisateur complexes qui doivent être réutilisés autour de votre application Meteor. Vous pouvez les utiliser dans CoffeeScript, JavaScript vanille et ES6. Le mieux, c'est que les composants sont hors D'usage. En voici un exemple:

class ExampleComponent extends BlazeComponent {
  onCreated() {
    this.counter = new ReactiveVar(0);
  }

  events() {
    return [{
      'click .increment': this.onClick
    }];
  }

  onClick(event) {
    this.counter.set(this.counter.get() + 1);
  }

  customHelper() {
    if (this.counter.get() > 10) {
      return "Too many times";
    }
    else if (this.counter.get() === 10) {
      return "Just enough";
    }
    else {
      return "Click more";
    }
  }
}

ExampleComponent.register('ExampleComponent');

{{> ExampleComponent }}

3) j'aime les types et les transporteurs qui me disent Où Et quand quelque chose va mal. J'utilise le script pour travailler avec Meteor et j'ai trouvé le dépôt suivant: https://github.com/dataflows/meteor-typescript-utils il semble que le créateur a essayé d'accomplir une approche MVC.

class MainTemplateContext extends MainTemplateData {
    @MeteorTemplate.event("click #heybutton")
    buttonClick(event: Meteor.Event, template: Blaze.Template): void {
        // ...
    }

    @MeteorTemplate.helper
    clicksCount(): number {
        // ...
    }
}

class MainTemplate extends MeteorTemplate.Base<MainTemplateData> {
    constructor() {
        super("MainTemplate", new MainTemplateContext());
    }

    rendered(): void {
        // ...
    }
}

MeteorTemplate.register(new MainTemplate());

<template name="MainTemplate">
    <p>
        <input type="text" placeholder="Say your name..." id="name">
        <input type="button" value="Hey!" id="heybutton">
    </p>
    <p>
        Clicks count: {{ clicksCount }}
    </p>

    <p>
        <ul>
            {{#each clicks }}
                <li> {{ name }} at <a href="{{pathFor 'SingleClick' clickId=_id}}">{{ time }}</a></li>
            {{/each}}
        </ul>
    </p>
</template>

Malheureusement, ce projet n'est pas maintenu ou développé activement.

4) et je pense que cela a déjà été mentionné, vous pouvez passer à l'échelle en utilisant des paquets. Cela exige une bonne façon de penser abstraite. Il semble fonctionner pour Télescope: https://github.com/TelescopeJS/Telescope

5) meteor-template-extension - fournit diverses façons de copier les assistants de gabarit, les gestionnaires d'événements et les crochets entre les gabarits, permettant la réutilisation de code; un inconvénient est que toute copie doit être prise en charge par un développeur, souvent encore et encore, ce qui devient problématique comme codebase se développe; en outre, sans une communauté API clairement définie ne peut pas construire et partager des composants

6) Composants de Flux – Composants de Flux sont plus proches de Réagir dans la conception d'API, alors que Blaze Composants sont en gardant familier des concepts tels que les données de contextes et de modèle aides; Composants de Flux sur l'autre main toujours utiliser un modèle basé sur les gestionnaires d'événements, tandis que Blaze Composants de rendre les méthodes de la classe de sorte qu'il est plus facile d'étendre ou de en général, Blaze Components semble être plus orienté OOP; Flow Components are not yet officially released ( crédits texte pour #5 et #6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

numéros 2 et 3 ont besoin d'être utilisés aussi, mais vous gagnerez en vitesse de développement avec le temps. Numéro quatre vous permet de construire et tester des composants pour rendre votre code plus stable. Le numéro trois est livré avec l'avantage de la sécurité de typographie complète, ce qui est un énorme plus lorsque vous développez dans une équipe avec une mauvaise documentation. Cependant, je suis actuellement en train de porter le numéro deux à dactylographier parce que je me sens très à l'aise pour travailler avec et je n'ai pas à modifier le paquet compilateur pour le faire fonctionner avec Meteor quand je n'utilise pas Gulp.

Il est toujours difficile de trouver la bonne façon de travailler avec Meteor. Tu dois le découvrir par toi-même, sinon on finit avec une structure de dossiers bien arrangée, mais on ne sait pas où tout se trouve. Heureux de codage.