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.
