ฉันกำลังมองหาแนวทางปฏิบัติที่ดีที่สุดเพื่อปรับปรุงและปรับขนาดแอพของฉันผ่านสถาปัตยกรรมที่เข้าใจได้ดี การปฏิบัติที่กล่าวมาทั้งหมดทำงานกับแอพขนาดเล็กถึงขนาดกลาง แต่จะล้มเหลวเมื่อคุณทำงานในทีมที่ใหญ่กว่า มีหลายวิธีที่ฉันได้ลอง:
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 / อ่าน / Blaze_Notes
2) อันนี้ดูดีมาก แต่ยังไม่ได้รับการปรับปรุงเมื่อเร็ว ๆ นี้ มันเป็นแพคเกจที่เขียนด้วยสคริปต์กาแฟที่เรียกว่า Blaze Components ( https://github.com/peerlibrary/meteor-blaze-components ) สำหรับ Meteor เป็นระบบสำหรับการพัฒนาองค์ประกอบ UI ที่ซับซ้อนได้อย่างง่ายดายซึ่งจำเป็นต้องนำแอป Meteor ของคุณกลับมาใช้ใหม่ คุณสามารถใช้พวกมันได้ใน CoffeeScript, vanilla 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) ฉันชอบประเภทและ transpiler ที่บอกฉันว่าที่ไหนและเมื่อไหร่จะเกิดอะไรขึ้น ฉันใช้ 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) และฉันคิดว่าถูกกล่าวถึงแล้วคุณสามารถขยายขนาดได้ด้วยแพ็คเกจ นั่นต้องใช้วิธีคิดที่เป็นนามธรรม ดูเหมือนว่าจะใช้งานได้กับ Telescope: https://github.com/TelescopeJS/Telescope
5) meteor-template-extension - ให้วิธีการที่หลากหลายในการคัดลอกตัวช่วยเทมเพลตตัวจัดการเหตุการณ์และ hooks ระหว่างแม่แบบอนุญาตให้ใช้รหัสซ้ำ ข้อเสียคือการคัดลอกทั้งหมดจะต้องได้รับการดูแลโดยนักพัฒนาบ่อยครั้งแล้วครั้งเล่าซึ่งเป็นปัญหาเมื่อโค้ดเบสโตขึ้น ยิ่งไปกว่านั้นหากไม่มีชุมชน API ที่กำหนดไว้อย่างชัดเจนจะไม่สามารถสร้างและแชร์ส่วนประกอบได้
6) Flow Components - Flow Component นั้นใกล้เคียงกับ React ในการออกแบบ API ในขณะที่Blaze Componentsนั้นมีแนวคิดที่คุ้นเคยเช่นบริบทข้อมูลและตัวช่วยเทมเพลต ในขณะที่ส่วนประกอบของ Flow ยังคงใช้ตัวจัดการเหตุการณ์ที่ยึดตามเทมเพลตในขณะที่ Blaze Components ทำให้วิธีการเรียนเป็นแบบง่ายขึ้นเพื่อขยายหรือแทนที่พวกเขาผ่านการสืบทอด โดยทั่วไปส่วนประกอบ Blaze ดูเหมือนว่าจะเป็น OOP ที่มุ่งเน้นมากขึ้น คอมโพเนนต์การไหลยังไม่เปิดตัวอย่างเป็นทางการ ( เครดิตข้อความสำหรับ # 5 และ # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
หมายเลข 2 และ 3 จำเป็นต้องใช้งานด้วยเช่นกัน แต่คุณจะได้รับความเร็วในการพัฒนาเมื่อเวลาผ่านไป หมายเลขสี่ให้คุณสร้างและทดสอบส่วนประกอบเพื่อทำให้รหัสของคุณมีเสถียรภาพมากขึ้น หมายเลขสามมาพร้อมกับข้อดีของการรักษาความปลอดภัยแบบเต็มรูปแบบของ typescript ซึ่งเป็นข้อดีอย่างมากเมื่อคุณพัฒนาทีมที่มีเอกสารไม่ดี อย่างไรก็ตามตอนนี้ฉันกำลังย้ายหมายเลขสองไปที่ TypeScript เพราะฉันรู้สึกสะดวกสบายในการทำงานกับมันและฉันไม่ต้องไปดูแพ็คเกจคอมไพเลอร์เพื่อให้ทำงานกับ Meteor เมื่อฉันไม่ได้ใช้ Gulp
ยังคงหาวิธีที่เหมาะสมในการทำงานกับ Meteor คุณต้องคิดออกด้วยตัวคุณเองไม่งั้นคุณจะได้โครงสร้างโฟลเดอร์ที่จัดเรียงไว้อย่างดี แต่คุณไม่มีเงื่อนงำว่าทุกอย่างอยู่ที่ไหน การเข้ารหัสที่มีความสุข
