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

165

Dans tous les exemples (classement, jeu de mots, etc.), ils ont un seul fichier de modèle HTML. Existe-t-il un grand projet Meteor open source avec de nombreux fichiers de modèles HTML différents que nous pouvons utiliser comme exemple de bonne pratique? Cela ne semble pas pratique de mettre tout ce dont une grande application a besoin dans un seul fichier de modèle.

meteor Andrew Arrow
la source
météore est nouveau, je n'ai rien trouvé de meilleure pratique à ce sujet. J'attends aussi une guilde à ce sujet
newlife
10
Avez-vous lu la partie sur la structuration de votre application dans le manuel? Il y a quelques explications sur l'analyse et la concaténation des fichiers HTML.
zwippie
1
Le guide officiel de Meteor suggère une structure de fichiers très cool. Vérifiez ici: guide.meteor.com/structure.html#javascript-structure
Waqas

Réponses:

16

Mettez tout cela ensemble! À partir de la documentation:

> HTML files in a Meteor application are treated quite a bit differently
> from a server-side framework. Meteor scans all the HTML files in your
> directory for three top-level elements: <head>, <body>, and
> <template>. The head and body sections are seperately concatenated
> into a single head and body, which are transmitted to the client on
> initial page load.
> 
> Template sections, on the other hand, are converted into JavaScript
> functions, available under the Template namespace. It's a really
> convenient way to ship HTML templates to the client. See the templates
> section for more.
mdgrech
la source
29
C'est cependant la préoccupation de l'affiche. Le regroupement est correct, mais vous pouvez voir ce qui se passe avec Asana - il nécessite un écran de chargement pendant qu'il télécharge> 1 Mo de code client. Ce n'est pas acceptable pour de nombreux sites. Nous allons voir si nous ne pouvons peut-être pas faire une partie du chargement au coup par coup après le chargement de l'écran principal, mais je suis sceptique pour le moment. Je pense qu'il va falloir que ce soit une fonctionnalité pour briser un peu les choses.
Dave Sanders
36
Cette réponse est le résultat n ° 1 dans Google, mais elle est vraisemblablement obsolète. D'autres futurs visiteurs comme moi; Regardez ci-dessous!
Kloar
À partir de la version 1.1.0.2, la simple application todo dont ils font la démonstration transfère 1,7 Mo de fichiers lorsque vous rechargez dur avec le cache du navigateur supprimé. Ceci est inacceptable pour de nombreux cas d'utilisation. : / Les choses sont beaucoup améliorées une fois que les actifs sont mis en cache, mais au premier chargement, c'est assez brutal.
Jason Kim
Idée: utiliser webpack, créer des bundles pour les choses, les charger paresseusement en cas de besoin.
trusktr
oui Asana prend un certain temps à se charger. Asana est également une application incroyablement bien conçue et réactive dans laquelle les utilisateurs ont créé 175 millions de tâches en 2014. Les applications qui se chargent plus rapidement ne sont pas toujours meilleures. Le démarrage des applications sur votre téléphone prend également un moment. Les gens s'y habitueront.
Max Hodges
274

Comme dans la FAQ non officielle sur les météores, je pense que cela explique assez bien comment structurer une grande application:

Où dois-je placer mes fichiers?

Les exemples d'applications dans meteor sont très simples et ne fournissent pas beaucoup d'informations. Voici ma réflexion actuelle sur la meilleure façon de le faire: (toutes 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 importantes, les fonctionnalités discrètes peuvent être divisées en sous-répertoires qui sont eux-mêmes organisés selon le même modèle. L'idée ici est que finalement le module de fonctionnalité pourrait être pris en compte dans un package intelligent séparé et, idéalement, partagé.

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 officielle sur Meteor

yagooar
la source
12
IMHO c'est mieux que la réponse acceptée. Je vais l'essayer maintenant.
hakan
17
Depuis la version 0.6.0, il est préférable d'éviter ce désordre et d'exécuter votre application entièrement à partir de packages intelligents. Je vais un peu plus en détail dans ce billet de blog: matb33.me/2013/09/05/meteor-project-structure.html
matb33
1
quelqu'un a une idée où mettre le mobile-config.js?
Mec du
1
Merci pour la réponse et le lien vers la faq non officielle (je suis nouveau dans le monde des météores), que veulent-ils dire par "code commun de quelqu'un d'autre"? Merci!
Cohars
3
Quant à meteor 1.3, je dirais qu'il est obsolète en raison de l'importation du module ES6. Voir l'article du guide météore sur la structure de l'application: guide.meteor.com/structure.html
Samuel
36

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

client / application.js

Utilisation:

client / main.js

Les fichiers main. * sont chargés en dernier. Cela vous aidera à vous assurer que vous n'avez aucun problème d'ordre de chargement. Voir la documentation Meteor, http://docs.meteor.com/#structuringyourapp , pour plus de détails.

pwcremin
la source
26

Meteor a été conçu pour que vous puissiez structurer votre application à peu près comme vous le souhaitez. Donc, si vous n'aimez pas votre structure, vous pouvez simplement déplacer un fichier vers un nouveau répertoire, ou même diviser un fichier en plusieurs morceaux, et dans Meteor, c'est à peu près tout de même. Notez simplement 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/ .

Le simple fait de tout regrouper dans un seul remplissage HTML ne sera certainement pas une bonne pratique.

Voici un exemple d'une structure possible: dans l'une de mes applications, un forum de discussion, j'organise par module ou "type de page" (accueil, forum, sujet, commentaire), en mettant les fichiers .css, .html et .js pour chacun type de page ensemble dans un répertoire. J'ai aussi un module "base", qui contient le code commun .css et .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 pouvez également 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 cependant que des structures de meilleures pratiques et des conventions de dénomination plus spécifiques émergeront.

Jonathan Warden
la source
2
C'est ma réponse préférée. L'une de mes choses préférées à propos de Meteor est que vous pouvez structurer vos fichiers d'une manière qui fonctionne pour vous.
CaptSaltyJack
J'aime cette réponse. Je l'ai fait de la première façon.
Chanté le
les choses liées doivent être proches les unes des autres. Ma réponse est comme la vôtre mais à l'envers.
Max Hodges
1.3 lib zappé
Jeremy Iglehart
Je ne vois pas la valeur de nommer plusieurs fichiers avec un nom de fonction comme «sujet». Maintenant, si vous voulez changer le nom de la fonction en "catégorie", vous devez changer plusieurs noms de fichiers. Organisez-les simplement sous un seul dossier appelé «sujet» et nommez-les de manière générique: events.js, views.html, styles, css, routes.js, etc. voir ma réponse pour plus.
Max Hodges
14

Pour tous ceux qui recherchent sur Google ce sujet:

L' emoutil de ligne de commande (par EventedMind, les gars derrière Iron Router) est très utile lors du montage d'une nouvelle application Meteor. Cela créera une belle structure de fichiers / dossiers. Si vous travaillez déjà sur une application et que vous souhaitez la réorganiser, configurez simplement un nouveau projet avec emet vous pouvez l'utiliser comme source d'inspiration.

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

Et ici: /programming/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Mikael Lirbank
la source
4
Remarque: ceci a été remplacé par iron-cli (même auteur). Voir: github.com/iron-meteor/iron-cli
j0e
Oui, 'em' a été renommé iron-cli, même outil.
Mikael Lirbank
11

Je pense que la structure des fichiers du Discover Meteor Book est vraiment bonne et constitue un bon début. 

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • Le code du répertoire / server ne s'exécute que sur le serveur.
  • Le code du répertoire / client ne s'exécute que sur le client.
  • Tout le reste fonctionne à la fois sur le client et sur le serveur.
  • Les fichiers dans / lib sont chargés avant toute autre chose.
  • Tout fichier principal. * Est chargé après tout le reste.
  • Vos actifs statiques (polices, images, etc.) vont dans le répertoire / public.
Almog Koren
la source
10

Créer des packages

Bien sûr, tout ne rentre pas dans cette approche, mais dans les grandes applications, vous aurez de nombreuses fonctionnalités qui peuvent être isolées. Tout ce qui est séparable et réutilisable tient dans des packages, le reste va dans la structure de répertoires habituelle, comme mentionné dans d'autres réponses. Même si vous ne créez pas de packages pour éviter la surcharge, structurer le code de manière modulaire est une bonne idée (voir ces suggestions )

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

Je trouve surtout très pratique le moyen facile de partager la logique entre les fichiers associés. Disons, par exemple, que vous voulez créer une fonction util et l'utiliser dans différents fichiers. Vous le rendez simplement "global" (sans le var) et Meteor l'enveloppera dans l'espace de noms du paquet, donc il ne polluera pas l'espace de noms global

Voici la doc officielle

Bogdan D
la source
6

Après un certain temps en dehors du codage meteorjs, je suis heureux d'avoir un peu de temps libre à consacrer à la création d'un jeu en ligne assez complexe. La structure de l'application a été l'une de mes premières préoccupations, et il semble que plusieurs très bons programmeurs aient défendu la méthode de structuration d'une application uniquement basée sur les packages, qui vous permet de coupler de manière lâche des packages 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 -modèle

lukenofautres
la source
6

Nous avons un grand projet (probablement l'un des plus grands projets Meteor que quiconque ait construit à ce jour, car il était en développement à plein temps depuis 1,5 an). Nous utilisons le même ensemble de noms de fichiers dans chaque vue. C'est très cohérent et nous aide à naviguer rapidement vers exactement ce que nous recherchons:

  • events.js
  • helpers.js
  • templates.html
  • routes.js
  • styles sans
  • etc.

Ressemble à ceci dans un projet:

       ├── consolidationDemandes
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routers.js
       │ └── templates.html
       ├── customerSpoof
       │ └── routers.js
       ├── tableau de bord
       │ ├── events.js
       │ ├── helpers.js
       │ ├── onDestroyed.js
       │ ├── onRendered.js
       │ ├── routers.js
       │ └── templates.html
       ├── emailVerification
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routers.js
       │ └── templates.html
       ├── chargement
       │ ├── styles.css
       │ └── templates.html
       ├── boîte aux lettres
       │ ├── autoform.js
       │ ├── consolidationRequestConfirmation
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onCreated.js
       │ │ ├── onRendered.js
       │ │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js

Les modèles associés sont simplement stockés ensemble dans le même fichier. Contenu de view/order/checkout/templates.htmlmontré réduit 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 de nombreuses parties:

       ├── chariot
       │ ├── addItem
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ ├── styles.less
       │ │ └── templates.html
       │ ├── caisse
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ └── templates.html
       │ └── vue
       │ ├── 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 également avec WebStorm, un éditeur extrêmement puissant et flexible pour le développement de Meteor. Nous trouvons cela extrêmement utile pour rechercher et organiser notre code et travailler de manière productive. Vue Webstorm

Heureux de partager des détails sur demande.

Max Hodges
la source
3
Veuillez envisager d'ajouter un commentaire si vous pensez que cette réponse peut être améliorée.
Max Hodges
Très bonne publication. Question: Après tout ce temps avec meteor, vous le recommandez toujours pour les grands projets, comme un e-commerce? Ou pensez à utiliser un framework qui peut vous donner plus d '"autonomie" que LoopBack ou même Happi.
Liko
nous adorons Meteor et nous y développons tous les nouveaux. Malheureusement, je ne connais pas assez LoopBack ou Happi pour avoir une opinion.
Max Hodges
1
Les LoopBacks se concentrent sur les API de repos de bout en bout, ce qui en fait un cadre de développement Web traditionnel (comme RoR). RoR a bien obtenu l'API REST, mais nous pensons que Meteor a bien fonctionné en temps réel.
Max Hodges
Merci pour les commentaires. Vous avez également organisé le côté serveur pour les fonctionnalités?
Liko
5

Utilisez la CLI d'échafaudage iron-cli. Rend les choses très faciles.

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

une fois installé. utilisez iron create my-apppour créer un nouveau projet. Cela créera la structure suivante pour vous. Vous pouvez également l'utiliser sur des projets existants. utiliser iron migratedans le répertoire du projet.

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
ravish.hacker
la source
Bien que ce lien puisse répondre à la question, il est préférable d'inclure les parties essentielles de la réponse ici et de fournir le lien pour référence. Les réponses aux liens uniquement peuvent devenir invalides si la page liée change.
user2314737
@ user2314737 Criez pour dire que le répondant a modifié son message. Il comprend désormais les données essentielles nécessaires au problème en question.
Kyll
4

Je suis le format passe-partout mattdeom, qui comprend déjà le routeur et le modèle de fer (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
Rudy
la source
3

Il existe de nombreuses approches différentes pour structurer votre application. Par exemple, si vous avez un routeur et différents modèles de page, et que chaque modèle de page contient de nombreuses parties de page et ainsi de suite, je le structurerais 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 placer vos modèles de nouvelles dans le dossier commun, comme vous pouvez utiliser votre modèle de nouvelles sur différentes pages.

Je pense que c'est la meilleure structure avec laquelle vous êtes à l'aise.

J'ai écrit une petite application ici: http://gold.meteor.com Et c'est si petit, je n'utilise qu'un seul fichier html et un seul fichier template.js .. :)

J'espère que ça aide un peu

Boris Kotov
la source
Je ne vois pas la valeur de nommer plusieurs fichiers avec un nom de fonction comme "articles". Maintenant, si vous voulez changer le nom de la fonctionnalité en "posts", vous devez changer les noms de fichiers. Organisez-les simplement sous un seul dossier appelé "articles" et nommez-les "events.js", views.html, styles, css, etc. voir ma réponse pour plus.
Max Hodges
3

Il existe une nouvelle classe sur Evented Mind appelée Configurer des projets Meteor qui aborde ce problème, mais parle également de la configuration de projet et de la configuration de votre environnement de développement.

Extrait de la vidéo sur la structure de l' application dans la classe: Meteor n'a pas une opinion très claire sur la façon dont votre application doit être structurée, mais voici quelques règles:

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

2) le client et le 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' emoutil mentionné ci-dessus fait également l'objet d'une mise à jour importante en ce moment et devrait être bien meilleur et disponible sur: https://github.com/EventedMind/em

katogeaver
la source
quelles sont les vues à l'intérieur / serveur / vues /?
stefcud
je ne vois pas la valeur de nommer plusieurs fichiers avec un nom de fonction comme "todos". Maintenant, si vous voulez changer le nom de la fonction en "tâches", vous devez changer 5 noms de fichiers. Organisez-les simplement sous un seul dossier appelé "todos" et nommez-les "events.js", views.html, styles, css, etc. voir ma réponse pour plus.
Max Hodges
1

Je recherche également les meilleures pratiques pour améliorer et faire évoluer mes applications grâce à une architecture bien conçue. Toutes les pratiques mentionnées ci-dessus fonctionnent pour les applications de petite à moyenne taille, mais échoueront lorsque vous travaillez dans une plus grande équipe. J'ai essayé plusieurs façons:

1) J'ai suivi cette stratégie: https://github.com/aldeed/meteor-autoform pour redimensionner et réutiliser les modèles. L'auteur a une très bonne idée de la conception des composants et du terrain. Je l'implémente actuellement car la communauté a développé 36 packages qui couvrent presque tous les cas et je peux utiliser TypeScript pour être sûr de type 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 article de blog sur la façon de le faire: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ ainsi que ici: http: // meteorpedia .com / read / Blaze_Notes

2) Celui-ci a l'air si prometteur mais n'a pas été mis à jour récemment. Il s'agit d'un package écrit en script coffee appelé. Blaze Components ( https://github.com/peerlibrary/meteor-blaze-components ) pour Meteor est un système permettant de 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 vanilla et ES6. La meilleure chose est que les composants sont OOP. Voici un de leurs exemples:

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 transpilateurs qui me disent où et quand quelque chose va mal. J'utilise TypeScript pour travailler avec Meteor et j'ai trouvé le référentiel suivant: https://github.com/dataflows/meteor-typescript-utils, il semble que le créateur ait 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 mettre à l'échelle à l'aide de packages. Cela nécessite une bonne façon de penser abstraite. Cela semble fonctionner pour Telescope: https://github.com/TelescopeJS/Telescope

5) meteor-template-extension - fournit diverses façons de copier les aides de modèle, les gestionnaires d'événements et les crochets entre les modèles, permettant la réutilisation du 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 à mesure que la base de code se développe; de plus, sans une communauté d'API clairement définie, il est impossible de créer et de partager des composants

6) Composants de flux - Les composants de flux sont plus proches de React dans la conception de l'API tandis que les composants Blaze conservent des concepts familiers tels que les contextes de données et les aides de modèle; Les composants de flux, quant à eux, utilisent toujours des gestionnaires d'événements basés sur des modèles tandis que les composants Blaze en font des méthodes de classe afin qu'il soit plus facile de les étendre ou de les remplacer par héritage; en général, Blaze Components semble être plus orienté POO; Les composants de flux ne sont pas encore officiellement publiés ( crédits textuels pour # 5 et # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

Les numéros 2 et 3 doivent également être utilisés, mais vous gagnerez en vitesse de développement avec le temps. Le numéro quatre vous permet de créer et de tester des composants pour rendre votre code plus stable. Le numéro trois présente l'avantage de la sécurité de type complet de Typescript, ce qui est un énorme avantage lorsque vous développez dans une équipe avec une documentation médiocre. Cependant, je porte actuellement le numéro deux sur TypeScript car je me sens très à l'aise pour travailler avec et je n'ai pas à modifier le package du compilateur pour le faire fonctionner avec Meteor lorsque je n'utilise pas Gulp.

Il est encore difficile de trouver la bonne façon de travailler avec Meteor. Vous devez le découvrir par vous-même, sinon vous vous retrouvez avec une structure de dossiers bien organisée, mais vous ne savez pas où tout se trouve. Bon codage.

MichelH
la source