Je recherche également les meilleures pratiques pour améliorer et faire évoluer mes applications grâce à une architecture bien conçue. Toutes les pratiques mentionnées ci-dessus fonctionnent pour les applications de petite à moyenne taille, mais échoueront lorsque vous travaillez dans une plus grande équipe. J'ai essayé plusieurs façons:
1) J'ai suivi cette stratégie: https://github.com/aldeed/meteor-autoform pour redimensionner et réutiliser les modèles. L'auteur a une très bonne idée de la conception des composants et du terrain. Je l'implémente actuellement car la communauté a développé 36 packages qui couvrent presque tous les cas et je peux utiliser TypeScript pour être sûr de type pendant la phase de développement.
<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>
Voici un bon article de blog sur la façon de le faire: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ ainsi que ici: http: // meteorpedia .com / read / Blaze_Notes
2) Celui-ci a l'air si prometteur mais n'a pas été mis à jour récemment. Il s'agit d'un package écrit en script coffee appelé. Blaze Components ( https://github.com/peerlibrary/meteor-blaze-components ) pour Meteor est un système permettant de développer facilement des éléments d'interface utilisateur complexes qui doivent être réutilisés autour de votre application Meteor. Vous pouvez les utiliser dans CoffeeScript, JavaScript vanilla et ES6. La meilleure chose est que les composants sont OOP. Voici un de leurs exemples:
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) J'aime les types et les transpilateurs qui me disent où et quand quelque chose va mal. J'utilise TypeScript pour travailler avec Meteor et j'ai trouvé le référentiel suivant: https://github.com/dataflows/meteor-typescript-utils, il semble que le créateur ait essayé d'accomplir une approche 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>
Malheureusement, ce projet n'est pas maintenu ou développé activement.
4) et je pense que cela a déjà été mentionné, vous pouvez mettre à l'échelle à l'aide de packages. Cela nécessite une bonne façon de penser abstraite. Cela semble fonctionner pour Telescope: https://github.com/TelescopeJS/Telescope
5) meteor-template-extension - fournit diverses façons de copier les aides de modèle, les gestionnaires d'événements et les crochets entre les modèles, permettant la réutilisation du code; un inconvénient est que toute copie doit être prise en charge par un développeur, souvent encore et encore, ce qui devient problématique à mesure que la base de code se développe; de plus, sans une communauté d'API clairement définie, il est impossible de créer et de partager des composants
6) Composants de flux - Les composants de flux sont plus proches de React dans la conception de l'API tandis que les composants Blaze conservent des concepts familiers tels que les contextes de données et les aides de modèle; Les composants de flux, quant à eux, utilisent toujours des gestionnaires d'événements basés sur des modèles tandis que les composants Blaze en font des méthodes de classe afin qu'il soit plus facile de les étendre ou de les remplacer par héritage; en général, Blaze Components semble être plus orienté POO; Les composants de flux ne sont pas encore officiellement publiés ( crédits textuels pour # 5 et # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
Les numéros 2 et 3 doivent également être utilisés, mais vous gagnerez en vitesse de développement avec le temps. Le numéro quatre vous permet de créer et de tester des composants pour rendre votre code plus stable. Le numéro trois présente l'avantage de la sécurité de type complet de Typescript, ce qui est un énorme avantage lorsque vous développez dans une équipe avec une documentation médiocre. Cependant, je porte actuellement le numéro deux sur TypeScript car je me sens très à l'aise pour travailler avec et je n'ai pas à modifier le package du compilateur pour le faire fonctionner avec Meteor lorsque je n'utilise pas Gulp.
Il est encore difficile de trouver la bonne façon de travailler avec Meteor. Vous devez le découvrir par vous-même, sinon vous vous retrouvez avec une structure de dossiers bien organisée, mais vous ne savez pas où tout se trouve. Bon codage.
