react - ¿Cuáles son las mejores prácticas para estructurar una gran aplicación Meteor con muchos archivos de plantilla HTML?
meteor tutorial (14)
En todos los ejemplos (leaderboard, juegos de palabras, etc.) tienen un solo archivo de plantilla HTML. ¿Existe algún gran proyecto Meteor de código abierto con muchos archivos de plantilla HTML diferentes que podamos utilizar como ejemplo de las mejores prácticas? No parece práctico poner todo lo que necesita una aplicación grande, todo en un solo archivo de plantilla.
Crear paquetes
Por supuesto, no todo encaja en este enfoque, pero en las aplicaciones grandes tendrás muchas funcionalidades que pueden aislarse. Cualquier cosa separable y reutilizable cabe en paquetes, el resto va en la estructura de directorio habitual, como se menciona en otras respuestas. Incluso si no hace paquetes para evitar la sobrecarga, es una buena idea estructurar el código de manera modular (vea estas sugerencias )
Meteor permite un control detallado sobre cómo cargar sus archivos (orden de carga, donde: cliente / servidor / ambos) y qué exporta el paquete.
Especialmente encuentro muy útil la manera fácil de compartir la lógica entre los archivos relacionados. Digamos, por ejemplo, que quieres hacer alguna función de utilidad y usarla en diferentes archivos. Simplemente lo convierte en "global" (sin var ) y Meteor lo ajustará en el espacio de nombres del paquete, por lo que no contaminará el espacio de nombres global.
Here está el documento oficial
¡Lump todo junto! De los documentos:
> 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.
Como en el faq de meteoros no oficial, creo que explica cómo estructurar una aplicación grande:
¿Dónde debería poner mis archivos?
Las aplicaciones de ejemplo en meteoros son muy simples y no brindan mucha información. Aquí está mi pensamiento actual sobre la mejor manera de hacerlo: (¡cualquier sugerencia / mejora es bienvenida!)
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)Para aplicaciones más grandes, la funcionalidad discreta se puede dividir en subdirectorios organizados con el mismo patrón. La idea aquí es que, finalmente, el módulo de funcionalidad se podría descomponer en un paquete inteligente separado, e idealmente, compartirlo.
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
Averigüe más: Preguntas frecuentes sobre Meteor No oficial
Creo que la estructura de archivos de Discover Meteor Book es realmente buena y un comienzo sólido.
/app:
/client
main.html
main.js
/server
/public
/lib
/collections
- El código en el directorio / server solo se ejecuta en el servidor.
- El código en el directorio / client solo se ejecuta en el cliente.
- Todo lo demás se ejecuta tanto en el cliente como en el servidor.
- Los archivos en / lib se cargan antes que cualquier otra cosa.
- Cualquier archivo main. * Se carga después de todo lo demás.
- Sus activos estáticos (fuentes, imágenes, etc.) van en el directorio / public.
Después de un tiempo fuera de la codificación meteorits, estoy feliz de tener algo de tiempo libre para dedicarme a construir un juego en línea bastante complejo. La estructura de la aplicación ha sido una de mis primeras preocupaciones, y parece que varios programadores muy buenos han defendido el método de solo paquete de estructurar una aplicación, que le permite acoplar libremente paquetes funcionalmente distintos. Hay otras ventajas para el enfoque, y 2 muy buenos artículos que explican el enfoque se pueden encontrar aquí:
matb33.me/2013/09/05/meteor-project-structure.html http://www.manuel-schoebel.com/blog/meteorjs-package-only-app-structure-with-mediator-pattern
Estoy de acuerdo con yagooar, pero en lugar de:
client/application.js
Utilizar:
client/main.js
los archivos main. * se cargan al último. Esto ayudará a garantizar que no tenga problemas con la carga. Consulte la documentación de Meteor, http://docs.meteor.com/#structuringyourapp , para obtener más detalles.
Estoy siguiendo el formato estándar de mattdeom, que ya incluye el enrutador y el modelo de hierro (Collection2). Vea abajo :
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
Hay muchos enfoques diferentes para estructurar su aplicación. Por ejemplo, si tiene un enrutador y diferentes plantillas de página, e internamente cada plantilla de página tiene muchas partes de página y así sucesivamente, lo estructuraría dependiendo de la semántica desde un nivel superior> inferior ...
Por ejemplo:
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
...
Por supuesto, podría poner sus plantillas de noticias en la carpeta común, ya que podría usar su plantilla de noticias en diferentes páginas.
Creo que es lo mejor que estructuras tu aplicación de forma que te sientas cómodo.
Escribí una pequeña aplicación aquí: http://gold.meteor.com Y es muy pequeña, uso solo un archivo html y solo un archivo template.js ... :)
Espero que ayude un poco
Hay una nueva clase en Evented Mind, llamada Configuración de proyectos de meteoritos, que trata sobre esto pero también habla sobre la configuración del proyecto y la configuración de su entorno de desarrollo.
Desde el video de Estructura de la aplicación en la clase: Meteor no tiene una opinión muy fuerte sobre cómo debe estructurarse su aplicación, pero aquí hay algunas reglas:
1) Orden de carga: Meteor va primero a la ubicación más profunda en el directorio de archivos y procesa los archivos en orden alfabético
2) el cliente y el servidor son carpetas especiales que Meteor reconoce
Nuestra estructura se ve así:
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 extiende RouteController, algo que viene con Iron Router.
La herramienta em mencionada anteriormente también está recibiendo una gran actualización en este momento y debería ser mucho mejor y estar disponible en: https://github.com/EventedMind/em
Meteor fue diseñado para que usted pueda estructurar su aplicación de la forma que desee. Entonces, si no le gusta su estructura, puede mover un archivo a un nuevo directorio, o incluso dividir un archivo en muchas partes, y para Meteor es prácticamente igual. Solo tenga en cuenta el tratamiento especial de los directorios de clientes, servidores y públicos como se especifica en la página de documentación principal: http://docs.meteor.com/ .
Solo agrupar todo en un solo HTML no surgirá como una mejor práctica.
Aquí hay un ejemplo de una estructura posible: en una de mis aplicaciones, un foro de discusión, organizo por módulo o "tipo de página" (casa, foro, tema, comentario), poniendo archivos .css, .html y .js para cada uno tipo de página juntos en un directorio. También tengo un módulo "base", que contiene el código .css y .js común y la plantilla maestra, que usa {{renderPage}} para representar uno de los otros módulos dependiendo del enrutador.
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
También puedes organizar por función
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
Sin embargo, espero que surjan algunas mejores prácticas específicas y convenciones de nombres.
Para todos los que buscan en Google sobre este tema:
La herramienta de línea de comando em (por EventedMind, los tipos detrás del Enrutador de Hierro) es muy útil al manipular una nueva aplicación Meteor. Creará una bonita estructura de archivo / carpeta. Si ya trabajas en una aplicación y quieres reorganizarla, simplemente configura un nuevo proyecto con em y puedes usarlo como inspiración.
Ver: https://github.com/EventedMind/em
Y aquí: https://.com/questions/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js
También estoy buscando las mejores prácticas para mejorar y escalar mis aplicaciones a través de una arquitectura bien concebida. Todas las prácticas mencionadas anteriormente funcionan para aplicaciones de tamaño pequeño a mediano pero fallarán cuando trabajes en un equipo más grande. Hay varias maneras en que he intentado:
1) Seguí esta estrategia: https://github.com/aldeed/meteor-autoform para escalar y reutilizar plantillas. El autor tiene una muy buena idea sobre el diseño de componentes y campos. Actualmente lo estoy implementando porque la comunidad desarrolló 36 paquetes que cubren casi todos los casos y puedo usar TypeScript para escribir con seguridad durante la fase de desarrollo.
<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>
Aquí hay una buena publicación de blog sobre cómo hacerlo: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ y también aquí: http://meteorpedia.com/read/Blaze_Notes
2) Este se ve muy prometedor pero no ha sido actualizado últimamente. Es un paquete escrito en un script de café llamado. Blaze Components ( https://github.com/peerlibrary/meteor-blaze-components ) para Meteor es un sistema para el desarrollo fácil de elementos de IU complejos que deben reutilizarse en su aplicación Meteor. Puede usarlos en CoffeeScript, JavaScript vainilla y ES6. Lo mejor es que los componentes son OOP. Aquí está uno de sus ejemplos:
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) Me gustan los tipos y el transpiler que me dicen dónde y cuándo algo saldrá mal. Estoy usando TypeScript para trabajar con Meteor y encontré el siguiente repositorio: https://github.com/dataflows/meteor-typescript-utils Parece que el creador trató de lograr un enfoque 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>
Desafortunadamente, este proyecto no se mantiene ni se desarrolla activamente.
4) y creo que ya se mencionó, puedes escalar utilizando paquetes. Eso requiere una buena forma abstracta de pensar. Parece que funciona para Telescope: https://github.com/TelescopeJS/Telescope
5) meteor-template-extension : proporciona varias formas de copiar ayudantes de plantillas, manejadores de eventos y ganchos entre plantillas, permitiendo la reutilización del código; un inconveniente es que todo el copiado debe ser atendido por un desarrollador, a menudo una y otra vez, lo que se vuelve problemático a medida que crece la base de código; además, sin una comunidad API claramente definida no puede construir y compartir componentes
6) Componentes de flujo: los componentes de flujo están más cerca de reaccionar en el diseño de API, mientras que los componentes de Blaze mantienen conceptos familiares como contextos de datos y ayudantes de plantilla; Flow Components, por otro lado, aún usa manejadores de eventos basados en plantillas, mientras que los Blaze Components los convierten en métodos de clase, por lo que es más fácil extenderlos o anularlos a través de la herencia; en general Blaze Components parece estar más orientada a OOP; Flow Components aún no se han lanzado oficialmente ( créditos de texto para # 5 y # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
Los números 2 y 3 también necesitan algo de uso, pero ganarás velocidad de desarrollo con el tiempo. El número cuatro le permite construir y probar componentes para hacer que su código sea más estable. El número tres viene con la ventaja de la seguridad de tipo completo de Typescript, que es una gran ventaja cuando se desarrolla en un equipo con poca documentación. Sin embargo, actualmente estoy transfiriendo el número dos a TypeScript porque me siento muy cómodo trabajando con él y no tengo que manipular el paquete del compilador para que funcione con Meteor cuando no estoy usando Gulp.
Todavía es difícil encontrar la forma correcta de trabajar con Meteor. Tienes que resolverlo por ti mismo, de lo contrario terminas con una estructura de carpetas muy bien organizada, pero no tienes ni idea de dónde está todo. Feliz codificación.
Tenemos un proyecto grande (probablemente uno de los proyectos Meteor más grandes que se haya construido hasta la fecha, ya que se desarrolló en tiempo completo durante 1,5 años). Usamos el mismo conjunto de nombres de archivo en cada vista. Es muy consistente y nos ayuda a navegar rápidamente a exactamente lo que estamos buscando:
- events.js
- helpers.js
- templates.html
- routes.js
- styles.less
- etc.
Se ve así en un proyecto:
├── consolidationRequests │ ├── events.js │ ├── helpers.js │ ├── routers.js │ └── templates.html ├── customerSpoof │ └── routers.js ├── dashboard │ ├── events.js │ ├── helpers.js │ ├── onDestroyed.js │ ├── onRendered.js │ ├── routers.js │ └── templates.html ├── emailVerification │ ├── events.js │ ├── helpers.js │ ├── routers.js │ └── templates.html ├── loading │ ├── styles.css │ └── templates.html ├── mailbox │ ├── autoform.js │ ├── consolidationRequestConfirmation │ │ ├── events.js │ │ ├── helpers.js │ │ ├── onCreated.js │ │ ├── onRendered.js │ │ └── templates.html │ ├── events.js │ ├── helpers.js
Las plantillas relacionadas solo se almacenan juntas en el mismo archivo. El contenido de view/order/checkout/templates.html muestra colapsó aquí:
<template name="orderCheckout"></template>
<template name="paymentPanel"></template>
<template name="orderCheckoutSummary"></template>
<template name="paypalReturnOrderCheckout"></template>
Usamos subcarpetas cuando las vistas se vuelven complejas con muchas partes:
├── cart │ ├── addItem │ │ ├── autoform.js │ │ ├── events.js │ │ ├── helpers.js │ │ ├── onRendered.js │ │ ├── routers.js │ │ ├── styles.less │ │ └── templates.html │ ├── checkout │ │ ├── autoform.js │ │ ├── events.js │ │ ├── helpers.js │ │ ├── onRendered.js │ │ ├── routers.js │ │ └── templates.html │ └── view │ ├── autoform.js │ ├── deleteItem │ │ ├── events.js │ │ ├── helpers.js │ │ └── templates.html │ ├── editItem │ │ ├── autoform.js │ │ ├── events.js │ │ ├── helpers.js │ │ └── templates.html │ ├── events.js │ ├── helpers.js │ ├── onDestroyed.js │ ├── onRendered.js │ ├── routers.js │ ├── styles.less │ └── templates.html
También desarrollamos con WebStorm, un editor extremadamente potente y flexible para el desarrollo de Meteor. Nos resulta inmensamente útil cuando buscamos y organizamos nuestro código y trabajamos productivamente.
Feliz de compartir detalles bajo petición.
Use la CLI de andamios iron-cli. Hace las cosas muy fáciles.
github.com/iron-meteor/iron-cli
una vez instalada. use iron create my-app para crear un nuevo proyecto. Creará la siguiente estructura para ti. También puede usar esto en proyectos existentes. use iron migrate en el directorio del proyecto.
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