Guide du développeur pour améliorer la structure du projet dans les applications Meteor

Au cours des dernières années, le nombre de frameworks JavaScript disponibles a considérablement augmenté. Allant de l'AngularJS éprouvé à la vingtaine de frameworks qui sortent chaque mois, il existe une diversité impressionnante parmi laquelle choisir. Celui qui a attiré mon attention il y a quelques années est un framework appelé Meteor. Contrairement à la plupart des frameworks, Meteor vise à être une plate-forme complète pour le développement d'applications JavaScript. Pour ceux qui découvrent Meteor, je vous encourage à le consulter sur leur site Web. Cet article ne sera pas une introduction à Meteor. Au lieu de cela, nous explorerons quelques moyens simples d'introduire une structure dans les projets Meteor.

L'un des grands avantages de Meteor est qu'il est très facile de prototyper rapidement des applications JavaScript complexes avec lui. Parce que Meteor est un hybride de modèles frontaux et de rendu couplé à un serveur basé sur Node interagissant avec MongoDB (une solution unifiée), la plupart de la configuration initiale nécessaire à la création d'une application Web complète est déjà effectuée pour vous. Cependant, la facilité de développement que cela procure peut être un piège. Il est facile de tomber dans de mauvaises pratiques et de se retrouver avec un fouillis de code non structuré lors de la création d'une application Meteor. J'ai quelques suggestions pour éviter cela.

Échafaudage : hiérarchie de répertoires gérable dans Meteor

Tout d'abord, il est important de conserver la structure de dossiers recommandée lors de la création de votre application. Meteor vous permet de placer des fichiers n'importe où dans le dossier du projet par défaut - vous pouvez même avoir tout votre code dans un seul fichier si vous le souhaitez. Bien que cela puisse fonctionner pour un projet de hackathon, la complexité induite par les applications évolutives habituelles au niveau de la production est difficile à gérer sans une structure solide.

Afin de résoudre ce problème, je vous recommande de consulter le paquet iron npm de Chris Mather. Le package a une variété d'options de configuration, il sera donc difficile de le décrire ici, mais en général, il construit une structure de projet qui ressemblera à ceci :

 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/ |- lib |- methods.js |- publish.js |- bootstrap.js

Cependant, pour certains projets, une structure de dossiers et de fichiers comme celle-ci peut être exagérée. Tous les projets n'auront pas besoin d'avoir ce niveau d'organisation précis, avec des séparations pour les collections, les méthodes et le code de publication sur le serveur. Pour ceux qui n'ont pas un projet trop volumineux ou qui ne veulent tout simplement pas avoir à installer et à apprendre un autre package npm, je recommande cette structure de dossiers de base :

Les éléments clés sont un dossier public qui contient des fichiers tels que votre favicon et d'autres actifs statiques, ainsi que les dossiers client, commun et serveur. Les dossiers client et serveur doivent (bien sûr) contenir du code exécuté respectivement sur le client et le serveur. Le dossier commun contient du code qui doit être accessible à la fois au client et au serveur. Un exemple de ceci est le code de schéma, dont nous parlerons un peu.

Il existe deux manières d'effectuer le niveau d'organisation le plus bas : l'une par type de fichier et la seconde par fonction. L'organisation par type de fichier signifie que dans votre dossier client/templates, par exemple, vous aurez trois dossiers - un pour les fichiers JavaScript, un pour CSS et un pour HTML. Le dossier HTML contiendra tous vos fichiers HTML de modèle, par exemple Login.html, Main.html, etc. Les dossiers JavaScript et CSS contiendront respectivement les fichiers de modèle de leur type. L'organisation par fonction, d'autre part, signifie l'organisation par le concept que les fichiers incarnent. Par exemple, dans client/templates, j'aurais un dossier "Login", avec tous les fichiers JavaScript, CSS et HTML associés au processus de connexion de l'application. Je préfère l'organisation par fonction car cela vous permet d'être plus clair sur l'endroit où vous pouvez trouver certains fichiers ou morceaux de code. Cependant, ce n'est pas purement noir et blanc, et la plupart des individus et des équipes ont trouvé un mélange de ces méthodes pour structurer leurs fichiers et dossiers.

Schéma : votre application en a besoin même si votre base de données ne l'est pas

Le deuxième type de structure dont j'aimerais discuter est associé à la base de données. Cet article suppose que vous utilisez MongoDB. Si vous ne l'êtes pas, les concepts s'appliqueront probablement toujours, mais pas les détails. Ceux qui utilisent MongoDB savent que cela permet de déstructurer la façon dont nous stockons nos données. Étant donné que MongoDB est une base de données de magasin de documents NoSQL, il n'y a pas de schéma fixe pour aucun "type" de données. Cette liberté signifie que vous n'avez pas à vous soucier de vous assurer que tous les objets sont standardisés sous une forme rigide, en fait, toutes les données de votre application pourraient être jetées dans une seule collection si vous le souhaitez. Cependant, lorsqu'il s'agit de créer des applications de qualité de production, ce n'est pas vraiment aussi souhaitable. Afin de gérer cela et d'ajouter des fonctionnalités utiles telles que la validation des demandes d'écriture, nous pouvons nous tourner vers deux merveilleux packages Meteor : SimpleSchema et Collection2 d'Aldeed.

Le package SimpleSchema, comme son nom l'indique, vous permet de valider de manière réactive des objets dans votre application. Consultez la documentation sur GitHub. Le package Collection2 démarre à partir de SimpleSchema et vous permet d'apporter les schémas appropriés aux collections Meteor. Cela permet la validation automatique des demandes d'écriture côté client et côté serveur à toute collection avec un schéma qui lui est attaché. Ces deux packages sont très complets et personnalisables, il est donc difficile de les comprendre complètement en quelques paragraphes. Je vous recommande plutôt de consulter les fichiers readme détaillés qu'Aldeed a compilés pour les détails. Je vais simplement parler de la façon dont j'ai tiré parti de ces forfaits. L'une des meilleures choses qu'ils ont activées était la validation de l'entrée du formulaire de l'utilisateur. Ceci est pratique pour valider les documents Meteor User (du package Accounts). Par défaut, les utilisateurs de Meteor ont un schéma implicite étonnamment complexe. Voici une image d'une partie du code qu'Aldeed a eu la gentillesse de mettre à disposition :

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

C'est simplement le schéma de l'objet de profil de l'utilisateur. Tenter de valider tout l'objet User serait un gâchis sans un package spécialement conçu comme SimpleSchema . Bien que tous ces champs apparaissent facultatifs dans l'image, si vous vouliez un schéma utilisateur correctement validé, ils ne le seraient probablement pas, et des choses comme "Schema.UserCountry" redirigent en fait vers d'autres schémas pour validation. En attachant ce schéma à l'objet Utilisateur et en l'intégrant de manière réactive à nos formulaires, peut-être avec un package comme AutoForm d'Aldeed, nous pouvons acquérir un degré de contrôle précis sur ce qui entre et n'entre pas dans nos bases de données, économisant du temps et des efforts avec un modèle conceptuel de la façon dont les données sont traitées dans notre application qui peut être pointé et discuté en termes concrets.

Rôles : Pour les 401 et 403

La dernière suggestion que j'ai pour structurer et améliorer un projet Meteor est le paquet Rôles d'Alanning. Il s'agit d'un système d'autorisation pour Meteor, et il vous permet de vérifier les niveaux d'accès des utilisateurs pour n'importe quelle partie de votre application Web. Les autorisations sont attachées au profil de l'utilisateur sous la forme de chaînes qui sont ensuite validées ou invalidées lorsque l'utilisateur tente d'accéder à des méthodes ou données Meteor publiées sur le client. Par exemple:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

Bien que le cœur du système soit relativement simple, il permet des autorisations complexes et précises pour n'importe quelle partie de votre application. Étant donné que tous les rôles sont stockés sous forme de chaînes, vous pouvez configurer un système aussi profond que vous le souhaitez - "admin", "admin.division1.manage", "admin.division1.manage.group2", etc.

Le problème avec la liberté que ce paquet permet est qu'il peut être difficile de suivre un système de rôles très granulaire. Le package fournit des fonctions telles que "getAllRoles" qui, comme son nom l'indique, récupère tous les rôles que vous avez créés, mais c'est à vous de garder une trace de toutes leurs significations, et quand un rôle donné devrait être utilisé. Et pour ceux qui sont curieux de savoir quelle est la différence entre les «rôles» et les «autorisations», aux fins de ce package, ils ne sont essentiellement pas différents.

Emballer

Malheureusement, en raison de l'ampleur de l'article (chacun des packages mentionnés ici mérite son propre didacticiel), il n'a pas été possible d'entrer dans les détails d'un package particulier, mais j'espère vous avoir éclairé sur la manière dont vous pouvez travailler vers un " " L'application Meteor dont vous pouvez être sûr qu'elle fonctionnera bien en production et à grande échelle. Si vous recherchez plus d'informations, consultez les liens que j'ai publiés et jetez un œil à une autre chose qui n'a pas été ajoutée à cet article, mais qu'il est utile d'avoir dans une application Meteor : le package Restivus, qui vous permet pour exposer facilement une API REST pour votre application.

En tant que clause de non-responsabilité, je ne suis l'auteur d'aucun de ces packages, et je m'excuse si j'ai déformé l'une des fonctionnalités ou les objectifs d'un package. Merci d'avoir lu, et j'espère que cet article vous a été utile. N'hésitez pas à me contacter pour toute question que vous pourriez avoir, ou laissez un commentaire ci-dessous.