Recherche…
Introduction
Avant la publication de Meteor 1.3, les développeurs de Meteor étaient frustrés par la gestion des dépendances de fichiers et des variables globales par Meteor.js. En réponse, Meteor a établi de nouvelles normes pour les structures de projet afin de simplifier le système de dépendance du projet. Ce sujet explique la structure de projet standardisée et les principes sous-jacents.
Remarques
client
Tout le code du répertoire client est exécuté uniquement du côté client ou du navigateur Web.
client / compatibilité
Le répertoire de compatibilité contient du code hérité ou tiers, tel que les bibliothèques jQuery, etc.
lib
Le répertoire lib est chargé avant les autres répertoires de votre projet Meteor et est chargé à la fois sur le serveur et sur le client. C'est l'endroit préféré pour définir des modèles de données, des bibliothèques isomorphes et une logique métier.
importations
Le répertoire imports est un répertoire disponible sur le serveur, à la fois pour le serveur et pour le client, mais uniquement avant l'expédition de l'ensemble client au client.
paquets
Le répertoire des packages est l'endroit où les packages personnalisés sont stockés lors du développement local. Lorsque vous utilisez la commande standard meteor add package:name pour ajouter un paquet, Meteor va d'abord regarder dans ce répertoire si un paquet local a le nom de description correspondant dans son fichier package.js . Si ce n'est pas le cas, il interrogera l'atmosphère comme d'habitude.
privé
Le répertoire privé contient des fichiers statiques qui ne doivent être disponibles que sur le serveur Web.
Publique
Le répertoire public contient des fichiers statiques uniquement disponibles sur le client d'application. Cela peut inclure des actifs de marque, etc.
serveur
Le répertoire du serveur contient des ressources côté serveur. Cela peut inclure la logique d'authentification, les méthodes et d'autres codes pouvant nécessiter des considérations de sécurité.
des tests
Le répertoire de tests est omis par défaut lorsque votre application est regroupée et déployée.
Comme suggéré par Richard Silverton, il est judicieux de placer non seulement le répertoire du projet meteor sous contrôle de version, mais aussi son répertoire parent.
De cette façon, vous pouvez garder les fichiers sous contrôle de version sans avoir la météorite pour les gérer.
Structures de répertoire classiques
La première chose que vous devez savoir lors de la structuration de vos applications est que l'outil Meteor contient des répertoires codés en dur avec une logique spécifique. À un niveau très basique, les répertoires suivants sont "intégrés" dans le bundle Meteor.
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports/ # for lazy loading feature
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
Page de référence: Meteor Guide> Répertoires spéciaux
Structure de répertoire uniquement pour les packages
De nombreuses personnes se retrouvent finalement à prendre en charge plusieurs applications et souhaitent partager du code entre les applications. Cela conduit au concept d'architecture de microservices et d'applications tout-en-un. Essentiellement, le code de l’ensemble de la structure de répertoire classique est transformé en packages.
Même s'il n'y a pas de logique codée en dur pour les répertoires dans les packages, nous trouvons qu'il est recommandé d'utiliser la structure de répertoires classique lors de la création de packages. Cela crée un chemin de refactorisation naturel car les entités sont prototypées dans l'application, puis extraites dans des packages à publier et à partager. Les noms de répertoire sont partagés, il y a donc moins de confusion parmi les membres de l'équipe.
client/ # client application code
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
server/ # server code
Structure du répertoire des importations / modules
Les versions les plus récentes de Meteor sont compatibles avec ecmascript , alias ES6 ou ES2015. Au lieu de paquets, Javascript prend désormais en charge import instructions et les modules d’ import , ce qui remplace le besoin d’applications uniquement par package. La structure de répertoire la plus récente est similaire à celle du package, mais utilise le répertoire /imports au lieu de /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Structure de répertoire en mode mixte
Et, bien sûr, vous pouvez combiner ces approches et utiliser les packages et les importations parallèlement au code spécifique à votre application. Une structure en mode de mixage est la plus courante dans trois situations: une application franken, qui consiste simplement à tirer un peu de l’extérieur sans stratégie globale; une application activement restructurée, des structures Classic ou Package-Only à la structure Imports / Modules.
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
Ordre de chargement du répertoire
Les fichiers de modèles HTML sont toujours chargés avant tout le reste
Fichiers commençant par main. sont chargés en dernier
Les fichiers à l'intérieur d'un répertoire lib / sont chargés ensuite
Les fichiers avec des chemins plus profonds sont chargés ensuite
Les fichiers sont ensuite chargés par ordre alphabétique du chemin complet
Page de référence: Meteor Guide> Structure de l'application> Ordre de chargement des fichiers par défaut
