Я також шукаю кращі практики для покращення та масштабування моїх додатків за допомогою добре продуманої архітектури. Усі вищезазначені практики працюють для додатків малого та середнього розміру, але вони не спрацьовують, коли ви працюєте в більшій команді. Я спробував кілька способів:
1) Я дотримувався цієї стратегії: https://github.com/aldeed/meteor-autoform для масштабування та повторного використання шаблонів. Автор має дуже гарну ідею щодо компонентного та польового дизайну. Зараз я його реалізую, оскільки спільнота розробила 36 пакетів, які охоплюють майже кожен випадок, і я можу використовувати TypeScript для безпечного типу під час фази розробки.
<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>
Ось хороший пост у блозі про те, як це зробити: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ , а також тут: http: // meteorpedia .com / read / Blaze_Notes
2) Це виглядає настільки перспективно, але останнім часом його не оновлювали. Це пакет, написаний у кавовому сценарії під назвою. Компоненти Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) для Meteor - це система для легкої розробки складних елементів інтерфейсу, які потрібно повторно використовувати навколо вашої програми Meteor. Ви можете використовувати їх у CoffeeScript, ванільному JavaScript та ES6. Найкраще, що компоненти - це OOP. Ось один із їх прикладів:
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) Мені подобаються типи та транспілятори, які підказують мені, де і коли щось піде не так. Я використовую TypeScript для роботи з Meteor і знайшов наступне сховище: https://github.com/dataflows/meteor-typescript-utils, схоже, що творець намагався здійснити підхід 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>
На жаль, цей проект не підтримується або активно розвивається.
4) і я думаю, що це вже згадувалося, ви можете масштабувати за допомогою пакетів. Для цього потрібен хороший абстрактний спосіб мислення. Здається, це працює для телескопа: https://github.com/TelescopeJS/Telescope
5) метеор-шаблон-розширення - надає різні способи копіювання помічників шаблонів, обробників подій та гаків між шаблонами, що дозволяє повторно використовувати код; Недоліком є те, що над усіма копіюваннями повинен піклуватися розробник, часто знову і знову, що стає проблематичним у міру зростання кодової бази; крім того, без чітко визначеного API спільнота не може створювати та ділити компоненти
6) Компоненти потоку - компоненти потоку ближче до Реагують в дизайні API, тоді як Blaze Components зберігають звичні поняття, такі як контексти даних та помічники шаблонів; Компоненти потоку, з іншого боку, все ще використовують обробники подій на основі шаблонів, тоді як Blaze Components роблять їх методами класів, щоб їх було легше розширити або змінити шляхом успадкування; загалом Blaze Components, здається, більш орієнтований на ООП; Компоненти потоку ще не офіційно випущені ( текстові кредити для №5 та №6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
Числа 2 і 3 теж потребують звикання, але ви з часом наберете швидкість розвитку. Номер чотири дозволяє створювати та тестувати компоненти, щоб зробити ваш код стабільнішим. Номер три має перевагу безпеки повного типу Typescript, що є величезним плюсом, коли ви розвиваєтесь у команді з поганою документацією. Однак я зараз переношу номер два в TypeScript, тому що мені дуже зручно працювати з ним, і мені не потрібно змінювати пакет компілятора, щоб він працював з Meteor, коли я не використовую Gulp.
Досі важко знайти правильний спосіб співпраці з "Метеором". Вам потрібно розібратися в цьому для себе, інакше ви закінчите гарно впорядковану структуру папок, але у вас немає поняття, де все є. Щасливе кодування.
