¿Cuáles son las mejores prácticas para estructurar una aplicación Meteor grande con muchos archivos de plantilla HTML? [cerrado]

165

En todos los ejemplos (tabla de clasificación, juegos de palabras, etc.) tienen un único archivo de plantilla HTML. ¿Existe algún gran proyecto de Meteor de código abierto con muchos archivos de plantillas HTML diferentes que podamos usar como ejemplo de mejores prácticas? No parece práctico poner todo lo que una aplicación grande necesita en un solo archivo de plantilla.

meteor Andrew Arrow
fuente
meteorito es algo nuevo, no he encontrado nada relacionado con las mejores prácticas sobre esto. También espero algo de guild sobre esto
newlife
10
¿Ha leído la parte sobre Estructuración de su aplicación en el manual? Hay alguna explicación sobre el escaneo y la concatenación de archivos HTML.
zwippie
1
La guía oficial de Meteor sugiere una estructura de archivos muy interesante. Consulta aquí: guide.meteor.com/structure.html#javascript-structure
Waqas

Respuestas:

16

¡Agrúpelo todo junto! De los documentos:

> 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
fuente
29
Sin embargo, esta es la preocupación del afiche. El agrupamiento está bien, pero puede ver lo que sucede con Asana: requiere una pantalla de carga mientras descarga> 1 MB de código de cliente. Eso no es aceptable para muchos sitios. Vamos a ver si tal vez no podamos hacer parte de la carga gradual después de la carga de la pantalla principal, pero estoy escéptico en este momento. Creo que tendrá que ser una característica para romper un poco las cosas.
Dave Sanders
36
Esta respuesta es el resultado número 1 en Google, pero está desactualizado. Otros, futuros visitantes como yo; ¡mira abajo!
Kloar
A partir de 1.1.0.2, la aplicación de tareas simple que muestran transfiere 1.7 MB de archivos cuando se recarga de nuevo con el caché del navegador eliminado. Esto es inaceptable para muchos casos de uso. : / Las cosas mejoran mucho una vez que los activos se almacenan en caché, pero en la primera carga, es bastante brutal.
Jason Kim
Idea: use el paquete web, haga paquetes para cosas, cárguelos cuando sea necesario.
trusktr
Sí, Asana tarda un poco en cargar. Asana también es una aplicación reactiva increíblemente bien hecha en la que los usuarios crearon 175 millones de tareas en 2014. Las aplicaciones que se cargan más rápido no siempre son mejores. Las aplicaciones también tardan un momento en iniciarse en su teléfono. La gente se acostumbrará.
Max Hodges
274

Al igual que en las preguntas frecuentes sobre meteoritos no oficiales, creo que explica bastante bien cómo estructurar una aplicación grande:

¿Dónde debo poner mis archivos?

Las aplicaciones de ejemplo en meteorito son muy simples y no proporcionan mucha información. Aquí está mi pensamiento actual sobre la mejor manera de hacerlo: (¡cualquier sugerencia / mejora es bienvenida!)

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)

Para aplicaciones más grandes, la funcionalidad discreta se puede dividir en subdirectorios que se organizan utilizando el mismo patrón. La idea aquí es que eventualmente el módulo de funcionalidad se podría factorizar en un paquete inteligente separado, e idealmente, compartirlo.

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

Obtenga más información: Preguntas frecuentes sobre meteoritos no oficiales

yagooar
fuente
12
En mi humilde opinión esto es mejor que la respuesta aceptada. Voy a tratar ahora.
hakan
17
Desde 0.6.0, es mucho mejor evitar ese desastre y ejecutar su aplicación completamente sin paquetes inteligentes. Entro
matb33
1
Alguien tiene idea de dónde poner el mobile-config.js?
Amigo
1
Gracias por la respuesta y el enlace a la pregunta no oficial (soy nuevo en el mundo de los meteoritos), ¿qué quieren decir con "código común de otra persona"? ¡Gracias!
Cohars
3
En cuanto al meteorito 1.3, diría que esto está desactualizado debido a la importación del módulo ES6. Consulte el artículo de la guía de meteoritos sobre la estructura de la aplicación: guide.meteor.com/structure.html
Samuel
36

Estoy de acuerdo con yagooar, pero en lugar de:

cliente / application.js

Utilizar:

cliente / main.js

Los archivos main. * se cargan en último lugar. Esto ayudará a garantizar que no tenga problemas de orden de carga. Consulte la documentación de Meteor, http://docs.meteor.com/#structuringyourapp , para obtener más detalles.

pwcremin
fuente
26

Meteor se diseñó para que pueda estructurar su aplicación de la forma que desee. Entonces, si no le gusta su estructura, simplemente puede mover un archivo a un nuevo directorio, o incluso dividir un archivo en muchas partes, y para Meteor es más o menos lo mismo. Solo tenga en cuenta el tratamiento especial de los directorios de clientes, servidores y públicos como se especifica en la página principal de documentación: http://docs.meteor.com/ .

Simplemente agrupar todo en un relleno HTML ciertamente no surgirá como una mejor práctica.

Aquí hay un ejemplo de una posible estructura: en una de mis aplicaciones, un foro de discusión, organizo por módulo o "tipo de página" (inicio, foro, tema, comentario), colocando archivos .css, .html y .js para cada tipo de página juntos en un directorio. También tengo un módulo "base", que contiene código común .css y .js y la plantilla maestra, que utiliza {{renderPage}} para representar uno de los otros módulos dependiendo del enrutador.

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

También puedes organizar por función

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

Sin embargo, espero que surjan algunas estructuras de mejores prácticas más específicas y convenciones de nomenclatura.

Jonathan Warden
fuente
2
Esta es mi respuesta favorita. Una de mis cosas favoritas sobre Meteor es que puede estructurar sus archivos de una manera que funcione para usted.
CaptSaltyJack
Me gusta esta respuesta Lo he estado haciendo de la primera manera.
Sung Cho
Las cosas relacionadas deben estar muy cerca unas de otras. Mi respuesta es como la tuya pero al revés.
Max Hodges
1.3 liberó a favor de las importaciones guide.meteor.com/structure.html#example-app-structure
Jeremy Iglehart
No veo valor en nombrar varios archivos con un nombre de función como "tema". Ahora, si desea cambiar el nombre de la función a "categoría", debe cambiar varios nombres de archivo. Simplemente organícelos en una sola carpeta llamada "tema" y asígneles un nombre genérico: events.js, views.html, styles, css, routes.js, etc. vea mi respuesta para obtener más información.
Max Hodges
14

Para todos los que están buscando en Google sobre este tema:

La emherramienta de línea de comando (por EventedMind, los chicos detrás del Enrutador de Hierro) es muy útil cuando se manipula una nueva aplicación Meteor. Creará una buena estructura de archivos / carpetas. Si ya trabaja en una aplicación y desea reorganizarla, simplemente configure un nuevo proyecto emy podrá usarlo como inspiración.

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

Y aquí: /programming/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Mikael Lirbank
fuente
44
Nota: esto ha sido reemplazado por iron-cli (mismo autor). Ver: github.com/iron-meteor/iron-cli
j0e
Sí, 'em' ha sido renombrado iron-cli, misma herramienta.
Mikael Lirbank
11

Creo que la estructura de archivos del Discover Meteor Book es realmente buena y un comienzo sólido. 

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • El código en el directorio / server solo se ejecuta en el servidor.
  • El código en el directorio / client solo se ejecuta en el cliente.
  • Todo lo demás se ejecuta tanto en el cliente como en el servidor.
  • Los archivos en / lib se cargan antes que nada.
  • Cualquier archivo. * Principal se carga después de todo lo demás.
  • Sus activos estáticos (fuentes, imágenes, etc.) van en el directorio / public.
Almog Koren
fuente
10

Crea paquetes

Por supuesto, no todo encaja en este enfoque, pero en aplicaciones grandes tendrá muchas funcionalidades que pueden aislarse. Cualquier cosa separable y reutilizable cabe en los paquetes, el resto va en la estructura de directorio habitual, como se menciona en otras respuestas. Incluso si no crea paquetes para evitar la sobrecarga, es una buena idea estructurar el código de forma modular (consulte estas sugerencias )

Meteor permite un control detallado sobre cómo cargar sus archivos (orden de carga, dónde: cliente / servidor / ambos) y qué exporta el paquete.

Especialmente encuentro muy útil la manera fácil de compartir la lógica entre los archivos relacionados. Digamos, por ejemplo, que quieres hacer alguna función de utilidad y usarla en diferentes archivos. Simplemente lo hace "global" (sin el var) y Meteor lo envolverá en el espacio de nombres del paquete, por lo que no contaminará el espacio de nombres global

Aquí está el documento oficial.

Bogdan D
fuente
6

Después de un tiempo fuera de la codificación de meteorjs, estoy feliz de tener algo de tiempo libre para dedicarlo a construir un juego en línea bastante complejo. La estructura de la aplicación ha sido una de mis primeras preocupaciones, y parece que varios programadores muy buenos han defendido el método de estructuración de una aplicación de solo paquete, que le permite acoplar paquetes funcionalmente distintos. Hay otras ventajas del enfoque, y se pueden encontrar 2 artículos muy buenos que explican el enfoque aquí:

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

lukenofurther
fuente
6

Tenemos un gran proyecto (probablemente uno de los proyectos Meteor más grandes que alguien haya construido hasta la fecha, ya que estuvo en desarrollo a tiempo completo durante 1,5 años). Usamos el mismo conjunto de nombres de archivo en cada vista. Es muy consistente y nos ayuda a navegar rápidamente a exactamente lo que estamos buscando:

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

Se ve así en un proyecto:

       ├── solicitud de consolidación
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routers.js
       │ └── templates.html
       ├── customerSpoof
       │ └── routers.js
       ├── tablero de instrumentos
       │ ├── events.js
       │ ├── helpers.js
       │ ├── onDestroyed.js
       │ ├── onRendered.js
       │ ├── routers.js
       │ └── templates.html
       ├── emailVerification
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routers.js
       │ └── templates.html
       ├── cargando
       │ ├── styles.css
       │ └── templates.html
       ├── buzón
       │ ├── autoform.js
       │ ├── consolidationRequestConfirmation
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onCreated.js
       │ │ ├── onRendered.js
       │ │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js

Las plantillas relacionadas se almacenan juntas en el mismo archivo. El contenido de lo view/order/checkout/templates.htmlmostrado se contrajo aquí:

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

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

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

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

Usamos subcarpetas cuando las vistas se vuelven complejas con muchas partes:

       ├── carro
       │ ├── addItem
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ ├── styles.less
       │ │ └── templates.html
       │ ├── pago
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ └── templates.html
       │ └── ver
       │ ├── 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

También desarrollamos con WebStorm, un editor extremadamente potente y flexible para el desarrollo de Meteor. Lo encontramos inmensamente útil cuando buscamos y organizamos nuestro código y trabajamos productivamente. Vista de tormenta web

Feliz de compartir detalles a petición.

Max Hodges
fuente
3
Considere agregar un comentario si cree que esta respuesta puede mejorarse.
Max Hodges
Buena publicación. Pregunta: ¿Después de todo este tiempo con meteorito, todavía lo recomienda para proyectos grandes, como un comercio electrónico? O considere usar un marco que le brinde más "autonomía" como LoopBack o incluso Happi.
Liko
amamos a Meteor y desarrollamos todo lo nuevo en él. Desafortunadamente, no estoy lo suficientemente familiarizado con LoopBack o Happi para tener una opinión.
Max Hodges
1
Los LoopBacks se centran en API de descanso de extremo a extremo para que suene como un marco de desarrollo web tradicional (como RoR). RoR tiene la API REST correcta, pero creemos que Meteor tiene la razón en tiempo real.
Max Hodges
Gracias por la respuesta. ¿También organizó el lado del servidor para las características?
Liko
5

Utilice andamios de hierro-cli CLI. Hace las cosas muy fáciles.

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

una vez instalado. utilizar iron create my-apppara crear un nuevo proyecto. Creará la siguiente estructura para usted. También puede usar esto en proyectos existentes. utilizar iron migrateen el directorio del proyecto.

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
fuente
Si bien este enlace puede responder la pregunta, es mejor incluir las partes esenciales de la respuesta aquí y proporcionar el enlace como referencia. Las respuestas de solo enlace pueden volverse inválidas si la página vinculada cambia.
user2314737
@ user2314737 Grita para decir que el respondedor editó su publicación. Ahora incluye los datos esenciales necesarios para el problema en cuestión.
Kyll
4

Estoy siguiendo el formato repetitivo mattdeom, que ya incluye el enrutador de hierro y el Modelo (Colección2). Vea abajo :

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
fuente
3

Existen muchos enfoques diferentes para estructurar su aplicación. Por ejemplo, si tiene un enrutador y diferentes plantillas de página, y dentro de cada plantilla de página tiene muchas partes de página, etc., lo estructuraría dependiendo de la semántica de nivel superior> inferior.

Por ejemplo:

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
     ...

Por supuesto, puede poner sus plantillas de noticias en la carpeta común, ya que puede usar su plantilla de noticias en diferentes páginas.

Creo que es mejor estructurar su aplicación de una manera cómoda.

Escribí una pequeña aplicación aquí: http://gold.meteor.com Y es tan pequeña que uso solo un archivo html y solo un archivo template.js .. :)

Espero que ayude un poco

Boris Kotov
fuente
No veo valor en nombrar varios archivos con un nombre de función como "artículos". Ahora, si desea cambiar el nombre de la función a "publicaciones", debe cambiar los nombres de los archivos. Simplemente organícelos en una sola carpeta llamada "artículos" y asígneles el nombre "events.js", views.html, styles, css, etc. vea mi respuesta para obtener más información.
Max Hodges
3

Hay una nueva clase en Evented Mind llamada Configuración de proyectos de meteoros que aborda esto pero también habla sobre la configuración del proyecto y la configuración de su entorno de desarrollo.

Del video Estructura de la aplicación en la clase: Meteor no tiene una opinión muy sólida sobre cómo debe estructurarse su aplicación, pero aquí hay algunas reglas:

1) Orden de carga: Meteor va primero a la ubicación más profunda del directorio de archivos y procesa los archivos en orden alfabético

2) el cliente y el servidor son carpetas especiales que Meteor reconoce

Nuestra estructura se ve así:

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/

Todos_controller extiende RouteController, algo que viene con Iron Router.

La emherramienta mencionada anteriormente también está recibiendo una gran actualización en este momento y debería estar mucho mejor y disponible en: https://github.com/EventedMind/em

katogeaver
fuente
¿Qué vistas hay dentro de / server / views /?
stefcud
No veo valor en nombrar varios archivos con un nombre de función como "todos". Ahora, si desea cambiar el nombre de la función a "tareas", debe cambiar los nombres de 5 archivos. Simplemente organícelos en una sola carpeta llamada "todos" y asígneles el nombre "events.js", views.html, styles, css, etc. vea mi respuesta para obtener más información.
Max Hodges
1

También estoy buscando las mejores prácticas para mejorar y escalar mis aplicaciones a través de una arquitectura bien concebida. Todas las prácticas mencionadas anteriormente funcionan para aplicaciones de tamaño pequeño a mediano, pero fallarán cuando trabajes en un equipo más grande. Hay varias formas en que lo he intentado:

1) Seguí esta estrategia: https://github.com/aldeed/meteor-autoform para escalar y reutilizar plantillas. El autor tiene una muy buena idea sobre el diseño de componentes y de campo. Actualmente lo estoy implementando porque la comunidad desarrolló 36 paquetes que cubren casi todos los casos y puedo usar TypeScript para escribir con seguridad durante la fase de desarrollo.

<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>

Aquí hay una buena publicación de blog sobre cómo hacerlo: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ , así como aquí: http: // meteorpedia .com / read / Blaze_Notes

2) Este se ve muy prometedor pero no se ha actualizado últimamente. Es un paquete escrito en script de café llamado. Blaze Components ( https://github.com/peerlibrary/meteor-blaze-components ) para Meteor es un sistema para desarrollar fácilmente elementos complejos de IU que deben reutilizarse en su aplicación Meteor. Puede usarlos en CoffeeScript, JavaScript vainilla y ES6. Lo mejor es que los componentes son OOP. Aquí está uno de sus ejemplos:

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) Me gustan los tipos y los transpiladores que me dicen dónde y cuándo algo saldrá mal. Estoy usando TypeScript para trabajar con Meteor y encontré el siguiente repositorio: https://github.com/dataflows/meteor-typescript-utils parece que el creador trató de lograr un enfoque 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>

Lamentablemente, este proyecto no se mantiene ni se desarrolla activamente.

4) y creo que ya se mencionó, puedes escalar usando paquetes. Eso requiere una buena forma abstracta de pensar. Parece funcionar para Telescope: https://github.com/TelescopeJS/Telescope

5) meteor-template-extension : proporciona varias formas de copiar ayudantes de plantilla, manejadores de eventos y ganchos entre plantillas, permitiendo la reutilización de código; Una desventaja es que todas las copias deben ser realizadas por un desarrollador, a menudo una y otra vez, lo que se vuelve problemático a medida que crece la base de código; Además, sin una API claramente definida, la comunidad no puede construir y compartir componentes

6) Componentes de flujo: los componentes de flujo están más cerca de reaccionar en el diseño de la API, mientras que los componentes de Blaze mantienen conceptos familiares como contextos de datos y ayudantes de plantillas; Los componentes de flujo, por otro lado, todavía usan controladores de eventos basados ​​en plantillas, mientras que los componentes de Blaze los convierten en métodos de clase para que sea más fácil extenderlos o anularlos a través de la herencia; en general, Blaze Components parece estar más orientado a OOP; Flow Components aún no se han lanzado oficialmente ( créditos de texto para los n. ° 5 y n. ° 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

Los números 2 y 3 también necesitan acostumbrarse, pero con el tiempo ganarás velocidad de desarrollo. El número cuatro le permite construir y probar componentes para hacer que su código sea más estable. El número tres viene con la ventaja de la seguridad total de Typecript, que es una gran ventaja cuando se desarrolla en un equipo con poca documentación. Sin embargo, actualmente estoy transfiriendo el número dos a TypeScript porque me siento muy cómodo para trabajar con él y no tengo que modificar el paquete del compilador para que funcione con Meteor cuando no estoy usando Gulp.

Todavía es difícil encontrar la forma correcta de trabajar con Meteor. Debe resolverlo usted mismo, de lo contrario, terminará con una estructura de carpetas bien organizada, pero no tiene idea de dónde está todo. Feliz codificación

MichelH
fuente