Sto anche cercando le migliori pratiche per migliorare e ridimensionare le mie app attraverso un'architettura ben concepita. Tutte le pratiche sopra menzionate funzionano per app di piccole e medie dimensioni ma falliranno quando lavori in un team più grande. Ci sono diversi modi in cui ho provato:
1) Ho seguito questa strategia: https://github.com/aldeed/meteor-autoform per ridimensionare e riutilizzare i modelli. L'autore ha un'ottima idea sulla progettazione di componenti e campi. Attualmente lo sto implementando perché la community ha sviluppato 36 pacchetti che coprono quasi tutti i casi e posso usare TypeScript per essere sicuro durante la fase di sviluppo.
<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>
Ecco un buon post sul blog su come farlo: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ e qui: http: // meteorpedia .com / lettura / Blaze_Notes
2) Questo sembra così promettente ma non è stato aggiornato di recente. È un pacchetto scritto in una sceneggiatura del caffè chiamato. I componenti Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) per Meteor sono un sistema per sviluppare facilmente complessi elementi dell'interfaccia utente che devono essere riutilizzati attorno all'app Meteor. Puoi usarli in CoffeeScript, JavaScript vaniglia ed ES6. La cosa migliore è che i componenti sono OOP. Ecco uno dei loro esempi:
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) Mi piacciono i tipi e il transpiler che mi dicono dove e quando qualcosa andrà storto. Sto usando TypeScript per lavorare con Meteor e ho trovato il seguente repository: https://github.com/dataflows/meteor-typescript-utils sembra che il creatore abbia provato a realizzare un approccio 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>
Sfortunatamente, questo progetto non è mantenuto o sviluppato attivamente.
4) e penso che sia già stato menzionato, puoi ridimensionare usando i pacchetti. Ciò richiede un buon modo di pensare astratto. Sembra funzionare per Telescope: https://github.com/TelescopeJS/Telescope
5) meteor-template-extension - offre vari modi per copiare helper di template, gestori di eventi e hook tra template, permettendo il riutilizzo del codice; un aspetto negativo è che tutte le copie devono essere curate da uno sviluppatore, spesso ancora e ancora, il che diventa problematico man mano che cresce la base di codice; inoltre, senza una comunità API chiaramente definita non è possibile creare e condividere componenti
6) Componenti di flusso - I componenti di flusso sono più vicini a React nella progettazione dell'API mentre Blaze Components mantiene concetti familiari come contesti di dati e helper di template; D'altra parte, Flow Components utilizza ancora gestori di eventi basati su template mentre Blaze Components li rende metodi di classe in modo che sia più facile estenderli o sovrascriverli tramite l'ereditarietà; in generale Blaze Components sembra essere più orientato verso OOP; I componenti di flusso non sono ancora ufficialmente rilasciati ( crediti di testo per # 5 e # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
Anche i numeri 2 e 3 richiedono un po 'di tempo per abituarsi, ma otterrai velocità di sviluppo nel tempo. Il numero quattro consente di creare e testare componenti per rendere il codice più stabile. Il numero tre offre il vantaggio della piena sicurezza del tipo di Typescript, che è un grande vantaggio quando si sviluppa in un team con scarsa documentazione. Tuttavia, sto attualmente eseguendo il porting del numero due su TypeScript perché mi sento molto a mio agio nel lavorarci e non devo modificare il pacchetto del compilatore per farlo funzionare con Meteor quando non sto usando Gulp.
È ancora difficile trovare il modo giusto di lavorare con Meteor. Devi capirlo da solo, altrimenti finisci con una struttura di cartelle ben organizzata, ma non hai idea di dove sia tutto. Buona codifica.
