¿Cuál es el propósito de backbone.js?
Intenté comprender la utilidad de backbone.js desde su sitio http://documentcloud.github.com/backbone , pero todavía no pude entender mucho.
¿Alguien puede ayudarme explicándome cómo funciona y cómo podría resultar útil para escribir un mejor JavaScript?
Backbone.js es básicamente un marco súper liviano que le permite estructurar su código Javascript en forma MVC (Modelo, Vista, Controlador) donde...
El modelo es parte de su código que recupera y completa los datos,
La vista es la representación HTML de este modelo (las vistas cambian a medida que cambian los modelos, etc.)
y un Controlador opcional que en este caso le permite guardar el estado de su aplicación Javascript a través de una URL hashbang, por ejemplo: http://twitter.com/#search?q=backbone.js
Algunas ventajas que descubrí con Backbone:
No más Spaghetti de Javascript: el código se organiza y se divide en archivos .js semánticamente significativos que luego se combinan usando JAMMIT
No más
jQuery.data(bla, bla): no es necesario almacenar datos en DOM, en su lugar almacene datos en modelosel enlace de eventos simplemente funciona
biblioteca de utilidades de subrayado extremadamente útil
El código backbone.js está bien documentado y es una lectura excelente. Me abrió los ojos a varias técnicas de código JS.
Contras:
- Me tomó un tiempo entenderlo y descubrir cómo aplicarlo a mi código, pero soy un novato en Javascript.
Aquí hay un conjunto de excelentes tutoriales sobre el uso de Backbone con Rails como back-end:
CloudEdit: un tutorial de Backbone.js con Rails:
http://www.jamesyu.org/2011/01/27/cloudedit-a-backbone-js-tutorial-by-example/
http://www.jamesyu.org/2011/02/09/backbone.js-tutorial-with-rails-part-2/
PD: También existe esta maravillosa clase de Colección que te permite manejar colecciones de modelos e imitar modelos anidados, pero no quiero confundirte desde el principio.
Si va a crear interfaces de usuario complejas en el navegador, probablemente terminará inventando la mayoría de las piezas que componen marcos como Backbone.js y Sammy.js. Entonces la pregunta es: ¿estás creando algo lo suficientemente complicado en el navegador como para merecer su uso (para que no termines inventando lo mismo tú mismo)?
Si lo que planea crear es algo en lo que la interfaz de usuario cambia periódicamente la forma en que se muestra pero no va al servidor para obtener páginas completamente nuevas , entonces probablemente necesite algo como Backbone.js o Sammy.js. El ejemplo cardinal de algo así es GMail de Google. Si alguna vez lo ha usado, notará que descarga una gran cantidad de HTML, CSS y JavaScript cuando inicia sesión por primera vez y luego todo sucede en segundo plano. Puede pasar de leer un correo electrónico a procesar la bandeja de entrada y buscarlos y volver a revisarlos todos sin pedir que se muestre una página completamente nueva.
Es ese tipo de aplicación en la que estos marcos se destacan por hacer más fácil de desarrollar. Sin ellos, terminarás reuniendo un conjunto diverso de bibliotecas individuales para obtener partes de la funcionalidad (por ejemplo, jQuery BBQ para la gestión del historial, Events.js para eventos, etc.) o terminarás construyendo todo tú mismo. y tener que mantener y probar todo usted mismo también. Compare eso con algo como Backbone.js que tiene miles de personas viéndolo en Github, cientos de bifurcaciones donde la gente puede estar trabajando en él y cientos de preguntas ya formuladas y respondidas aquí en Stack Overflow.
Pero nada de esto tiene importancia si lo que planeas construir no es lo suficientemente complicado como para que valga la pena la curva de aprendizaje asociada con un marco. Si todavía está creando sitios PHP, Java o cualquier otra cosa donde el servidor back-end todavía está haciendo todo el trabajo pesado de crear las páginas web a pedido del usuario y JavaScript/jQuery es solo la guinda de ese proceso, no lo está. No voy a necesitar o aún no estoy listo para Backbone.js.
La columna vertebral es...
...una biblioteca muy pequeña de componentes que puedes usar para ayudarte a organizar tu código. Viene empaquetado como un único archivo JavaScript. Excluyendo los comentarios, tiene menos de 1000 líneas de JavaScript real. Está escrito con sensatez y puedes leerlo completo en un par de horas.
Es una biblioteca de interfaz de usuario, la incluye en su página web con una etiqueta de secuencia de comandos. Solo afecta al navegador y dice poco sobre su servidor, excepto que idealmente debería exponer una API tranquila.
Si tiene una API, Backbone tiene algunas características útiles que lo ayudarán a comunicarse con ella, pero puede usar Backbone para agregar interactividad a cualquier página HTML estática.
La columna vertebral es para...
...agregando estructura a JavaScript.
Debido a que JavaScript no impone ningún patrón en particular, las aplicaciones de JavaScript pueden volverse muy complicadas muy rápidamente. Cualquiera que haya creado algo más que trivial en JavaScript probablemente se habrá topado con preguntas como:
- ¿Dónde almacenaré mis datos?
- ¿Dónde pondré mis funciones?
- ¿Cómo conectaré mis funciones para que se llamen de manera sensata y no se conviertan en espaguetis?
- ¿Cómo puedo hacer que diferentes desarrolladores puedan mantener este código?
Backbone busca responder estas preguntas brindándole:
- Modelos y colecciones para ayudarle a representar datos y colecciones de datos.
- Vistas, para ayudarle a actualizar su DOM cuando cambien sus datos.
- Un sistema de eventos para que los componentes puedan escucharse entre sí. Esto mantiene los componentes desacoplados y evita la espaguetización.
- Un conjunto mínimo de convenciones sensatas, para que los desarrolladores puedan trabajar juntos en la misma base de código.
A esto lo llamamos patrón MV*. Modelos, Vistas y extras opcionales.
La columna vertebral es ligera
A pesar de su apariencia inicial, Backbone es increíblemente ligero y apenas hace nada. Lo que hace es muy útil.
Te proporciona un conjunto de pequeños objetos que puedes crear y que pueden emitir eventos y escucharse entre sí. Puede crear un pequeño objeto para representar un comentario, por ejemplo, y luego un pequeño objeto commentView para representar la visualización del comentario en un lugar particular del navegador.
Puede decirle a commentView que escuche el comentario y se vuelva a dibujar cuando el comentario cambie. Incluso si tiene el mismo comentario mostrado en varios lugares de su página, todas estas vistas pueden escuchar el mismo modelo de comentario y permanecer sincronizadas.
Esta forma de componer código ayuda a evitar que se enrede incluso si su base de código se vuelve muy grande con muchas interacciones.
Modelos
Al comenzar, es común almacenar sus datos en una variable global o en el DOM como atributos de datos . Ambos tienen problemas. Las variables globales pueden entrar en conflicto entre sí y, por lo general, son de mala forma. Los atributos de datos almacenados en el DOM solo pueden ser cadenas, tendrás que analizarlos dentro y fuera nuevamente. Es difícil almacenar cosas como matrices, fechas u objetos y analizar los datos de forma estructurada.
Los atributos de datos se ven así:
<p data-username="derek" data-age="42"></p>
Backbone resuelve esto proporcionando un objeto Modelo para representar sus datos y métodos asociados . Digamos que tiene una lista de tareas pendientes, tendría un modelo que representa cada elemento de esa lista.
Cuando su modelo se actualiza, activa un evento. Es posible que tenga una vista vinculada a ese objeto en particular. La vista escucha eventos de cambio de modelo y se vuelve a representar.
Puntos de vista
Backbone le proporciona objetos Ver que se comunican con el DOM. Todas las funciones que manipulan el DOM o escuchan eventos DOM van aquí.
Una Vista normalmente implementa una función de renderizado que vuelve a dibujar la vista completa, o posiblemente parte de la vista. No hay obligación de implementar una función de renderizado, pero es una convención común.
Cada vista está vinculada a una parte particular del DOM, por lo que es posible que tenga un searchFormView, que solo escucha el formulario de búsqueda, y un shoppingCartView, que solo muestra el carrito de compras.
Por lo general, las vistas también están vinculadas a modelos o colecciones específicos. Cuando el modelo se actualiza, activa un evento que la vista escucha. La vista podría llamarse render para volver a dibujarse.
Del mismo modo, cuando escribe en un formulario, su vista puede actualizar un objeto modelo. Cualquier otra vista que escuche ese modelo llamará a su propia función de renderizado.
Esto nos brinda una separación clara de preocupaciones que mantiene nuestro código limpio y ordenado.
La función de renderizado
Puede implementar su función de renderizado de la forma que mejor le parezca. Podrías poner algo de jQuery aquí para actualizar el DOM manualmente.
También puedes compilar una plantilla y usarla. Una plantilla es sólo una cadena con puntos de inserción. Lo pasas a una función de compilación junto con un objeto JSON y obtienes una cadena compilada que puedes insertar en tu DOM.
Colecciones
También tienes acceso a colecciones que almacenan listas de modelos, por lo que todoCollection sería una lista de modelos de tareas pendientes. Cuando una colección gana o pierde un modelo, cambia su orden o se actualiza un modelo en una colección, toda la colección activa un evento.
Una vista puede escuchar una colección y actualizarse cada vez que se actualiza la colección.
Puede agregar métodos de clasificación y filtrado a su colección y hacer que se ordene automáticamente, por ejemplo.
Y eventos para unirlo todo
As much as possible, application components are decoupled from each other. They communicate using events, so a shoppingCartView might listenTo a shoppingCart collection, and redraw itself when the cart is added to.
shoppingCartView.listenTo(shoppingCart, "add", shoppingCartView.render);
Of course, other objects might also be listening to the shoppingCart as well, and might do other things like update a total, or save the state in local storage.
- Views listen to Models and render when the model changes.
- Views listen to collections and render a list (or a grid, or a map, etc.) when an item in the collection changes.
- Models listen to Views so they can change state, perhaps when a form is edited.
Decoupling your objects like this and communicating using events means that you'll never get tangled in knots, and adding new components and behaviour is easy. Your new components just have to listen to the other objects already in the system.
Conventions
Code written for Backbone follows a loose set of conventions. DOM code belongs in a View. Collection code belongs in a Collection. Business logic goes in a model. Another developer picking up your codebase will be able to hit the ground running.
To sum up
Backbone is a lightweight library that lends structure to your code. Components are decoupled and communicate via events so you won't end up in a mess. You can extend your codebase easily, simply by creating a new object and having it listen to your existing objects appropriately. Your code will be cleaner, nicer, and more maintainable.
My little book
I liked Backbone so much that I wrote a little intro book about it. You can read it online here: http://nicholasjohnson.com/backbone-book/
I also broke the material down into a short online course, which you can find here (archived). You can complete the course in about a day.
