Quais são as práticas recomendadas para estruturar um grande aplicativo Meteor com muitos arquivos de modelo HTML? [fechadas]

165

Em todos os exemplos (cabeçalho, jogo de palavras etc.), eles têm um único arquivo de modelo HTML. Existe algum grande projeto de software livre Meteor com muitos arquivos de modelo HTML diferentes que podemos usar como exemplo de prática recomendada? Não parece prático colocar tudo o que um aplicativo grande precisa em um arquivo de modelo.

meteor Andrew Arrow
fonte
meteoro é novo material, eu havenot encontrar melhores práticas no domínio nada sobre isso .Eu também esperar algum guildline sobre isso
newlife
10
Você leu a parte sobre Estruturação de sua aplicação no manual? Há alguma explicação sobre a verificação e concatenação de arquivos HTML.
Zwippie #
1
O guia oficial do Meteor sugere uma estrutura de arquivos muito legal. Verifique aqui: guide.meteor.com/structure.html#javascript-structure
Waqas

Respostas:

16

Junte tudo isso! Dos 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
fonte
29
Essa é a preocupação do pôster. O agrupamento é bom, mas você pode ver o que acontece com o Asana - ele requer uma tela de carregamento enquanto faz o download> 1 MB de código do cliente. Isso não é aceitável para muitos sites. Vamos ver se talvez não possamos fazer parte do carregamento fragmentado após o carregamento da tela principal, mas estou cético no momento. Eu acho que vai precisar ser um recurso para quebrar um pouco as coisas.
Dave Sanders
36
Esta resposta é o resultado nº 1 do Google, mas está desatualizada. Outros, futuros visitantes como eu; olhe abaixo!
Kloar
A partir da versão 1.1.0.2, o aplicativo de tarefas simples que eles demonstram transfere 1,7 MB de arquivos quando você recarrega com o cache do navegador removido. Isso é inaceitável para muitos casos de uso existentes. : / As coisas melhoram muito quando os ativos são armazenados em cache, mas, na primeira carga, é bastante brutal.
Jason Kim
Idéia: use o webpack, faça pacotes para as coisas, carregue-os preguiçosamente quando necessário.
Trusktr
sim O Asana leva algum tempo para carregar. O Asana também é um aplicativo reativo incrivelmente bem-feito, no qual os usuários criaram 175 milhões de tarefas em 2014. Os aplicativos que carregam mais rápido nem sempre são melhores. Demora um momento para que os aplicativos também sejam inicializados no seu telefone. As pessoas vão se acostumar com isso.
Max Hodges
274

Como no FAQ não oficial de meteoros, acho que explica bastante como estruturar um aplicativo grande:

Onde devo colocar meus arquivos?

Os aplicativos de exemplo no meteoro são muito simples e não fornecem muitas informações. Aqui está o meu pensamento atual sobre a melhor maneira de fazê-lo: (todas as sugestões / melhorias são bem-vindas!)

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 aplicativos maiores, a funcionalidade discreta pode ser dividida em subdiretórios que são eles próprios organizados usando o mesmo padrão. A idéia aqui é que, eventualmente, o módulo de funcionalidade possa ser fatorado em um pacote inteligente separado e, idealmente, compartilhado.

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

Saiba mais: Perguntas frequentes sobre meteoros não oficiais

yagooar
fonte
12
IMHO isso é melhor do que a resposta aceita. Eu vou tentar isso agora.
hakan 02/09
17
Desde a versão 0.6.0, é muito melhor evitar essa bagunça e executar o aplicativo inteiramente a partir de pacotes inteligentes. Eu entrar em detalhes um pouco mais neste blog: matb33.me/2013/09/05/meteor-project-structure.html
matb33
1
alguém tem uma idéia de onde colocar o mobile-config.js?
Cara,
1
Obrigado pela resposta e pelo link para a pergunta não oficial (eu sou novo no mundo dos meteoros), o que eles querem dizer com "código comum de outra pessoa"?
Cohars
3
Quanto ao meteoro 1.3, eu diria que isso está desatualizado devido à importação do módulo ES6. Veja o artigo do guia de meteoros sobre a estrutura da aplicação: guide.meteor.com/structure.html
Samuel
36

Eu concordo com yagooar, mas em vez de:

client / application.js

Usar:

client / main.js

Os principais arquivos. * são carregados por último. Isso ajudará a garantir que você não tenha nenhum problema de pedido de carga. Veja a documentação do Meteor, http://docs.meteor.com/#structuringyourapp , para mais detalhes.

pwcremin
fonte
26

O Meteor foi projetado para que você estruture seu aplicativo da maneira que desejar. Portanto, se você não gostar da sua estrutura, basta mover um arquivo para um novo diretório ou até dividir um arquivo em várias partes, e para o Meteor é praticamente o mesmo. Observe o tratamento especial dos diretórios cliente, servidor e público, conforme especificado na página principal da documentação: http://docs.meteor.com/ .

Apenas agrupar tudo em um preenchimento de HTML certamente não surgirá como uma prática recomendada.

Aqui está um exemplo de uma estrutura possível: em um dos meus aplicativos, um fórum de discussão, organizo por módulo ou "tipo de página" (página inicial, fórum, tópico, comentário), colocando arquivos .css, .html e .js para cada tipo de página juntos em um diretório. Eu também tenho um módulo "base", que contém códigos .css e .js comuns e o modelo mestre, que usa {{renderPage}} para renderizar um dos outros módulos, dependendo do roteador.

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

Você também pode organizar por função

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

Espero que algumas estruturas de práticas recomendadas mais específicas e convenções de nomenclatura surjam.

Jonathan Warden
fonte
2
Esta é a minha resposta favorita. Uma das minhas coisas favoritas sobre o Meteor é que você pode estruturar seus arquivos de uma maneira que funcione para você.
CaptSaltyJack 31/01
Eu gosto desta resposta. Eu tenho feito isso da primeira maneira.
Sung Cho
coisas relacionadas devem estar próximas umas das outras. Minha resposta é como a sua, mas ao contrário.
Max Hodges
1.3 lib zapped em favor das importações guide.meteor.com/structure.html#example-app-structure
Jeremy Iglehart
não vejo valor em nomear vários arquivos com um nome de recurso como "topic". Agora, se você deseja alterar o nome do recurso para "categoria", é necessário alterar vários nomes de arquivos. Basta organizá-los em uma única pasta chamada "topic" e nomeá-los genericamente: events.js, views.html, estilos, css, routes.js, etc. veja minha resposta para mais.
Max Hodges
14

Para quem está pesquisando no Google sobre este tópico:

A emferramenta de linha de comando (da EventedMind, o pessoal do Iron Router) é muito útil ao montar um novo aplicativo Meteor. Isso criará uma boa estrutura de arquivos / pastas. Se você já trabalha em um aplicativo e deseja reorganizá-lo, basta configurar um novo projeto eme usá-lo como inspiração.

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

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

Mikael Lirbank
fonte
4
Nota: este foi substituído por iron-cli (mesmo autor). Veja: github.com/iron-meteor/iron-cli
j0e
Sim, 'em' foi renomeado iron-cli, a mesma ferramenta.
Mikael Lirbank 01/09/2015
11

Eu acho que a estrutura de arquivos do Discover Meteor Book é realmente boa e um começo sólido. 

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • O código no diretório / server é executado apenas no servidor.
  • O código no diretório / client é executado apenas no cliente.
  • Tudo o resto é executado no cliente e no servidor.
  • Os arquivos em / lib são carregados antes de qualquer outra coisa.
  • Qualquer arquivo. * Principal é carregado depois de todo o resto.
  • Seus ativos estáticos (fontes, imagens, etc.) vão para o diretório / public.
Almog Koren
fonte
10

Criar pacotes

É claro que nem tudo se encaixa nessa abordagem, mas em aplicativos grandes, você terá muitas funcionalidades que podem ser isoladas. Qualquer coisa separável e reutilizável cabe nos pacotes, o restante segue a estrutura de diretórios usual, como mencionado em outras respostas. Mesmo se você não criar pacotes para evitar a sobrecarga, estruturar o código de maneira modular é uma boa ideia (consulte estas sugestões )

O Meteor permite um controle refinado sobre como você carrega seus arquivos (ordem de carregamento, onde: cliente / servidor / ambos) e o que o pacote exporta.

Acho especialmente útil a maneira mais fácil de compartilhar a lógica entre os arquivos relacionados. Digamos, por exemplo, que você queira fazer alguma função util e usar em arquivos diferentes. Você apenas o torna "global" (sem o var) e o Meteor o agrupa no espaço para nome do pacote, para que não polua o espaço para nome global

Aqui está o documento oficial

Bogdan D
fonte
6

Depois de um tempo fora da codificação meteorjs, fico feliz por ter algum tempo livre para dedicar à construção de um jogo online bastante complexo. A estrutura do aplicativo foi uma das minhas primeiras preocupações e parece que vários programadores muito bons defendem o método somente de pacote de estruturar um aplicativo, o que permite que você junte livremente pacotes funcionalmente distintos. Existem outras vantagens na abordagem e dois artigos muito bons que explicam a abordagem podem ser encontrados aqui:

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

lukenofurther
fonte
6

Temos um grande projeto (provavelmente um dos maiores projetos de Meteor que alguém já construiu até hoje, pois estava em desenvolvimento em tempo integral por 1,5 anos). Usamos o mesmo conjunto de nomes de arquivos em cada visualização. É muito consistente e nos ajuda a navegar rapidamente para exatamente o que estamos procurando:

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

É assim em um projeto:

       ├── consolidationRequests
       │ ├── events.js
       │ ├── helpers.js
       Rou ├── routers.js
       Templates └── templates.html
       Customer── customerSpoof
       Rou └── routers.js
       ├── painel
       │ ├── events.js
       │ ├── helpers.js
       On ├── onDestroyed.js
       On ├── onRendered.js
       Rou ├── routers.js
       Templates └── templates.html
       ├── emailVerification
       │ ├── events.js
       │ ├── helpers.js
       Rou ├── routers.js
       Templates └── templates.html
       Loading── loading
       │ ├── styles.css
       Templates └── templates.html
       Mailbox── ​​caixa de correio
       Aut ├── autoform.js
       Consolid ├── consolidationRequestConfirmation
       . │ ├── events.js
       │ │ ├── helpers.js
       On │ ├── onCreated.js
       On │ ├── onRendered.js
       Templates │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js

Os modelos relacionados são armazenados apenas juntos no mesmo arquivo. O conteúdo view/order/checkout/templates.htmlmostrado foi recolhido aqui:

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

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

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

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

Usamos subpastas quando as visualizações ficam complexas com várias partes:

       ├── carrinho
       Add ├── addItem
       Aut │ ├── autoform.js
       . │ ├── events.js
       │ │ ├── helpers.js
       On │ ├── onRendered.js
       Rou │ ├── routers.js
       │ │ ├── styles.less
       Templates │ └── templates.html
       │ ├── checkout
       Aut │ ├── autoform.js
       . │ ├── events.js
       │ │ ├── helpers.js
       On │ ├── onRendered.js
       Rou │ ├── routers.js
       Templates │ └── templates.html
       View └── view
       Aut ├── autoform.js
       I ├── deleteItem
       . │ ├── events.js
       │ │ ├── helpers.js
       Templates │ └── templates.html
       │ ├── editItem
       Aut │ ├── autoform.js
       . │ ├── events.js
       │ │ ├── helpers.js
       Templates │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js
       On ├── onDestroyed.js
       On ├── onRendered.js
       Rou ├── routers.js
       │ ├── styles.less
       Templates └── templates.html

Também desenvolvemos com o WebStorm, um editor extremamente poderoso e flexível para o desenvolvimento do Meteor. Achamos imensamente útil ao pesquisar e organizar nosso código e trabalhar de forma produtiva. Visualização Tempestade na Web

É um prazer compartilhar detalhes a pedido.

Max Hodges
fonte
3
Por favor, considere adicionar um comentário se você acha que esta resposta pode ser melhorada.
Max Hodges
Ótimo post. Pergunta: Depois de todo esse tempo com meteoros, você ainda o recomenda para projetos grandes, como um comércio eletrônico? Ou considere usar uma estrutura que possa lhe dar mais "autonomia" como LoopBack ou mesmo Happi.
Liko
nós amamos o Meteor e desenvolvemos tudo de novo nele. Infelizmente, não estou familiarizado o suficiente com o LoopBack ou a Happi para ter uma opinião.
Max Hodges
1
O LoopBacks concentra-se nas APIs de descanso de ponta a ponta que soam como uma estrutura de desenvolvimento da Web tradicional (como o RoR). O RoR acertou a API REST, mas achamos que o Meteor acertou em tempo real.
Max Hodges
Obrigado pelo feedback. Você organizou o lado do servidor para recursos também?
Liko
5

Use a CLI do andaime da Iron-Cli. Torna as coisas muito fáceis.

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

uma vez instalado. use iron create my-apppara criar um novo projeto. Ele criará a seguinte estrutura para você. Você também pode usar isso em projetos existentes. use iron migrateno diretório do projeto.

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
fonte
Embora esse link possa responder à pergunta, é melhor incluir aqui as partes essenciais da resposta e fornecer o link para referência. As respostas somente para links podem se tornar inválidas se a página vinculada for alterada.
user2314737
@ user2314737 Grite para dizer que o respondente editou sua postagem. Agora inclui os dados essenciais necessários para o problema em questão.
22715 Kyll
4

Estou seguindo o formato padrão da mattdeom, que já inclui o roteador e o modelo de ferro (Coleção2). Ver abaixo :

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

Existem várias abordagens diferentes para estruturar seu aplicativo. Por exemplo, se você tiver um roteador e modelos de página diferentes, e no interior de cada modelo de página houver muitas partes da página e assim por diante, eu estruturaria isso dependendo da semântica do nível superior> inferior.

Por exemplo:

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

Obviamente, você pode colocar seus modelos de notícias na pasta comum, como também pode usá-los em páginas diferentes.

Eu acho que é o melhor que você estrutura seu aplicativo de uma maneira que você se sinta confortável.

Eu escrevi um pequeno aplicativo aqui: http://gold.meteor.com E é tão pequeno que eu uso apenas um arquivo html e apenas um arquivo template.js .. :)

Espero que ajude um pouco

Boris Kotov
fonte
não vejo valor em nomear vários arquivos com um nome de recurso como "articles". Agora, se você deseja alterar o nome do recurso para "postagens", é necessário alterar os nomes dos arquivos. Apenas organize-os em uma única pasta chamada "artigos" e nomeie-os como "events.js", views.html, styles, css, etc. veja minha resposta para mais.
Max Hodges
3

Há uma nova classe no Evented Mind chamada Configurando Projetos de Meteoros que aborda isso, mas também fala sobre a configuração do projeto e a configuração do seu ambiente de desenvolvimento.

No vídeo Estrutura da aplicação na classe: O Meteor não tem uma opinião muito forte sobre como sua aplicação deve ser estruturada, mas aqui estão algumas regras:

1) Ordem de carregamento - O Meteor vai primeiro ao local mais profundo do diretório de arquivos e processa os arquivos em ordem alfabética

2) cliente e servidor são pastas especiais que o Meteor reconhece

Nossa estrutura fica assim:

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/

O todos_controller estende o RouteController, algo que vem com o Iron Router.

A emferramenta mencionada acima também está recebendo uma grande atualização no momento e deve estar muito melhor e disponível em: https://github.com/EventedMind/em

katogeaver
fonte
o que há em / server / views /?
stefcud
não vejo valor em nomear vários arquivos com um nome de recurso como "todos". Agora, se você deseja alterar o nome do recurso para "tarefas", é necessário alterar 5 nomes de arquivos. Apenas organize-os em uma única pasta chamada "todos" e nomeie-os como "events.js", views.html, styles, css, etc. veja minha resposta para mais.
Max Hodges
1

Também estou procurando as melhores práticas para aprimorar e dimensionar meus aplicativos por meio de uma arquitetura bem concebida. Todas as práticas mencionadas acima funcionam para aplicativos de pequeno e médio porte, mas falham quando você trabalha em uma equipe maior. Existem várias maneiras de tentar:

1) Segui esta estratégia: https://github.com/aldeed/meteor-autoform para dimensionar e reutilizar modelos. O autor tem uma ideia muito boa sobre o design de componentes e campos. No momento, estou implementando porque a comunidade desenvolveu 36 pacotes que cobrem quase todos os casos e eu posso usar o TypeScript para ter segurança de tipo durante a fase de desenvolvimento.

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

Aqui está uma boa postagem no blog sobre como fazê-lo: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ , bem como aqui: http: // meteorpedia .com / read / Blaze_Notes

2) Este parece tão promissor, mas não foi atualizado recentemente. É um pacote escrito em script de café chamado. Os Blaze Components ( https://github.com/peerlibrary/meteor-blaze-components ) para Meteor são um sistema para o desenvolvimento fácil de elementos complexos da interface do usuário que precisam ser reutilizados em seu aplicativo Meteor. Você pode usá-los no CoffeeScript, vanilla JavaScript e ES6. A melhor coisa é que os componentes são OOP. Aqui está um de seus exemplos:

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) Gosto de tipos e transpiler que me dizem onde e quando algo dará errado. Estou usando o TypeScript para trabalhar com o Meteor e encontrei o seguinte repositório: https://github.com/dataflows/meteor-typescript-utils , parece que o criador tentou realizar uma abordagem 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>

Infelizmente, este projeto não é mantido ou desenvolvido ativamente.

4) e acho que já foi mencionado, você pode escalar usando pacotes. Isso requer uma boa maneira abstrata de pensar. Parece funcionar para o Telescope: https://github.com/TelescopeJS/Telescope

5) extensão de modelo de meteoro - fornece várias maneiras de copiar auxiliares de modelo, manipuladores de eventos e ganchos entre modelos, permitindo a reutilização de código; uma desvantagem é que todas as cópias devem ser cuidadas por um desenvolvedor, muitas vezes repetidas vezes, o que se torna problemático à medida que a base de código cresce; além disso, sem uma comunidade de API claramente definida, não é possível criar e compartilhar componentes

6) Componentes de fluxo - Os componentes de fluxo estão mais próximos do React no design da API, enquanto o Blaze Components mantém conceitos familiares como contextos de dados e auxiliares de modelos; Os componentes de fluxo, por outro lado, ainda usam manipuladores de eventos baseados em modelo, enquanto os componentes do Blaze os tornam métodos de classe, para que seja mais fácil estendê-los ou substituí-los por herança; em geral, o Blaze Components parece ser mais orientado para OOP; Os componentes de fluxo ainda não foram lançados oficialmente ( créditos de texto para # 5 e # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

Os números 2 e 3 também precisam ser acostumados, mas você ganhará velocidade de desenvolvimento ao longo do tempo. O número quatro permite criar e testar componentes para tornar seu código mais estável. O número três vem com a vantagem da segurança de tipo completo do Typescript, que é uma grande vantagem quando você desenvolve uma equipe com documentação insuficiente. No entanto, atualmente estou portando o número dois para o TypeScript, porque me sinto muito confortável em trabalhar com ele e não preciso alterar o pacote do compilador para que ele funcione com o Meteor quando não estou usando o Gulp.

Ainda é difícil encontrar o caminho certo para trabalhar com o Meteor. Você precisa descobrir por si mesmo, caso contrário, você acaba com uma estrutura de pastas bem organizada, mas não tem idéia de onde está tudo. Feliz codificação.

MichelH
fonte