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
