Szukam również najlepszych praktyk, aby ulepszyć i skalować moje aplikacje za pomocą dobrze przemyślanej architektury. Wszystkie powyższe praktyki sprawdzają się w przypadku małych i średnich aplikacji, ale zawodzą, gdy pracujesz w większym zespole. Próbowałem na kilka sposobów:
1) Postępowałem zgodnie z tą strategią: https://github.com/aldeed/meteor-autoform, aby skalować i ponownie wykorzystywać szablony. Autor ma bardzo dobry pomysł na projektowanie komponentów i terenów. Obecnie wdrażam go, ponieważ społeczność opracowała 36 pakietów, które obejmują prawie każdy przypadek i mogę używać TypeScript, aby zachować bezpieczeństwo pisania na etapie rozwoju.
<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>
Oto dobry post na blogu, jak to zrobić: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ oraz tutaj: http: // meteorpedia .com / read / Blaze_Notes
2) Ten wygląda tak obiecująco, ale ostatnio nie był aktualizowany. Jest to pakiet napisany w skrypcie kawowym o nazwie. Komponenty Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) dla Meteor to system do łatwego tworzenia złożonych elementów UI, które muszą być ponownie użyte w Twojej aplikacji Meteor. Możesz ich używać w CoffeeScript, waniliowym JavaScript i ES6. Najlepsze jest to, że komponenty są OOP. Oto jeden z ich przykładów:
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) Lubię typy i transpilery, które mówią mi, gdzie i kiedy coś pójdzie nie tak. Używam TypeScript do pracy z Meteor i znalazłem następujące repozytorium: https://github.com/dataflows/meteor-typescript-utils wygląda na to, że twórca próbował osiągnąć podejście 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>
Niestety ten projekt nie jest utrzymywany ani aktywnie rozwijany.
4) i myślę, że już o tym wspomniano, można skalować za pomocą pakietów. To wymaga dobrego abstrakcyjnego sposobu myślenia. Wydaje się, że działa dla Telescope: https://github.com/TelescopeJS/Telescope
5) rozszerzenie meteor-template - zapewnia różne sposoby kopiowania pomocników szablonów, programów obsługi zdarzeń i hooków między szablonami, umożliwiając ponowne użycie kodu; Wadą jest to, że wszelkie kopiowanie musi być wykonywane przez programistę, często w kółko, co staje się problematyczne wraz ze wzrostem bazy kodu; ponadto bez jasno zdefiniowanej społeczności API nie można tworzyć i udostępniać komponentów
6) Komponenty Flow - Komponenty Flow są bliżej Reacta w projekcie API, podczas gdy Komponenty Blaze zachowują znane pojęcia, takie jak konteksty danych i pomoce szablonów; Z drugiej strony, komponenty Flow nadal używają programów obsługi zdarzeń opartych na szablonach, podczas gdy składniki Blaze sprawiają, że są one metodami klasowymi, dzięki czemu łatwiej jest je rozszerzać lub zastępować poprzez dziedziczenie; generalnie komponenty Blaze wydają się być bardziej zorientowane na OOP; Komponenty Flow nie zostały jeszcze oficjalnie wydane ( kredyty tekstowe dla nr 5 i nr 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
Numery 2 i 3 również wymagają przyzwyczajenia, ale z czasem przyspieszysz rozwój. Numer cztery pozwala budować i testować komponenty, aby uczynić kod bardziej stabilnym. Numer trzy ma tę zaletę, że typescript zapewnia pełne bezpieczeństwo typów, co jest ogromnym plusem, gdy tworzysz w zespole ze słabą dokumentacją. Jednak obecnie przenoszę numer dwa na TypeScript, ponieważ czuję się bardzo komfortowo z nim pracować i nie muszę dostosowywać pakietu kompilatora, aby działał z Meteor, gdy nie używam Gulp.
Wciąż ciężko jest znaleźć właściwy sposób pracy z Meteor. Musisz sam to rozgryźć, w przeciwnym razie otrzymasz ładnie ułożoną strukturę folderów, ale nie masz pojęcia, gdzie wszystko jest. Miłego kodowania.
