Buscar..
Introducción
Antes del lanzamiento de Meteor 1.3, los desarrolladores de Meteor estaban frustrados con el manejo de las dependencias de archivos y las variables globales de Meteor.js. En respuesta, Meteor estableció nuevos estándares para las estructuras del proyecto con el fin de hacer que el sistema de dependencia del proyecto sea más ágil. Este tema explica la estructura estandarizada del proyecto y los principios que la sustentan.
Observaciones
cliente
Todo el código en el directorio del cliente se ejecuta solo en el lado del cliente o en el navegador web.
cliente / compatibilidad
El directorio de compatibilidad contiene códigos heredados o de terceros, como las bibliotecas jQuery, etc.
lib
El directorio lib se carga antes que otros directorios en su proyecto Meteor, y se carga tanto en el servidor como en el cliente. Este es el lugar preferido para definir modelos de datos, bibliotecas isomorfas y lógica empresarial.
importaciones
El directorio de importaciones es un directorio en el servidor que está disponible tanto para el servidor como para el cliente, pero solo antes de que el paquete del cliente se envíe al cliente.
paquetes
El directorio de paquetes es donde los paquetes personalizados se almacenan durante el desarrollo local. Al usar el comando estándar meteor add package:name para agregar un paquete, Meteor buscará primero en este directorio si un paquete local tiene el nombre de descripción correspondiente en su archivo package.js . Si no, sondeará Atmosphere como de costumbre.
privado
El directorio privado contiene archivos estáticos que solo deberían estar disponibles en el servidor web.
público
El directorio público contiene archivos estáticos que solo están disponibles en el cliente de la aplicación. Esto puede incluir activos de marca, etc.
servidor
El directorio del servidor contiene activos del lado del servidor. Esto puede incluir lógica de autenticación, métodos y otros códigos que pueden necesitar consideración de seguridad.
pruebas
El directorio de pruebas se omite de forma predeterminada cuando su aplicación está empaquetada y desplegada.
Como sugirió Richard Silverton , es una idea conveniente poner no solo el directorio del proyecto meteorito bajo el control de versiones, sino también su directorio principal.
De esa manera, puede mantener los archivos bajo el control de versiones sin tener que tratar con meteoros.
Directorio clásico de estructuras
Lo primero que debe saber al estructurar sus aplicaciones es que la herramienta Meteor tiene algunos directorios que están codificados con lógica específica. En un nivel muy básico, los siguientes directorios están "integrados" en el agrupador 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)
Página de referencia: Guía de meteoros> Directorios especiales
Estructura de directorio solo para paquetes
Muchas personas finalmente se encuentran admitiendo múltiples aplicaciones y desean compartir código entre aplicaciones. Esto lleva al concepto de arquitectura de microservicio y aplicaciones de paquete completo. Esencialmente, el código de toda la estructura clásica de directorios se redacta en paquetes.
Aunque no existe una lógica codificada para los directorios en los paquetes, encontramos que es una buena práctica usar la estructura clásica de directorios al crear paquetes. Esto crea una ruta de refactor natural a medida que las funciones se crean prototipos en la aplicación y luego se extraen en paquetes para publicar y compartir. Los nombres de los directorios se comparten, por lo que hay menos confusión entre los miembros del equipo.
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
Importaciones / Módulos de Estructura de Directorio
Las versiones más recientes de Meteor se envían con soporte para ecmascript , también conocido como ES6 o ES2015. En lugar de paquetes, Javascript ahora admite instrucciones y módulos de import , lo que reemplaza la necesidad de aplicaciones de solo paquete. La última estructura de directorios es similar a la estructura de solo paquetes, pero usa el directorio /imports lugar de /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Estructura de directorio en modo mixto
Y, por supuesto, puede combinar estos enfoques y utilizar tanto paquetes como importaciones junto con el código específico de su aplicación. Una estructura de modo mixto es más común en tres situaciones: una aplicación de franken, que es simplemente un poco extraña de aquí y allá sin ninguna estrategia general; una aplicación que se está refaccionando activamente desde las estructuras clásicas o de solo paquete a la estructura de Importaciones / Módulos.
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)
Orden de carga del directorio
Los archivos de plantillas HTML siempre se cargan antes que todo lo demás.
Archivos que comienzan con main. se cargan el último
Los archivos dentro de cualquier directorio lib / se cargan a continuación
Los archivos con rutas más profundas se cargan a continuación
Los archivos se cargan en orden alfabético de la ruta completa
Página de referencia: Guía de meteoritos> Estructura de la aplicación> Orden de carga de archivos predeterminado
