Quelles sont les meilleures pratiques pour structurer une grande application Meteor avec de nombreux fichiers de modèle HTML?
Dans tous les exemples (classement, jeux de mots, etc.), ils ont un seul fichier modèle HTML. Existe-t-il un grand projet Meteor open source contenant de nombreux fichiers de modèle HTML que nous pouvons utiliser comme exemple de bonne pratique? Ne semble pas pratique de mettre tout ce dont une grande application a besoin dans un seul fichier modèle.
Bosse tout cela ensemble! De la docs:
> HTML files in a Meteor application are treated quite a bit differently
> from a server-side framework. Meteor scans all the HTML files in your
> directory for three top-level elements: <head>, <body>, and
> <template>. The head and body sections are seperately concatenated
> into a single head and body, which are transmitted to the client on
> initial page load.
>
> Template sections, on the other hand, are converted into JavaScript
> functions, available under the Template namespace. It's a really
> convenient way to ship HTML templates to the client. See the templates
> section for more.
Comme dans la FAQ non officielle sur les météores, je pense que cela explique à peu près comment structurer une application volumineuse:
Où devrais-je mettre mes fichiers?
Les exemples d’applications de météore sont très simples et ne fournissent pas beaucoup d’informations. Voici ma réflexion actuelle sur la meilleure façon de le faire: (toute suggestion/amélioration est la bienvenue!)
lib/ # <- any common code for client/server. lib/environment.js # <- general configuration lib/methods.js # <- Meteor.method definitions lib/external # <- common code from someone else ## Note that js files in lib folders are loaded before other js files. collections/ # <- definitions of collections and methods on them (could be models/) client/lib # <- client specific libraries (also loaded first) client/lib/environment.js # <- configuration of any client side packages client/lib/helpers # <- any helpers (handlebars or otherwise) that are used often in view files client/application.js # <- subscriptions, basic Meteor.startup code. client/index.html # <- toplevel html client/index.js # <- and its JS client/views/<page>.html # <- the templates specific to a single page client/views/<page>.js # <- and the JS to hook it up client/views/<type>/ # <- if you find you have a lot of views of the same object type client/stylesheets/ # <- css / styl / less files server/publications.js # <- Meteor.publish definitions server/lib/environment.js # <- configuration of server side packages public/ # <- static files, such as images, that are served directly. tests/ # <- unit test files (won't be loaded on client or server)Pour les applications plus grandes, les fonctionnalités discrètes peuvent être divisées en sous-répertoires, eux-mêmes organisés selon le même modèle. L'idée ici est que, éventuellement, le module de fonctionnalité pourrait être intégré dans un package intelligent séparé et, idéalement, partagé.
feature-foo/ # <- all functionality related to feature 'foo' feature-foo/lib/ # <- common code feature-foo/models/ # <- model definitions feature-foo/client/ # <- files only sent to the client feature-foo/server/ # <- files only available on the server
En savoir plus: FAQ non officielle sur les météores
Je suis d'accord avec yagooar, mais au lieu de:
client/application.js
Utilisation:
client/main.js
les fichiers main. * sont chargés en dernier. Cela vous aidera à éviter tout problème d'ordre de chargement. Voir la documentation de Meteor, http://docs.meteor.com/#structuringyourapp , pour plus de détails.
Meteor a été conçu pour structurer votre application comme vous le souhaitez. Donc, si vous n'aimez pas votre structure, vous pouvez simplement déplacer un fichier dans un nouveau répertoire, ou même scinder un fichier en plusieurs parties, et dans Meteor, c'est à peu près la même chose. Notez simplement le traitement spécial des répertoires client, serveur et public, comme indiqué dans la page de documentation principale: http://docs.meteor.com/ .
Tout mettre en place dans un seul remplissage HTML ne sera certainement pas considéré comme une pratique exemplaire.
Voici un exemple d’une structure possible: dans l’une de mes applications, un forum de discussion, j’organise par module ou par "type de page" (accueil, forum, rubrique, commentaire), en mettant les fichiers .css, .html et .js pour chaque type de page ensemble dans un répertoire. J'ai également un module "base", qui contient le code commun .css et .js, ainsi que le modèle principal, qui utilise {{renderPage}} pour afficher l'un des autres modules en fonction du routeur.
my_app/
lib/
router.js
client/
base/
base.html
base.js
base.css
home/
home.html
home.js
home.css
forum/
forum.html
forum.js
forum.css
topic/
topic.html
topic.js
topic.css
comment/
comment.html
comment.js
comment.css
Vous pouvez également organiser par fonction
my_app/
lib/
router.js
templates/
base.html
home.html
forum.html
topic.html
comment.html
js/
base.js
home.js
forum.js
topic.js
comment.js
css/
base.css
home.css
forum.css
topic.css
comment.css
J'espère cependant que des structures de pratiques optimales et des conventions de dénomination plus spécifiques émergeront.
Pour tous ceux qui sont sur Google sur ce sujet:
L'outil de ligne de commande em (de EventedMind, le gars derrière le routeur de fer) est très utile lors du montage d'une nouvelle application Meteor. Cela créera une belle structure de fichiers/dossiers. Si vous travaillez déjà sur une application et souhaitez la réorganiser, configurez simplement un nouveau projet avec em et vous pourrez vous en inspirer.
Voir: https://github.com/EventedMind/em
Et ici: https://stackoverflow.com/questions/17509551/what-is-the-best-way-torganize-templates-in-meteor-js
Je pense que la structure de fichier du Discover Meteor Book est vraiment bonne et qu'elle est un bon début.
/app:
/client
main.html
main.js
/server
/public
/lib
/collections
- Le code dans le répertoire/server ne fonctionne que sur le serveur.
- Le code dans le répertoire/client ne fonctionne que sur le client.
- Tout le reste fonctionne à la fois sur le client et le serveur.
- Les fichiers dans/lib sont chargés avant tout.
- Tout fichier principal. * Est chargé après tout le reste.
- Vos ressources statiques (polices, images, etc.) sont placées dans le répertoire/public.
Créer des packages
Bien sûr, tout ne correspond pas à cette approche, mais dans les applications volumineuses, de nombreuses fonctionnalités peuvent être isolées. Tout ce qui est séparable et réutilisable est contenu dans les paquets, le reste va dans la structure de répertoires habituelle, comme mentionné dans d'autres réponses. Même si vous ne créez pas de paquetages pour éviter la surcharge, structurer le code de manière modulaire est une bonne idée (voir ces suggestions )
Meteor permet un contrôle plus fin du chargement de vos fichiers (ordre de chargement, où: client/serveur/les deux) et de ce que le paquet exporte.
Je trouve en particulier très pratique le moyen facile de partager la logique entre les fichiers associés. Supposons, par exemple, que vous souhaitiez utiliser certaines fonctions utilitaires et les utiliser dans différents fichiers. Vous venez juste de le rendre "global" (sans le var) et Meteor l’enveloppera dans l’espace de noms du paquet, pour qu’il ne pollue pas l’espace de noms global.
Ici le document officiel
Nous avons un grand projet (probablement l'un des plus grands projets Meteor jamais construit à ce jour, car il était en développement à temps plein depuis un an et demi). Nous utilisons le même ensemble de noms de fichiers dans chaque vue. Il est très cohérent et nous aide à naviguer rapidement vers exactement ce que nous recherchons:
- événements.js
- helpers.js
- templates.html
- routes.js
- styles.less
- etc.
Ça ressemble à ça dans un projet:
├── consolidationRequests ├── events.js ├── helpers.js Routeurs.js └── └── templates.html CustomerSpoof │ routeurs.js Tableau de bord ─ events.js ├── helpers.js │ onDestroyed.js OnRendered.js Routeurs .js └── └── templates.html emailVerification events.js helpers.js ├── ├── routers.js Templates.html Chargement Styles.css ─ templates.html ├── boîte aux lettres │ autoform.js ├── ├── consolidationRequestConfirmation : Événements.js : Assistants.js │ ├── surCréé.js │ ├── onRendered.js └── templates.html Events.js Helpers.js
Les modèles associés sont simplement stockés ensemble dans le même fichier. Contenu de view/order/checkout/templates.html montré ici s'est effondré:
<template name="orderCheckout"></template>
<template name="paymentPanel"></template>
<template name="orderCheckoutSummary"></template>
<template name="paypalReturnOrderCheckout"></template>
Nous utilisons des sous-dossiers lorsque les vues sont complexes et comportent de nombreuses parties:
├── cart │ ├── addItem │ │ autoform.js │ events.js ├── │ ├── helpers.js OnRendered.js │ routers.js │ ├── styles.less │ └── templates.html ├── checkout │ autoform.js │ events.js Ender │ ├── helpers.js OnRendered.js Routers.js │ └── templates.html └── voir Autoform.js │ deleteItem │ events.js │ ├── helpers.js │ └── templates.html ├── editItem │ ├── autoform.js │ events.js │ ├── assistants .js └── templates.html events.js ├── helpers.js onDestroyed. js onRendered.js routers.js ├── styles.less └── templates.html
Nous développons également avec WebStorm, un éditeur extrêmement puissant et flexible pour le développement de Meteor. Nous trouvons cela extrêmement utile pour rechercher et organiser notre code et pour travailler de manière productive. 
Heureux de partager des détails sur demande.
Après un moment de programmation par meteorjs, je suis heureux de pouvoir consacrer du temps libre à la création d’un jeu en ligne assez complexe. La structure des applications a été l'une de mes premières préoccupations, et il semble que plusieurs très bons programmeurs aient défendu la méthode de paquetage uniquement pour structurer une application, ce qui vous permet de coupler de manière lâche des paquets fonctionnellement distincts. Cette approche présente d’autres avantages. Vous trouverez ici deux très bons articles expliquant cette approche:
http://www.matb33.me/2013/09/05/meteor-project-structure.htmlhttp://www.manuel-schoebel.com/blog/meteorjs- package-only-app-structure-with-mediator-pattern
Utilisez l’échafaudage CLI. Cela rend les choses très faciles.
https://github.com/iron-meteor/iron-cli
une fois installé. utilisation iron create my-app pour créer un nouveau projet. Il va créer la structure suivante pour vous. Vous pouvez également l'utiliser sur des projets existants. utilisation iron migrate dans le répertoire du projet.
my-app/
.iron/
config.json
bin/
build/
config/
development/
env.sh
settings.json
app/
client/
collections/
lib/
stylesheets/
templates/
head.html
lib/
collections/
controllers/
methods.js
routes.js
packages/
private/
public/
server/
collections/
controllers/
lib/
methods.js
publish.js
bootstrap.js
Je suis le format passe-partout mattdeom, qui inclut déjà le routeur et le modèle de fer (Collection2). Voir ci-dessous :
client/ # Client folder
compatibility/ # Libraries which create a global variable
config/ # Configuration files (on the client)
lib/ # Library files that get executed first
startup/ # Javascript files on Meteor.startup()
stylesheets # LESS files
modules/ # Meant for components, such as form and more(*)
views/ # Contains all views(*)
common/ # General purpose html templates
model/ # Model files, for each Meteor.Collection(*)
private/ # Private files
public/ # Public files
routes/ # All routes(*)
server/ # Server folder
fixtures/ # Meteor.Collection fixtures defined
lib/ # Server side library folder
publications/ # Collection publications(*)
startup/ # On server startup
meteor-boilerplate # Command line tool
Il y a une nouvelle classe sur Evented Mind appelée Configuration de projets Meteor qui traite de cette question mais aussi de la configuration de projet et de la configuration de votre environnement de développement.
De la vidéo Structure de l'application dans la classe: Meteor n'a pas une opinion très arrêtée sur la structure de votre application, mais voici quelques règles:
1) Ordre de chargement - Meteor va d'abord à l'emplacement le plus profond du répertoire de fichiers et traite les fichiers dans l'ordre alphabétique.
2) le client et le serveur sont des dossiers spéciaux que Meteor reconnaît
Notre structure ressemble à ceci:
both/
collections/
todos.js
controllers/
todos_controller.js
views/
todos.css
todos.html
todos.js
app.js - includes routes
client/
collections/
views/
app.js
server/
collections/
views/
app.js
packages/
public/
Todos_controller étend RouteController, fourni avec Iron Router.
L’outil em mentionné ci-dessus fait également l’objet d’une mise à jour importante et devrait être bien meilleur et disponible à l’adresse suivante: https://github.com/EventedMind/em
Il existe de nombreuses approches différentes pour structurer votre application. Par exemple, si vous avez un routeur et différents modèles de page, et que chaque modèle de page contient plusieurs parties de page, etc., je structurerais la structure en fonction de la sémantique de niveau supérieur> inférieur.
Par exemple:
client
views
common
header
header.html
header.js
header.css
footer
footer.html
footer.js
footer.css
pages
mainPage
mainPage.html
mainPage.js
mainPage.css
articles
articles.html
articles.js
articles.css
news
news.html
news.js
news.css
...
Bien sûr, vous pouvez placer vos modèles de news dans le dossier commun, de la même manière que vous pouvez utiliser votre modèle de news sur différentes pages.
Je pense que c'est mieux de structurer votre application d'une manière qui vous convient le mieux.
J'ai écrit une petite application ici: http://gold.meteor.com Et c'est tellement petit que je n'utilise qu'un fichier html et un seul fichier template.js .. :)
J'espère que ça aide un peu
Je recherche également les meilleures pratiques pour améliorer et adapter mes applications à travers une architecture bien conçue. Toutes les pratiques mentionnées ci-dessus fonctionnent pour des applications de taille petite à moyenne, mais elles échoueront si vous travaillez dans une équipe plus grande. J'ai essayé de plusieurs manières:
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 sur la conception des composants et des champs. Je suis en train de l'implémenter car la communauté a développé 36 paquets qui couvrent presque tous les cas et je peux utiliser TypeScript pour être sûr de taper 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. C'est un paquet écrit en script de café appelé. Les composants Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) de Meteor sont un système permettant de développer facilement des éléments d'interface utilisateur complexes devant être réutilisés autour de votre application Meteor. Vous pouvez les utiliser dans CoffeeScript, Vanilla JavaScript et ES6. La meilleure chose à faire est que les composants sont OOP. Voici l'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 caractères et le transpiler qui me disent où et quand quelque chose va mal se passer. 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 tenté de mettre en œuvre 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 ni développé activement.
4) et je pense que cela a déjà été mentionné, vous pouvez évoluer en utilisant des 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 divers moyens de copier des aides de modèles, des gestionnaires d'événements et des points d'ancrage entre les modèles, permettant ainsi la réutilisation du code; un inconvénient est que toute la copie doit être confiée à un développeur, souvent encore et encore, ce qui devient problématique à mesure que la base de code se développe; de plus, sans communauté d'API clairement définie, il est impossible de construire et de partager des composants
6) Composants de flux - Les composants de flux sont plus proches de React dans la conception de l'API alors que Blaze Components conservent des concepts familiers tels que les contextes de données et le modèle D'autre part, Flow Components utilise toujours des gestionnaires d'événements basés sur des modèles alors que Blaze Components en fait des méthodes de classe pour faciliter leur extension ou leur redéfinition par héritage; en général, Blaze Components semble être plus OOP Les composants de Flow ne sont pas encore officiellement publiés ( crédits de texte pour les # 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 complète de TypeScript, ce qui est un avantage considérable lorsque vous développez en équipe avec une documentation médiocre. Cependant, je porte actuellement le numéro deux sur TypeScript parce que je me sens très à l'aise avec ce logiciel et que 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 le bon moyen de travailler avec Meteor. Vous devez le savoir vous-même, sinon vous aurez une structure de dossiers bien organisée, mais vous ne savez pas où tout se trouve. Bonne codage.