Pergunta sobre meteor – Quais são as melhores práticas 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 projeto Meteor grande e de código aberto com muitos arquivos de modelo HTML diferentes que podemos usar como um exemplo de prática recomendada? Não parece prático colocar tudo o que um aplicativo grande precisa em um único arquivo de modelo.

meteoro é coisa nova, eu não encontrei nada relacionado com a melhor prática sobre isso. Eu também espero alguma guildline sobre isso newlife
Você leu a parte sobreEstruturando seu aplicativo no manual? Há alguma explicação sobre a varredura e a concatenação de arquivos HTML. zwippie
O guia oficial do Meteor sugere uma estrutura de arquivos muito legal. Verifique aqui:guide.meteor.com/structure.html#javascript-structure Waqas

Sua resposta

14   a resposta
1

onar meus aplicativos por meio de uma arquitetura bem concebida. Todas as práticas mencionadas acima funcionam para aplicativos de tamanho pequeno a médio, mas falharão quando você trabalhar em uma equipe maior. Existem várias maneiras que tentei:

1) Eu segui essa estratégia:https://github.com/aldeed/meteor-autoform para dimensionar e reutilizar modelos. O autor tem uma boa ideia sobre design de componentes e campos. Eu estou implementando atualmente porque a comunidade desenvolveu 36 pacotes que cobrem quase todos os casos e eu posso usarTypeScript para ser do tipo seguro 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á um bom post sobre como fazer isso: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 ultimamente. É um pacote escrito em roteiro de café chamado. Componentes de Chamas (https://github.com/peerlibrary/meteor-blaze-components) para o Meteor é um sistema para desenvolver facilmente elementos de interface do usuário complexos que precisam ser reutilizados em torno do 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 dos exemplos deles:

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) Eu gosto de tipos e transpiladores que me dizem onde e quando algo vai dar errado. Eu 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 um bom modo abstrato de pensar. Parece funcionar para o telescópio:https://github.com/TelescopeJS/Telescope

5)meteor-template-extension - fornece várias formas de copiar ajudantes 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 atendidas por um desenvolvedor, muitas vezes, de novo e de novo, o que se torna problemático à medida que a base de código cresce; Além disso, sem uma comunidade de APIs claramente definida, não é possível criar e compartilhar componentes

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

Os números 2 e 3 também precisam de alguns ajustes, mas você ganhará velocidade de desenvolvimento ao longo do tempo. O número quatro permite que você crie e teste componentes para tornar seu código mais estável. O número três vem com a vantagem do tipo completo de segurança do Typescript, que é uma enorme vantagem quando você se desenvolve em uma equipe com pouca documentação. No entanto, eu estou atualmente portando o número dois para o TypeScript porque me sinto muito confortável para trabalhar com ele e não tenho que tweek o pacote do compilador para fazê-lo funcionar 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 você não tem idéia de onde tudo está. Codificação feliz.

9
Crie pacotes

É claro que nem tudo se encaixa nessa abordagem, mas em grandes aplicativos você terá muitas funcionalidades que podem ser isoladas. o resto vai na estrutura de diretórios usual, como mencionado em outras respostas. Mesmo que você não faça pacotes para evitar a sobrecarga, estruturar o código de maneira modular é uma boa ideiaestas 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.

Eu particularmente acho muito útil a maneira fácil de compartilhar a lógica entre os arquivos relacionados. Digamos, por exemplo, você quer fazer alguma função util e usar em arquivos diferentes. Você só faz "global" (sem ovar) e o Meteor irá envolvê-lo no namespace do pacote, para que ele não polua o namespace global

Aquié o documento oficial

6

Meteor que alguém construiu até hoje, como era 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 procuramos:

events.jshelpers.jstemplates.htmlroutes.jsstyles.lessetc.

Parece isso em um projeto:

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

Modelos relacionados são armazenados juntos no mesmo arquivo. Conteúdo deview/order/checkout/templates.html mostrado colapsado aqui:

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

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

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

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

Usamos subpastas quando as visualizações se tornam complexas com muitas partes:

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

Também desenvolvemos com o WebStorm, um editor extremamente poderoso e flexível para o desenvolvimento do Meteor. Achamos imensamente útil quando pesquisamos e organizamos nosso código e trabalhamos produtivamente.

Feliz em compartilhar detalhes a pedido.

Obrigado pelo feedback. Você organizou o lado do servidor para recursos também? Liko
nós amamos o Meteor e fazemos todos os novos desenvolvê-lo. Infelizmente eu não estou familiarizado o suficiente com LoopBack ou Happi para ter uma opinião. Max Hodges
Existem muitos boilerplates disponíveis no mercado. A maioria dos usuários preferiu seguir seu próprio caminho. Alguém fez o trabalho duro também:media.com/things-i-did-and-learned-today/… Shivam Bajpai
obrigado, vou escrever sobre a inclusão da abordagem que tomamos! Eu sinto que é melhor manter arquivos relacionados juntos, como estamos fazendo e essas abordagens não são. Max Hodges
273

acho que explica basicamente como estruturar um aplicativo grande:

Onde devo colocar meus arquivos?

Os aplicativos de exemplo no meteoro são muito simples e não fornecem muita informação. Aqui está meu pensamento atual sobre a melhor maneira de fazer isso: (quaisquer sugestões / melhorias são muito bem-vindas!)

<code>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)
</code>

Para aplicações maiores, a funcionalidade discreta pode ser dividida em subdiretórios que são organizados usando o mesmo padrão. A ideia aqui é que, eventualmente, o módulo de funcionalidade poderia ser fatorado em um pacote inteligente separado e, idealmente, compartilhado.

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

Descubra mais:FAQ não oficial do Meteor

onde devemos colocar o Meteor.subscribe? obrigado :) hqt
@piedpiper meteoro servidor de inicialização coisas vai em environment.js kpie
IMHO isso é melhor do que a resposta aceita. Eu vou tentar isso agora. hakan
appjitsu mantém um bastante abrangentemelhores práticas de meteoros aplicativo de amostra no github que usei para ajudar a estruturar alguns dos meus aplicativos. Ele coloca em prática o que @ matb33 sugere com seu post no blog. Jeremiah
36

client/application.js

Usar:

client/main.js

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

15

Junte tudo! Dos docs:

<code>> 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.
</code>
'lib' agora é 'importações'guide.meteor.com/structure.html#example-app-structure Jeremy Iglehart
@ MaxHodges: Re: "Aplicativos que carregam mais rápido nem sempre são melhores": Ceteris paribus, eles são. ruakh
@ruakh Daí o uso das palavras "nem sempre". dudewad
@dudewad: Eu não penso assim. Ele parece estar dizendo que o aumento de velocidade nem sempre é uma melhoria; pelo menos, ele não parece estar afirmando que os pontos fortes de Asana dependem de alguma forma de sua relativa lentidão. ruakh
3

Mente Evented chamadoConfigurando Projetos Meteoros que aborda isso, mas também fala sobre a configuração do projeto e a configuração do seu ambiente de desenvolvimento.

DeEstrutura de aplicação vídeo na classe: Meteor não tem uma opinião muito forte sobre como o seu aplicativo deve ser estruturado, mas aqui estão algumas regras:

1) Load order - Meteor vai para o local mais profundo no diretório de arquivos primeiro e processa os arquivos em ordem alfabética

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

Nossa estrutura se parece com isso:

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

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

oem ferramenta mencionada acima também está recebendo uma grande atualização agora e deve ser muito melhor e disponível em:https://github.com/EventedMind/em

Eu não vejo valor em nomear vários arquivos com um nome de recurso como "todos". Agora, se você quiser alterar o nome do recurso para "tarefas", terá que alterar 5 nomes de arquivos. Apenas organizá-los em uma única pasta chamada "todos" e nomeá-los "events.js", views.html, estilos, css, etc ver minha resposta para mais. Max Hodges
o que é vistas dentro de / server / views /? StefanoCudini
26

ente da maneira que desejar. Então, se você não gosta de sua estrutura, você pode simplesmente mover um arquivo para um novo diretório, ou até mesmo dividir um arquivo em vários pedaços, e para o Meteor é praticamente o mesmo. Apenas observe o tratamento especial de clientes, servidores e diretórios públicos, conforme especificado na página principal da documentação:http://docs.meteor.com/.

Apenas agrupar tudo em um preenchimento HTML certamente não será uma boa prática.

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" (home, 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 o código comum .css e .js e o modelo mestre, que usa o {{renderPage}} para renderizar um dos outros módulos, dependendo do roteador.

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

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

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

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

Eu gosto dessa 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 para trás. Max Hodges
Esta é 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
1.3 zapped lib em favor das importaçõesguide.meteor.com/structure.html#example-app-structure Jeremy Iglehart
Eu não vejo valor na nomeação de vários arquivos com um nome de recurso como "tópico". Agora, se você quiser alterar o nome do recurso para "categoria", terá que alterar vários nomes de arquivos. Apenas organize-os em uma única pasta chamada "topic" e nomeie-os genericamente: events.js, views.html, styles, css, routes.js, etc. veja minha resposta para mais. Max Hodges
11

e boa e um começo sólido.

<code>/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
</code>
O código no diretório / server só é executado no servidor.O código no diretório / client só é executado no cliente.Tudo o mais é executado no cliente e no servidor.Arquivos em / lib são carregados antes de mais nada.Qualquer arquivo principal. * É carregado depois de todo o resto.Seus ativos estáticos (fontes, imagens etc.) entram no diretório / public.
4

que já inclui o roteador de ferro e Model (Collection2). Ver abaixo :

<code>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 al,l 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
</code>
14

oem ferramenta de linha de comando (por EventedMind, os caras por trás do Iron Router) é muito útil ao manipular um novo Meteor App. Ele irá criar uma boa estrutura de arquivos / pastas. Se você já trabalha em um aplicativo e deseja reorganizá-lo, basta configurar um novo projeto comem e você pode usá-lo para inspiração.

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

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

Nota: isto foi substituído por iron-cli (mesmo autor). Vejo:github.com/iron-meteor/iron-cli j0e
Sim, eles foram renomeados iron-cli, mesma ferramenta. Mikael Lirbank
5

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

uma vez instalado. usariron create my-app para criar um novo projeto. Ele irá criar a seguinte estrutura para você. Você também pode usar isso em projetos existentes. usariron migrate no diretório do projeto.

<code>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
</code>
Embora esse link possa responder à pergunta, é melhor incluir as partes essenciais da resposta aqui e fornecer o link para referência. As respostas somente de link podem se tornar inválidas se a página vinculada for alterada. user2314737
@ user2314737 Shoutout para dizer que o respondente editou seu post. Agora inclui os dados essenciais necessários para o problema em questão. Paul Stenne
3

or exemplo, se você tem um roteador e modelos de página diferentes, e dentro de cada modelo de página você tem muitas partes de página e assim por diante, eu iria estruturá-lo depende da semântica do nível superior> inferior.

Por exemplo:

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

Claro, você poderia colocar seus modelos de notícias na pasta comum, como você poderia usar seu modelo de notícias em páginas diferentes.

Eu acho que é o melhor que você estrutura seu aplicativo de uma forma que você está confortável.

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

Espero que ajude um pouquinho

Eu não vejo valor na nomeação de vários arquivos com um nome de recurso como "artigos". Agora, se você quiser alterar o nome do recurso para "posts", você deve alterar os nomes dos arquivos. Apenas organizá-los em uma única pasta chamada "artigos" e nomeá-los "events.js", views.html, estilos, css, etc. ver minha resposta para mais. Max Hodges
6

estou feliz em ter algum tempo livre para se dedicar à construção de um jogo on-line bastante complexo. A estrutura do aplicativo tem sido uma das minhas primeiras preocupações, e parece que vários programadores muito bons têm defendido o método de estruturar um aplicativo somente com o pacote, o que permite a você acoplar vagamente pacotes funcionalmente distintos. Existem outras vantagens para a abordagem, e 2 artigos muito bons explicando 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-pattern

Perguntas relacionadas