ventajas underscore tutorial software react ember desventajas backbone backbone.js javascript-framework

backbone.js - underscore - software backbone



¿Cuáles son las fortalezas y debilidades del mundo real de los muchos frameworks basados en backbone.js? (5)

Actualmente estoy utilizando la red troncal con el módulo de gestor de disposición y el manillar como motor de plantillas y me pareció realmente fácil configurar una pequeña aplicación utilizando un servidor de Grails ya existente. Antes de comenzar a usar el administrador de diseño, leí acerca de Marionette y Chaplin y ambos me parecieron realmente poderosos pero complejos. Entonces recordé por qué elegí originalmente backbone.js: simplicidad. Todos esos marcos están agregando lo que la red troncal ha dejado fuera por diseño. No digo que un framework sea malo, pero si necesito algo más complejo probaré otros proyectos, como ember.js o sproutcore, ya que tienen una base de código única, escrita con un objetivo en la mente de sus desarrolladores. Aquí tenemos frameworks encima de otro. Por supuesto, la red troncal es una columna vertebral no solo para crear aplicaciones, sino también para escribir una biblioteca más poderosa, pero lo único que creo que es realmente malo es la capa de vista, ya que falta un administrador de diseño y la posibilidad de anidar vistas . Con el administrador de diseño esa brecha se llena bastante bien.

Por lo tanto, mi respuesta a su pregunta es: empiece por usar la red troncal tal como está, y pregúntese qué es lo que falta y cuáles eran sus expectativas sobre el marco. Si observa que hay demasiadas cosas que quedan fuera de la red troncal, busque y busque en los otros marcos y elija el que esté más cerca de sus necesidades. Y si aún no tiene confianza en la elección, tal vez la red troncal no sea para usted y tenga que buscar otra solución (ember.js, sproutcore, ExtJs, JavaScript MVC son todos buenos). Si tiene experiencia en escribir aplicaciones cliente, realmente no necesita experiencia en todo el marco para elegir el correcto (para usted, por supuesto)

Espero que alguien pueda compartir su experiencia con algunas de las últimas variantes emergentes de backbone.js. Tengo una buena experiencia con backbone / underscore / require en varios proyectos y me gustaría dar el siguiente paso hacia soluciones más avanzadas para la estructura de aplicaciones complejas.

Sé que los siguientes marcos están disponibles:

Y probablemente me perdí algunos.

Hay una breve introducción sobre las diferencias aquí:

pero es muy general. Me preguntaba si alguien puede compartir su experiencia con aplicaciones de la vida real usando estos marcos.

¿Cuál es el beneficio de elegir uno sobre el otro? Cuándo será marionette una mejor solución que chaplin, o por qué los veteranos son mejores para ciertas aplicaciones, por ejemplo.

Claro, la respuesta obvia será " use cuál es la mejor para sus necesidades ", pero carezco de la experiencia con estos marcos para conocer su fortaleza / propósito / ventajas o escenarios preferidos.

¡Gracias!

Editar 1: encontró esta publicación: Backbone.Marionette vs Backbone-Boilerplate

Edición 2: Respuesta de Mathias schafer (Chaplin) por correo:

En resumen, la estructura actual está cerca de la versión 1.0 ya que ya se usa en producción. No estamos planeando agregar una nueva característica grande o interrumpir los cambios de la API hasta el 1.0.

Marionette es sin duda la biblioteca más completa y estable que hay. Aborda varios aspectos del desarrollo de aplicaciones JS con Backbone. Por ejemplo, tiene una capa de vista fuerte que Backbone deja completamente vacía. Por supuesto, encontrará que algunos de los aspectos no satisfarán sus demandas y podría sentir la necesidad de establecer una estructura alrededor de Marionette.

Por el contrario, Chaplin se centra en un aspecto bastante pequeño, pero muy importante de las aplicaciones de Backbone, a saber, la estructura general de la aplicación y el ciclo de vida del módulo. En este sentido, Chaplin es muy opuesto y se parece más a un marco que a una biblioteca (como en "tu código llama a una biblioteca, un marco llama a tu código"). Chaplin proporciona algunas clases centrales que se encuentran por encima de los módulos de aplicaciones individuales y controlan el estado general de la aplicación. Esto le da a su aplicación una estructura convencional como Ruby on Rails, por ejemplo.

En Chaplin, declaras algunas rutas que se asignan a los controladores, y Chaplin inicia el controlador una vez que la ruta coincide. También se ocupa de la eliminación de los controladores antiguos, y de mostrar y ocultar las vistas principales, que se supone que debe crear un controlador. Esta es la idea básica, pero Chaplin se ocupa de los detalles feos para que esto funcione sin problemas.

Hay dos principios que vienen con esta estructura: - Modularización, desacoplamiento y sandboxing - Comunicación entre módulos usando Publish / Subscribe y Mediator (s)

Por supuesto, estos patrones no son nuevos en el mundo del desarrollo de software, y Chaplin no es la única biblioteca que los aplica a las aplicaciones Backbone.js.

Chaplin también proporciona mejoras para la capa de visualización, por ejemplo, un CollectionView muy sofisticado, pero en total no tanto como Marionette con sus regiones y diseños. Pero es relativamente fácil escribir tales metaclases utilizando los medios que proporciona Chaplin Views.

Desarrollé el framework Luca mientras trabajaba en BenchPrep, donde lo usamos para desarrollar varias aplicaciones grandes de una página en la parte superior de la biblioteca backbone.js.

He trabajado con ExtJS durante varios años antes y he robado mis conceptos favoritos de ese marco, como la arquitectura impulsada por componentes, donde se desarrollan sus puntos de vista como componentes independientes y luego se unen a ellos junto con otros componentes utilizando vistas de contenedores. Y dado que se basa en gran medida en la configuración, desarrollar una aplicación en Luca se parece mucho a describir un objeto con JSON.

Una ventaja de este enfoque es la capacidad de reutilizar componentes en varias aplicaciones o en diferentes lugares de su aplicación, con solo cambios menores utilizando la extensión de Backbone. También es muy fácil experimentar con diferentes diseños / presentaciones de componentes haciendo solo pequeños ajustes a la configuración JSON.

Además de una amplia gama de funciones auxiliares / de utilidad, Luca se envía con muchos derivados Backbone de alto nivel que puedes unir de cualquier manera imaginable para construir una interfaz de usuario compleja.

Vistas, componentes, contenedores

  • Modelo aumentado, Vista, Colección, Clases de enrutador
  • Opciones de configuración que facilitan la comunicación entre Modelos, Colecciones, Vistas, la Aplicación y sus respectivos administradores.
  • Contenedores (diseño de división / columna, diseño de cuadrícula, vista de pestaña, vista de tarjeta / asistente)
  • FormView con todos los componentes de campo estándar y ayudantes para sincronizar con un Backbone.Model
  • GridView, para generar elementos de cuadrícula desplegables de un Luca.Collection
  • CollectionView, para generar vistas basadas en una colección
  • Barras de herramientas / botones

Estilos de Twitter Bootstrap y marcado gratis

  • Luca juega muy bien con el marco de arranque de Twitter. Simplemente configurando Luca.enableBootstrap = true e incluyendo el CSS, sus componentes (como las vistas de pestañas, barras de herramientas, botones, formularios, campos, cuadrículas, etc.) utilizarán automáticamente el marcado compatible con Twitter Bootstrap y las convenciones de la clase CSS.
  • Utiliza el sistema Grid para el diseño, y responde a la mayoría de las clases base de bootstrap css de una manera inteligente
  • Los componentes Luca.Viewport y GridLayout están configurados para funcionar con los sistemas de cuadrícula estáticos, fluidos o reactivos de bootstrap.
  • Tiene como objetivo proporcionar una coincidencia uno a uno para los componentes de arranque de twitter, para representarlos como vistas de Backbone configurables

El componente de la aplicación

  • La máquina de estado basada en Backbone.Model proporciona métodos getter / setter y eventos de cambio de atributos como un estilo de flujo de control de aplicaciones
  • Componente de controlador integrado que oculta / muestra páginas de la aplicación en respuesta a los eventos Backbone.Router o State Machine
  • Integrated Collection Manager que realiza un seguimiento de las colecciones que ha creado, le permite delimitarlas, agruparlas, asignarles parámetros predeterminados
  • Un administrador de socket que es una capa de abstracción sobre los servicios de websocket que hace que push sea tan fácil como Backbone.Event
  • Un enrutador de eventos de teclado que desencadena eventos clave con nombre en los componentes que se preocupan por responder a dichos eventos

Colección y mejoras del modelo

  • Las colecciones se basan en backbone-query , que proporciona una interfaz de consulta muy similar a mongoDb
  • habilitar un almacenamiento local Backbone.sync simplemente configurando collection.localStorage = true
  • población automática de colecciones cuyos datos están bootstrapped en la carga de la página
  • métodos almacenados en caché / propiedades calculadas. almacenar en caché el resultado de los métodos de recopilación y caducar el caché en respuesta a cambios / agregar / eliminar eventos en la colección o sus modelos
  • propiedades calculadas en los modelos. construir atributos basados ​​en funciones complejas, y actualizar automáticamente el valor calculado en respuesta a cambios

Eventos y ganchos

Los componentes de Luca son más liberales con los eventos que emiten en comparación con los componentes básicos de stock. Emitirán eventos como before: initialize, after: initialize, before: render, after: render, activation, first: activation, deactivation, first: deactivation, y esto le permite afinar más el comportamiento de sus componentes. Además, al definir un evento en la propiedad @hooks en su vista, automáticamente llamará una función con un nombre similar si existe. Esto evita una gran cantidad de código de estilo de devolución de llamada que mejora la legibilidad.

También puede configurar la clase Luca.Events para publicar los eventos en un canal de publicación / suscripción global, lo que facilita la creación de una aplicación grande y ayuda en la comunicación entre módulos.

La gema Ruby

Luca fue desarrollado específicamente mientras trabajaba con las API de Rails y Sinatra, y debido a esto, actualmente está optimizado para una pila específica, pero de ninguna manera lo encierra en un servidor específico.

Luca viene distribuido como parte de una gema de Ruby configurada para trabajar en la cartera de activos, o como un archivo descargable JS.

No está obligado a utilizar Rails o Sinatra. Pero si lo haces, he incluido muchas cosas útiles:

  • Los archivos con la extensión .luca se procesan como HAML con interpolación de variables de estilo JST. (equivalente a .jst.ejs.haml) por la canalización de activos
  • Un arnés de prueba para navegador, o pruebas de unidad basadas en jazmín sin cabeza junto con muchos ayudantes de prueba de Backbone y Underscore.
  • Un punto final API para el conjunto de herramientas de desarrollo que se incluye con Luca (más sobre esto más adelante)
  • Un punto final API que le permite usar Redis como un motor de almacenamiento sin esquema para Luca.Collection con una configuración mínima

Las herramientas de desarrollo

  • Las aplicaciones de Luca pueden habilitar una consola de coffeescript en el navegador con ayudantes específicos de Luca y comandos que ayudan a monitorear, inspeccionar y depurar aplicaciones y componentes de Luca.

  • Con la ayuda de Rails Gem y el editor de componentes basado en CodeMirror de Luca, puede editar el código fuente de Luca Framework y los componentes específicos de la aplicación directamente en el navegador, utilizando Coffeescript. Verá comentarios inmediatos en respuesta a sus ediciones, con las instancias de objetos afectados que se actualizan con el prototipo actualizado, y puede guardar los cambios en el disco.

  • El Component Tester es un sandbox en vivo para jugar con los componentes que componen su aplicación de forma aislada. Le proporciona herramientas para modificar el prototipo del componente, configurar sus dependencias y configurar el componente. El componente volverá a reproducirse inmediatamente cada vez que realice una edición. Puede ver y editar el marcado que genera el componente, así como el CSS directamente en el navegador y ver sus cambios de inmediato. Esto lo convierte en una herramienta de experimentación muy valiosa.

  • El Probador de componentes pronto se integrará con Jasmine para que pueda ver los resultados de las pruebas de su unidad de componentes en tiempo real mientras edita su código

Luca es un trabajo en progreso, pero mantiene una API estable (aún no 1.0) y se ha utilizado en varias aplicaciones de producción grandes. Definitivamente es un marco muy dogmático, pero estoy trabajando para hacerlo más modular. Estoy trabajando activamente en la documentación y los componentes de muestra.

Estudié la estructura de varios frameworks con Backbone.js y construí las vértebras para un proyecto en HauteLook. Los objetivos del proyecto incluían ... carga de scripts dinámicos, formato de módulo AMD, gestión de dependencias, construcción con bibliotecas en su mayoría de código abierto, organizar código en paquetes, optimizar y compilar para una o varias aplicaciones de una sola página, host en servidor completamente en caché, por ejemplo, ningún servidor Las secuencias de comandos en dos lados que usan solo una API para datos, y lo más divertido para mí, usan un desarrollo impulsado por el comportamiento para el proyecto. Hay una descripción del proyecto en: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Nuestro problema:

Las bibliotecas seleccionadas (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) proporcionan carga de módulos, administración de dependencias, estructura de aplicaciones (para modelos, colecciones, vistas y rutas), interacciones asíncronas con API, diversas utilidades y objetos para administrar comportamientos asincrónicos , por ejemplo, (Promesas) Deferreds, Callbacks. La lógica restante necesaria para completar el marco incluye:

  • un objeto (modelo) para administrar el estado de la aplicación de una sola página;
  • un administrador de diseño para presentar, organizar / transición y vistas claras, y
  • Controladores que responden a las rutas, obtienen / configuran el estado de la aplicación y transfieren el trabajo al administrador del diseño.

Nuestras soluciones (implementadas en vértebras):

Administrador de estado de la aplicación -

El administrador de aplicaciones almacena los datos en la memoria y también conserva los datos en el almacenamiento del navegador para proporcionar un recurso para datos / metadatos comunes. También proporciona datos (estado) para reconstruir las visitas de página en función de interacciones previas (por ejemplo, pestaña seleccionada, filtros aplicados). El administrador de estado de la aplicación proporciona una estrategia para que los recursos recuperen el estado. Significó actuar como una máquina de estado.

Administrador de diseño -

El administrador de disposición tiene una o varias vistas, así como también destinos de documentos (DOM) para cada vista (renderizada). Una página puede hacer una transición entre muchas vistas, por lo que el administrador de disposición realiza un seguimiento de los estados de vista, por ejemplo, renderizado, no renderizado, visualizado, no mostrado. Puede usar el administrador de diseño para cargar de forma diferida y representar (desconectadas) vistas que un visitante del sitio es muy probable que solicite, por ejemplo, cambios de pestaña en una página. La transición entre estados de vista es administrada por este objeto. Se puede borrar todo el diseño para que se eliminen los objetos de vista y sus enlaces, preparando estos objetos para la recolección de elementos no utilizados (evitando pérdidas de memoria). El administrador de disposición también comunica el estado de vista con los controladores.

Controlador -

La función de controlador de ruta llama a un objeto controlador y es responsable de obtener el estado relevante (modelos de aplicación) para generar una página (diseño), (también es responsable de establecer el estado cuando cambian las rutas). El controlador pasa datos dependientes (modelos / colecciones) y objetos de vista construidos para una página solicitada al administrador de disposición. Como efecto secundario, el uso de controladores evita que las rutas se hinchen y enreden. Una ruta debe asignarse a un controlador que luego inicia la vista de página, manteniendo las funciones de manejo de ruta escasas.

La aplicación Todos está alojada tanto en modo dev como optimizada en Heroku ...

Muchos de los conceptos en los otros marcos se toman prestados, por ejemplo, la necesidad de vistas adicionales para obtener una vista previa de las fugas de memoria como lo señala Derick Bailey - http://lostechies.com/derickbailey/ ; el Administrador de diseño por Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

En resumen, Backbone.js está destinado a ser una herramienta en su aplicación, la biblioteca Backbone.js no proporciona toda la arquitectura que necesitará para construir una aplicación, pero proporciona una gran interacción con una API y una estructura de código sólida para ... Vistas (también actúan como controladores) y su capa de datos Modelos y Colecciones, y finalmente Rutas. Construimos vértebras para satisfacer los objetivos de nuestro proyecto y decidimos extraer el código como un marco para que otros lo usen, aprendan o lo que sea.

La respuesta a su pregunta en mi opinión es aprender de todos los marcos y usar lo que necesita para alcanzar sus objetivos, si encuentra que los objetivos de su proyecto se ajustan estrechamente a uno de los frameworks construidos con Backbone, entonces genial, de lo contrario construirá su propio marco hay grandes ejemplos compartidos por la comunidad. O si te encuentras un poco perdido en la dirección de tu aplicación, entonces elige algo más obstinado y estructurado quizás Ember.js. Lo bueno es que hay una buena variedad de opciones para ayudarlo a codificar utilizando un patrón MVC (MVX) con JavaScript.

La mayoría de (todos?) Los marcos que estás viendo resuelven los mismos problemas, pero lo hacen de maneras ligeramente diferentes con objetivos ligeramente diferentes.

Creo que es justo decir que todos estos proyectos resolverían los problemas en estas categorías:

  • Proporcione un conjunto razonable de valores predeterminados
  • Reducir el código repetitivo
  • Proporcione la estructura de la aplicación en la parte superior de los bloques de construcción de BackboneJS
  • Extrae patrones que los autores usan en sus aplicaciones

Marionette, que he estado construyendo desde diciembre de 2011, también tiene algunos objetivos e ideales muy distintos en mente:

  • Arquitectura de aplicaciones compuestas
  • Influencia del patrón de mensajería empresarial
  • Opciones de modulación
  • Uso incremental (sin requisito de todo o nada)
  • Sin bloqueo de servidor
  • Facilite el cambio de los valores predeterminados
  • Código como configuración / sobre configuración

No digo que ninguno de los otros marcos tenga los mismos objetivos. Pero creo que la singularidad de Marionette proviene de la combinación de estos objetivos.

Arquitectura de aplicaciones compuestas

Pasé más de 5 años trabajando en sistemas de software distribuido de cliente grueso utilizando WinForms y C #. Creé aplicaciones para computadoras de escritorio, portátiles (smart-client), dispositivos móviles y aplicaciones web, todas ellas compartiendo un conjunto funcional básico y trabajando con el mismo back-end del servidor muchas veces. En este momento, aprendí el valor de la modularización y me desplacé rápidamente por un camino de diseño de aplicaciones compuestas.

La idea básica es "componer" la experiencia de tiempo de ejecución de su aplicación y procesar muchas piezas pequeñas e individuales que no necesariamente se conocen entre sí. Se registran en el sistema general de aplicaciones compuestas y luego se comunican a través de diversos medios de llamadas y mensajes desacoplados.

He escrito un poco sobre esto en mi blog, presentando a Marionette como una arquitectura de aplicaciones compuestas para Backbone:

Colas / patrones de mensajes

Los mismos sistemas distribuidos a gran escala también aprovecharon la puesta en cola de mensajes, los patrones de integración empresarial (patrones de mensajería) y los buses de servicio para manejar los mensajes. Esto, más que cualquier otra cosa, tuvo una influencia tremenda en mi enfoque del desarrollo de software desacoplado. Comencé a ver aplicaciones WinForms en un solo proceso y en memoria desde esta perspectiva, y pronto mi desarrollo del lado del servidor y de la aplicación web tomó influencia de esto.

Esto se ha traducido directamente en cómo veo el diseño de la aplicación Backbone. Proporciono un agregador de eventos en Marionette, tanto para el objeto de aplicación de alto nivel como para cada módulo que crea dentro de la aplicación.

Pienso en los mensajes que puedo enviar entre mis módulos: mensajes de comando, mensajes de eventos y más. También pienso en la comunicación del lado del servidor como mensajes con estos mismos patrones. Algunos de los patrones ya han llegado a Marionette, pero otros aún no.

Modularización

La modularización del código es tremendamente importante. Crear paquetes pequeños y bien encapsulados que tengan un enfoque singular con puntos de entrada y salida bien definidos es una necesidad para cualquier sistema de cualquier tamaño y complejidad significativos.

Marionette proporciona modularización directamente a través de sus definiciones de module . Pero también reconozco que algunas personas les gusta RequireJS y quieren usar eso. Así que proporciono una compilación estándar y una compilación compatible con RequireJS.

MyApp = new Backbone.Marionette.Application(); MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){ // your module code goes here });

(No hay una publicación de blog disponible para esto, aún)

Uso incremental

Esta es una de las filosofías centrales que preparo en cada parte de Marionette que puedo: ningún requisito de "todo o nada" para el uso de Marionette.

Backbone en sí tiene un enfoque muy incremental y modular con todos sus objetos de bloques de construcción. Usted es libre de elegir cuáles quiere usar, cuándo. Creo firmemente en este principio y me esfuerzo por asegurarme de que Marionette funcione de la misma manera.

Con ese fin, la mayoría de las piezas que he incorporado a Marionette están diseñadas para ser independientes, para trabajar con las piezas principales de Backbone y para trabajar juntas aún mejor.

Por ejemplo, casi todas las aplicaciones de Backbone deben mostrar dinámicamente una vista de Backbone en un lugar particular de la pantalla. Las aplicaciones también necesitan controlar el cierre de vistas antiguas y limpiar la memoria cuando se coloca una nueva. Aquí es donde entra la Region de Marionetas. Una región maneja el código repetitivo de tomar una vista, invocar el renderizado sobre ella y rellenar el resultado con el DOM por usted. Luego cerrará esa vista y la limpiará para usted, siempre que su vista tenga un método "cerrado".

MyApp.addRegions({ someRegion: "#some-div" }); MyApp.someRegion.show(new MyView());

Pero no es necesario que use las vistas de Marionette para usar una región. El único requisito es que se extienda desde Backbone.View en algún punto de la cadena de prototipos del objeto. Si elige proporcionar un método close , un método onShow u otros, Marionette''s Region lo llamará por usted en el momento adecuado.

Sin bloqueo de servidor

Construyo aplicaciones Backbone / Marionette sobre una amplia variedad de tecnologías de servidor:

  • ASP.NET MVC
  • Ruby on Rails
  • Ruby / Sinatra
  • NodeJS / ExpressJS
  • PHP / Slim
  • Java
  • Erlang
  • ... y más

JavaScript es JavaScript, cuando se trata de ejecutar en un navegador. JavaScript del lado del servidor también es impresionante, pero tiene cero efecto o influencia en la forma en que escribo mi navegador basado en JavaScript.

Debido a la diversidad de proyectos que construí y las tecnologías de back-end que usan mis clientes, no puedo y no bloquearé a Marionette en una sola pila de tecnología del lado del servidor por ningún motivo. No proporcionaré un proyecto repetitivo. No proporcionaré una gema ruby ​​o un paquete npm. Quiero que las personas entiendan que Marionette no requiere un servidor de fondo específico. Es un navegador basado en JavaScript, y el back-end no importa.

Por supuesto, apoyo totalmente a otras personas que proporcionan paquetes para su lenguaje y marco. Enumero esos paquetes en la Wiki y espero que la gente continúe compilando más paquetes a medida que vean una necesidad. Pero eso es apoyo de la comunidad, no apoyo directo de Marionette.

Cambie fácilmente los valores predeterminados

En mi esfuerzo por reducir el código repetitivo y proporcionar valores predeterminados razonables (que es una idea que "pedí prestada" directamente del LayoutManager de Tim Branyen), reconozco la necesidad de que otros desarrolladores utilicen implementaciones ligeramente diferentes a las que yo hago.

Ofrezco renderizado basado en etiquetas <script> en línea para plantillas, utilizando plantillas Underscore.js por defecto. Pero puede reemplazar esto al cambiar los objetos Renderer y / o TempalteCache en Marionette. Estos dos objetos proporcionan el núcleo de las capacidades de representación, y hay páginas wiki que muestran cómo cambiar esto para motores de plantillas específicos y diferentes formas de cargar plantillas.

Con v0.9 de Marionette, se vuelve aún más fácil. Por ejemplo, si desea reemplazar el uso de bloques de script de plantilla en línea con plantillas precompiladas, solo tiene que reemplazar un método en el Renderer:

Backbone.Marionette.Renderer.render = function(template, data){ return template(data); };

y ahora toda la aplicación usará plantillas precompiladas que adjunte al atributo de template su vista.

Incluso proporciono un complemento Marionette.Async con v0.9 que le permite soportar vistas de representación asíncrona. Me esfuerzo continuamente para que sea tan fácil como sea posible para reemplazar los comportamientos predeterminados en Marionette.

Código como configuración

Soy un fan de la "convención sobre la configuración" en ciertos contextos. Es una forma poderosa de hacer las cosas, y Marionette ofrece un poco de esto, aunque no demasiado, sinceramente. Muchos otros marcos, especialmente LayoutManager, ofrecen más convenciones sobre la configuración que Marionette.

Esto se hace con propósito e intención.

Creé suficientes complementos, frameworks, complementos y aplicaciones de JavaScript para conocer el dolor de intentar que las convenciones funcionen de una manera significativa y rápida. Se puede hacer con velocidad, pero generalmente a cambio de poder cambiarlo.

Con ese fin, tomo un enfoque de "código como configuración" para Marionette. No proporciono muchas API de "configuración" en las que puede proporcionar un literal de objeto con valores estáticos que cambian una serie de comportamientos. En su lugar, documenté los métodos que tiene cada objeto, tanto a través del código fuente anotado como a través de la documentación real de la API, con la intención de decirle cómo cambiar a Marionette para que funcione de la manera que desee.

Al proporcionar una API limpia y clara para los objetos de Marionetas, creo una situación en la que el reemplazo del comportamiento de un objeto específico o Marioneta como un todo es relativamente simple y muy flexible. Sacrifico las llamadas a la API de configuración "simple" por la flexibilidad de proporcionar tu propio código para que las cosas funcionen de la manera que deseas.

No encontrarás una API de "configuración" u "opciones" en Marionette. Pero encontrará una gran cantidad de métodos que cumplen un propósito muy específico, con firmas limpias, que facilitan el cambio de funcionamiento de Marionette.