Backbone.js

MVC es un patrón omnipresente en el lado del servidor. Existe en todas las plataformas web: JSF, Struts o Spring MVC en JavaEE, ASP.NET MVC en .NET, CakePHP, Symphony, Codeigniter y otros en PHP, Rails en Ruby, Django en Python,…​

A finales de los 90, Sun propugnó lo que dio en llamar "modelo 2" como patrón básico de arquitectura para aplicaciones web basadas en servlets y JSPs. Con mayores o menores modificaciones, este modelo fue la base de Struts y otros frameworks MVC del mundo JavaEE como Spring MVC. En el modelo 2, las peticiones del cliente las recibe un servlet, que hace el papel de controlador, y que delega la lógica de negocio en un conjunto de JavaBeans (el modelo). Finalmente el control se transfiere a un JSP (la vista), que muestra los resultados al usuario. No obstante, Sun nunca llegó a estandarizar un API o un framework para implementar MVC en nuestras aplicaciones.

En la actualidad, en un mundo de aplicaciones web convertidas en "simples" APIs en el lado del servidor, la antigua preponderancia de MVC en el servidor parece haberse difuminado un poco. Lo que es lógico, ya que la vista se ha trasladado al cliente. Así, la "necesidad" de usar MVC para estructurar la aplicación ha acabado trasladándose también al lado del cliente.

Cuando el uso de Javascript se limitaba a cosas como validación de formularios, pequeños cálculos y algunos efectos visuales MVC en el cliente no hacía una gran falta. El interfaz ya venía construido desde el servidor en forma de plantillas, y asímismo el servidor ya generaba casi todos los datos que se le mostraban al usuario. Pero en la actualidad se tiende a ir hacia SPAs (Single Page Applications), en las que básicamente la interfaz se construye dinámicamente con Javascript, lo que incluye también el formateo y presentación de los datos que está viendo el usuario, y la gestión de los nuevos que crea. Esto implica que desde Javascript también debemos poder manipular el modelo y ejecutar lógica de negocio. El servidor se queda como una especie de fuente de datos remota. Como vemos, prácticamente todo el esquema del antiguo "modelo 2" se ha trasladado al cliente.

Backbone fue uno de los primeros frameworks MVC en hacerse popular. Su filosofía va en la línea de lo que los anglosajones llaman "non opinionated", es decir, un framework que da libertad al desarrollador para hacer las cosas con su propio estilo, y no impone cierta forma de trabajar. Esto si lo queremos ver desde el punto de vista negativo, hace que el proceso de aprendizaje esté mezclado con cierta inseguridad para el desarrollador, ya que nunca acaba de tener claro "si lo está haciendo bien".

Otro aspecto que define el carácter de Backbone es la simplicidad. Es pequeño en términos de número de líneas de código y por tanto las funcionalidades que ofrece "tal cual" son limitadas. No ofrece facilidades "automágicas", casi todo está bajo control del desarrollador. Esto ha hecho que surjan multitud de plugins para cubrir las funcionalidaes que Backbone no tiene y sí tienen otros frameworks más complejos.

Cuando se habla de MVC, siempre surge la duda de exactamente de qué tipo de MVC se está hablando. Desde que apareció la versión original del patrón en los 70, en el contexto de aplicaciones de escritorio desarrolladas en Smalltalk, han surgido multitud de variantes, en las que cambian los roles que desarrolla exactamente cada uno de los componentes "Modelo/Vista/Controlador" o el flujo de información que hay entre ellos. Incluso hay versiones en las que alguno de los componentes del trío original desaparece y es sustituído por otros, como MVP (Model/View/Presenter), MVVM (Model/View/ViewModel),…​

Backbone no es exactamente MVC, más que nada porque directamente carece de controladores. En cuanto a qué es entonces, exactamente no lo vamos a responder aquí, más que nada porque es una discusión probablamente infructuosa y que en cualquier caso no va a ayudar a comprender mejor su funcionamiento. Nos conformaremos con llamarlo MV*, como dicen los anglosajones, MV- whatever, o MV- loquesea.

Teniendo presente lo que acabamos de decir, la siguiente figura mostraría una posible estructura conceptual de una aplicación Backbone (posible porque también podríamos estructurar las cosas de otro modo y tampoco "estaría mal"). La figura está tomada del libro de Addy Osmani "Developing Backbone Applications", que además está disponible en Github

Como vemos en la figura, en el "corazón" de Backbone están los modelos y las vistas. Además, para reflejar el hecho de que típicamente en una aplicación vamos a manejar más de una instancia del mismo tipo de modelo (clientes, libros, mensajes,…​) Backbone modeliza también la idea de colección de modelos.

Las colecciones de modelos interactúan (se sincronizan, sync) con una fuente de datos, típicamente un API REST en el servidor.

Por otro lado, la vista interactúa con el HTML de la página. La vista actualiza el DOM, modificando así el HTML "en tiempo real" y en el sentido contrario, los eventos del DOM se procesan en la vista.

Vista y modelo se comunican mediante eventos. Esto se hace así para reducir el acoplamiento entre ambos. Es normal que la vista tenga que conocer ciertos detalles del modelo para poder interactuar con él, pero en general el modelo no debería tener que conocer cómo es la vista para comunicarse con ella. Así podremos reutilizar los modelos cambiando una vista por otra. Para solucionar este problema se usa el paradigma de comunicación "Publicar/Suscribir" (Publish/Subscribe o Pub/Sub). En este paradigma el objeto que quiere comunicarse con otro sin acoplarse con él no lo hace directamente sino emitiendo eventos. El objeto interesado se suscribe a esos eventos. En Backbone veremos que la vista se suscribe a los eventos que le interesan del modelo.

Para terminar, el router es un componente que asocia URLs con código Javascript. La idea es que cada operación o cada estado de nuestra aplicación debería identificarse con una URL, lo que permitiría que el usuario creara sin problemas sus bookmarks.

Como ya hemos visto, el modelo es el conjunto de objetos que forman el dominio de nuestra aplicación y por tanto depende enteramente de su naturaleza: en un "campus virtual" tendremos profesores, alumnos, notas, …​ mientras que en una red social tendremos usuarios, mensajes, fotos, …​

Los modelos son realmente las mismas entidades que usamos en la capa de negocio de la aplicación. En ellos encapsulamos por tanto dos aspectos: los datos y la lógica de negocio. En nuestro ejemplo del tiempo los datos serán los parámetros que definen el estado actual del tiempo (temperatura, humedad, descripción en modo texto: - "soleado", "nublado", …​-). La lógica de negocio se ocuparía de la comunicación con el servicio web remoto que nos ofrece los datos.

Backbone nos ofrece una "clase" base, Backbone.Model, que podemos extender para crear nuestros propios modelos. No es necesario especificar por adelantado las propiedades del modelo, se pueden crear en cualquier momento, igual que con los objetos Javascript convencionales

Antes de ver cómo implementamos la lógica de negocio, necesitamos saber cómo funciona el API del servicio web. Básicamente hay que hacer una petición GET a http://api.openweathermap.org/data/2.5/weather con el parámetro q igual al nombre de la localidad. Si además añadimos los parámetros units=metric&lang=es obtendremos el resultado en español usando unidades del sistema métrico. La respuesta será un JSON del estilo

Como vemos, la descripción del tiempo está en el campo weather[0].description. El weather[0].icon es el icono que lo representa gráficamente. Como indica la documentación, para obtener el icono hay que ponerle delante a este nombre una URL base.

Con esto ya podemos implementar la llamada al servicio web desde nuestro modelo. La lógica de negocio la implementaremos normalmente con propiedades de tipo function(). Como la funcionalidad la deben tener todas las instancias de la clase, le asignaremos la propiedad a la clase:

Podemos probar el funcionamiento del código anterior tecleando algo como lo que sigue en la consola Javascript:

La vista en Backbone tiene la misión de generar el HTML que represente el modelo en pantalla. Es decir, de dibujar el widget. También debe responder a los eventos del usuario. En nuestro caso el único evento es la pulsación en el botón "ver tiempo".

Las vistas heredan de la clase Backbone.View, y deben tener asociada una instancia de un modelo (también podrían tener varias instancias, como veremos en la siguiente sesión).

Como ya hemos dicho, tenemos un pequeño problema: ¿cómo hacemos que el modelo avise a la vista de que actualizarTiempo ya ha acabado y que por tanto se puede ejecutar el renderData()? podría ejecutarlo el propio modelo, pero necesitaría mantener una referencia a la vista y esto haría que dejara de ser genérico y se "atara" a la vista (asumiera que siempre va a estar asociado a una vista que tiene un método renderData).

La solución más limpia para comunicar del modelo hacia la vista es no tocar el código del modelo en absoluto y usar la idea de "Publicar/Suscribir". Por defecto, los modelos de Backbone emiten eventos cuando se dan ciertas situaciones, por ejemplo que cambia una propiedad, o que el modelo se sincroniza con el estado del servidor. Lo único que debe hacer la vista es encontrar el evento apropiado y suscribirse a él. En este caso, el evento que nos viene que ni pintado sería que la propiedad dt del modelo adquiera un nuevo valor. Recordemos que esta propiedad es un timestamp que nos indica cuándo se han obtenido los datos.

En el initialize de la vista, que se usa para inicializar valores por defecto y otros elementos, podemos suscribirnos al evento del modelo. Esto se puede hacer con el método listenTo, indicando a qué objeto queremos suscribirnos, qué evento nos interesa, y cuál va a ser el manejador de evento:

El resto del código de la vista quedaría igual que antes. Como vemos, la función que dispara la actualización del tiempo no necesita llamar a renderData ella misma. Si la operación de actualización cambia el atributo dt del modelo se llamará a renderData automáticamente.

Este ejercicio debes entregarlo en una carpeta llamada mi_tiempo_backbone.

En este ejercicio vamos a modificar el modelo del widget del tiempo para incluir también la temperatura actual, y crearemos una nueva vista que incluya esta información.

Este ejercicio debes entregarlo en una carpeta llamada UAdivino.

Crear una aplicación de Backbone que funcione al estilo de la conocida "bola 8 mágica", a la que se le "hace una pregunta" en voz alta y nos responde algo al azar.

El widget tendrá un aspecto similar al siguiente:

Los modelos en Backbone siguen la filosofía de Javascript: son dinámicos y podemos añadir y eliminar atributos sobre la marcha. Para añadir un atributo, o cambiar su valor si este ya existe, usamos set(nombre, valor). Para obtener el valor, get(nombre). Continuando con el ejemplo anterior:

También podemos fijar los valores de los atributos al instanciar el objeto con new. Se los pasamos a este método en forma de hash:

Si deseamos eliminar un atributo podemos usar unset(nombre), aunque este método lo único que hace es borrar el atributo usando delete. Podríamos hacer lo mismo accediendo directamente a la propiedad de la clase llamada attributes, que es la que contiene los atributos en sí

Podemos comprobar si un objeto tiene un determinado atributo con has(nombre), que devolverá un valor booleano indicándolo.

Como ya hemos dicho, cuando creamos una clase que hereda de Backbone.Model podemos definir propiedades en forma de objeto Javascript, normalmente usando notación literal. De hecho podemos definir propiedades de instancia y propiedades de clase. Las primeras serían propias de cada instancia de nuestro modelo. Las segundas serían de la clase del modelo en sí. En Backbone ya vienen definidas por defecto unas cuantas propiedades de instancia. Por ejemplo cada objeto tiene un cid que es un identificador único y se va generando secuencialmente.

Lo habitual es usar las propiedades especificadas en el extend para definir métodos. Un método no va a ser más que una propiedad que resulta ser una función. Por ejemplo:

Todos los modelos tienen una propiedad por defecto cid (client id) que actúa como identificador y cuyo valor va generando automáticamente Backbone. Como luego veremos, cuando el modelo se almacena en el servidor también pasa a tener una propiedad id, con valor asignado por este.

Podemos ejecutar un determinado código cuando se cree el modelo, poniéndolo en el método initialize

Aunque si lo que queremos es simplemente inicializar atributos con valores por defecto es más directo usar la propiedad defaults. A esta propiedad se le pasa un objeto en notación literal con los nombres de los atributos y sus valores por defecto:

La solución es hacer que defaults sea una función que devuelva un objeto con los valores deseados, así, cada instancia tendrá su propia copia de valores por defecto.

Backbone ofrece un método validate() para la validación de datos, pero el código tenemos que escribirlo nosotros por completo, no existe ningún tipo de validación declarativa.

Si la validación es correcta el método validate() no debería devolver nada. En caso de que sea incorrecta, corre por cuenta del desarrollador qué devolver, mientras se devuelva algo. Por ejemplo:

validate() recibe como parámetro un objeto con los atributos que se están validando. Backbone llama automáticamente a validate() al guardar un objeto en el servidor. En ese caso los atributos recibidos en validate() son los actuales del objeto.

Además validará el cambio de valor de un atributo si pasamos la opción validate:true. En este caso los atributos recibidos en validate() son los nuevos valores que estamos intentando fijar.

Para crear el modelo en el lado del servidor llamaríamos al método save().

La creación del objeto en el servidor implica una petición POST. Antes de hacer esta petición se llama a validate(), y si la validación falla, save() devuelve false.

Una vez hecha la petición, Backbone espera que el servidor le devuelva un JSON incluyendo al menos la propiedad "id" con el identificador del nuevo recurso creado. Si esto se cumple, la librería establece la propiedad id del modelo a este valor.

Si el servidor usara una propiedad con nombre distinto a id para devolver el identificador del objeto, podemos poner este nombre como valor del atributo idAttribute del modelo.

Para tener más información sobre la respuesta devuelta por el servidor debemos pasar dos callbacks en el save(), uno para llamar en caso de éxito (código de estado en el rango 200-299) y otro en caso de error:

El método fetch() le pide al servidor los datos del modelo, sobreescribiendo los actuales. Asume que la respuesta va a venir en forma de objeto JSON. Para poder usar este método el objeto ya debe tener un id asignado, ya que la URL a la que se va a lanzar la petición get es la urlRoot + /id.

Si los valores de los atributos procedentes del servidor difieren de los actuales se disparará un evento change. Posteriormente veremos cómo hacer que un objeto determinado observe un evento que genera otro.

La última línea imprimirá undefined ya que no habrá dado tiempo a que el servidor responda y a rellenar el objeto con los valores de la respuesta. Sin embargo si depuramos el código ayudándonos de un debugger paso a paso, daremos tiempo a que se procese la respuesta y sí mostrará el login correctamente, con el consiguiente WTF! por nuestra parte. Para poder enterarnos de cuándo se ha rellenado la información del objeto tenemos que usar callbacks en fetch() o bien usar eventos, como veremos al final de la sesión.

La actualización se dispara con el mismo método que sirve para crear un objeto en el servidor: save(). Backbone asume que un modelo que tiene valor asignado a la propiedad id ya existe en el servidor, y por tanto al llamar a save() lanzará un PUT a urlRoot + /id.

Para eliminar un objeto del servidor se usa destroy(), que lanzará una petición DELETE a urlRoot + /id, salvo que todavía no haya sido guardado en el servidor (no tenga id), en cuyo caso no hará petición y devolverá false.

Podemos obtener el modelo en una posición con el método at(). Como los arrays, las colecciones mantienen una propiedad length con el número de elementos.

Si conocemos el id o el cid del modelo, podemos obtenerlo directamente con get().

para iterar por la colección podemos usar el típico bucle for que vaya incrementando un índice y usar at(), pero también podemos usar un iterador:

Al forEach se le pasa una función, que será llamada conforme se vaya iterando por la lista. Como argumento la función recibirá el objeto en la posición actual. Este y otros métodos de manejo de colecciones y eventos procede en realidad de la librería underscore, que como ya hemos comentado es un prerrequisito de Backbone.

En principio el orden de los elementos al recorrer la colección es el de inserción, pero también podemos especificar un criterio de ordenación. Para casos sencillos podemos darle al atributo comparator el nombre del campo usado para clasificar.

Si necesitamos usar un criterio más complejo le podemos asignar a comparator una función con un único argumento que a partir del objeto devuelva el criterio de ordenación.

También podemos usar una función con dos argumentos que actúe como un comparador: dados dos objetos a comparar devuelve -1 si el primer argumento es menor que el segundo, +1 si es mayor y 0 si son iguales.

Podemos filtrar una colección ayudándonos de la función filter de underscore. Por ejemplo, aquí vemos cómo podríamos filtrar una colección de usuarios obteniendo solo los que tienen un password de menos de 6 caracteres.

Podemos añadir un nuevo modelo o array de modelos a la colección con add(). El modelo se añadirá en la posición especificada por el criterio de ordenación actual. Si queremos añadir por la cabeza usaríamos unshift() y por la cola push(). Podemos eliminar un modelo o un array de ellos con remove(), o eliminar el de la cabeza con shift() y el de la cola con pop().

El método set() se usa para "actualizar" una colección. Si un modelo de la nueva colección no existe en la actual se añadirá, si estaba en la antigua pero no en la nueva se eliminará, y si existe en ambas se mezclarán sus atributos (los que existan en antigua y nueva se actualizarán al valor de la nueva).

Para obtener una colección del servidor se usa el método fetch(), igual que con los modelos. Si la colección no está vacía no se elimina completamente, sino que se usa el método set() para actualizar la del cliente.

Para guardar la colección en el servidor, actualizarla o eliminarla tendremos que ir procesando los modelos uno a uno. No obstante en los modelos incluidos en colecciones no es necesario especificar la urlRoot de cada uno por separado, se usa automáticamente la url de la colección como URL base.

En Backbone cualquier componente (modelo, vista, colección o router) puede observar los eventos emitidos por cualquier otro componente. Pero también podemos hacer que cualquier objeto Javascript pueda emitir y recibir eventos. También podemos hacer que cualquier objeto Javascript sea capaz de observar eventos de Backbone haciendo un mixin del objeto con la clase Backbone.Events. Es tan sencillo como llamar al método _.extend de Underscore pasándole como parámetros el objeto y la clase Events:

Hay varias posibilidades para suscribirnos a los eventos que nos interese. La más usada es el método listenTo, al que se le pasa como parámetro el objeto a observar, el nombre del evento y la función handler. Por ejemplo, supongamos que desde un modelo queremos observar cuándo cambia algún atributo de otro:

Recordemos que si el observador no es un componente de Backbone, primero tenemos que hacer un mixin con Backbone.Events. Lo demás es idéntico.

Para dejar de escuchar todos los eventos que emite un objeto podemos usar stopListening pasando como parámetro el objeto que queremos "ignorar" de ahora en adelante.

Habitualmente los observadores de los eventos no serán objetos propios como en nuestro ejemplo, sino componentes de Backbone. Típicamente son las vistas las que observan el comportamiento del modelo, lo que permite comunicarlos sin introducir acoplamiento entre ambos. El modelo puede indicar que ha cambiado para que la vista muestre los nuevos datos, sin necesidad de mantener una referencia a la vista, ni siquiera saber cómo se llama el método de la vista que procesa los cambios.

Antes hemos visto el caso de la operación fetch, para actualizar un modelo/colección con los datos del servidor, que al ser asíncrona continúa la ejecución sin haber recibido todavía los datos. Podríamos saber cuándo se han recibido por ejemplo suscribiéndonos al evento sync, que se dispara cuando los datos locales se sincronizan con el servidor.

Podemos también generar un evento manualmente, incluso eventos propios. En caso de ser un evento propio lo único que tenemos que hacer es inventar un nombre para el evento. Por convenio se usa el tipo de componente y el nombre dado al evento separados por :. Por ejemplo model:miEvento

Disparamos el evento llamando a trigger desde el objeto que emite el evento:

trigger admite un número variable de argumentos. El primero es el nombre del evento a generar y el resto son los parámetros que se le pasarán al handler.

Ya hemos comentado que Backbone necesita que cada modelo tenga un id para poder identificarlo de manera única en el servidor. Si los objetos que devuelve nuestro API siguen la misma convención no tendremos que hacer nada en especial, pero hay algunas plataformas en las que el identificador no es el atributo id sino que se usa otro nombre. Por ejemplo como veréis en la asignatura de NoSQL, en MongoDB se usa el campo _id como identificador. En ese caso lo único que tendremos que hacer es asignar a la propiedad idAttribute del modelo el nombre del atributo que actúa de identificador.

Si el API devuelve un identificador más complejo (por ejemplo formado por dos atributos, o por parte de un atributo) no podemos establecer esta simple correspondencia. En ese caso lo que podemos hacer es sobreescribir el método url(), que debería devolver la URL del modelo, y que por defecto se obtiene como la URL "base" más el id. La URL base de un modelo se define bien como la url de la colección, si el modelo está incluido en una, bien como el valor de la propiedad urlRoot del modelo (que por defecto es vacío y tenemos que especificar si lo deseamos).

Por ejemplo supongamos que un API usara como identificador el atributo id pero luego la URL de un objeto se formara concatenando la URL base + el id + el sufijo /data (de acuerdo, es un ejemplo un poco raro pero podría ser). En el modelo haríamos algo como:

Por defecto Backbone toma la respuesta del servidor como un objeto JSON y asigna sus propiedades "de primer nivel" como atributos del modelo. Esto es porque la implementación por defecto de la función parse(), que es la que se usa para analizar la respuesta del servidor, simplemente devuelve tal cual el cuerpo de la respuesta:

Sin embargo hay muchos APIs que en los listados "envuelven" los resultados en un objeto que actúa como wrapper y los resultados en sí están dentro de él. Esto es típico de las operaciones de búsqueda o listados, por ejemplo al buscar repositorios en el API de GitHub. En este caso lo que haría Backbone es guardar el wrapper dentro del modelo, que no es lo que queremos. Tendremos pues que sobreescribir parse(). En el ejemplo de búsqueda en GitHub, el wrapper tiene una propiedad items donde están los resultados como un array. De modo que si tuvieramos una colección Repositorios tendríamos que hacer algo como:

Todos los APIs en los que podamos modificar información van a requerir que nos autentifiquemos de una forma u otra, incluso muchos APIs en los que solo se puede leer información requieren del uso de una api key para identificar al "usuario" y evitar que un mismo usuario haga un número de peticiones excesivo.

Hay varias formas de enviar la información adicional requerida. Prácticamente todas se basan en que internamente Backbone usa jQuery para hacer las peticiones AJAX, por lo que podemos usar los métodos estándar de jQuery para manipular la petición. Por ejemplo el método $.ajaxPrefilter() nos permite modificar una petición antes de que se envíe al servidor, cambiando sus opciones, que son las mismas que podemos usar en el típico $.ajax().

Por ejemplo, si tenemos que autentificarnos o enviar datos mediante cabeceras especiales, haríamos algo como:

Para los APIs que no sean del todo REST tendremos que sobreescribir el método sync(), que es el "corazón" de la comunicación con el servidor. Evidentemente esto va a ser mucho más complicado que todas las configuraciones que hemos visto hasta ahora. No obstante, hay ciertos casos de uso típicos para los que se han desarrollado plugins de terceros.

Por ejemplo, hay APIs de terceros que permiten sincronizar los datos con el LocalStorage del navegador en lugar de con un servidor remoto. Esto es muy interesante para aplicaciones que puedan trabajar offline por ejemplo agendas, listas de tareas, notas, …​ el más conocido es Backbone localStorage Adapter, que nos permite sincronizar una colección automáticamente con el LocalStorage, sin más que definir una propiedad localStorage

Incluso hay plugins, como DualStorage que permiten trabajar con el API REST remoto por defecto y cambiar de manera transparente al LocalStorage cuando se detecta que estamos offline.

Este ejercicio debes entregarlo en una carpeta llamada star_wars.

Vamos a probar cómo comunicarnos mediante Backbone con el API de Star Wars que ya has usado en otros ejercicios. Como sabes, el API solo permite hacer peticiones GET, por lo que vamos a centrarnos en listar y filtrar datos. Tendremos que adaptar la persistencia REST por defecto de Backbone a la forma de funcionar del API.

Este ejercicio debes entregarlo en una carpeta llamada alquiler_coches. Seguiremos trabajando sobre la misma carpeta en más sesiones.

El API de Star Wars no nos permite hacer más que peticiones GET, así que vamos a usar otro backend con el que podamos desarrollar una aplicación completa. Para no tener que programarnos el backend desde cero, ya que no es el objetivo de la asignatura, usaremos una plataforma de tipo BAAS (Backend As A Service), con la que podemos crear un backend de tipo REST de manera sencilla.

Usaremos una plataforma llamada Parse. Aunque ofrece otros servicios, el que nos interesa es el de persistencia remota, con el que podemos hacer CRUD de objetos en el servidor que no serán más que conjuntos de pares propiedad-valor, al igual que en Backbone.

Para poder trabajar con la Parse lo primero es darse de alta como desarrollador. Una vez dados de alta si nos autentificamos accederemos al dashboard donde podremos crear aplicaciones. Cada aplicación tiene un almacenamiento persistente independiente y para usarla necesitamos un par de claves, como ahora veremos.

Vamos a ir creando en sucesivas sesiones una aplicación para una compañía de alquiler de coches. En concreto vamos a ir desarrollando solo la parte de administración en la que se podrá listar los vehículos, darlos de alta/baja, editarlos,…​

Por el momento para nosotros los coches tendrán una matricula, un modelo, un kilometraje y un valor disponible indicando si está disponible o por el contrario está alquilado.

Para probar lo implementado, en la consola Javascript crea manualmente coches y comprueba interactivamente que se pueden guardar, recuperar, y modificar. Comprueba que si la matrícula no es válida no se llega a hacer la petición al servidor.

Todas las vistas tienen una propiedad predefinida llamada el, que representa el nodo del DOM que es la raíz del HTML de la vista. La vista genera HTML y lo lo coloca dentro de el (luego veremos cómo se hace esto habitualmente). Después nosotros somos los responsables de tomar esa propiedad el e insertarla en el lugar que queramos del DOM.

Por defecto, el es una etiqueta <div>. Si ejecutamos el código anterior veremos que por tanto se le añade un <div> a la página con el mensaje que hemos puesto.

Podemos darle el valor que queramos a el si no nos interesa el valor por defecto. De hecho podemos configurarla totalmente a nuestra medida con una serie de atributos

Al ejecutar el código anterior al cuerpo de la página se le añadirá un HTML como este

Hasta ahora hemos observado que la vista genera el HTML pero nosotros somos los responsables de incluirlo en la página. Hay otra posibilidad: darle al el como valor el id de algún nodo de la página. Así, al poner

El contenido ya aparecería insertado en el DOM de la página actual.

Como ya hemos dicho en otras ocasiones Backbone facilita el trabajo con jQuery. En este caso tiene predefinida una propiedad $el que representa lo mismo que el pero es un objeto jQuery en lugar de un nodo DOM estándar, por lo que podemos usar el API de jQuery si nos resulta más cómodo:

Ya hemos visto que la inclusión de la vista en el DOM se hace manualmente o bien poniendo como valor de el un nodo ya existente en el DOM. Para eliminar la vista del DOM se usa el método remove().

Hasta ahora hemos estado manipulando directamente el el para incluir contenido en la vista, pero esta forma de trabajar no es muy "limpia" que digamos. La convención habitual en Backbone es sobreescribir el método render(), que debería rellenar el contenido del el, generando el HTML de la vista. Y decimos convención ya que si examinamos los fuentes de Backbone veremos que el resto del código no llama a render() en ningún momento, y la implementación por defecto no hace nada (salvo devolver this, hablaremos ahora sobre esto).

Así, los ejemplos que hemos puesto hasta ahora quedarían mejor como:

Nótese que:

Las vistas que solo muestran contenido estático no son muy divertidas. Normalmente nos interesará que sean interactivas y respondan a eventos. La gestión de eventos también es responsabilidad de la vista, y se define en un objeto en formato JSON llamado events. Las propiedades son nombres de eventos (y de manera opcional un selector CSS indicando el nodo o nodos DOM al que afecta). Los valores son cadenas con el nombre del manejador correspondiente. Por ejemplo:

El selector CSS se busca únicamente dentro de la vista. En el ejemplo, si en la página (fuera de la vista) hubiera otras etiquetas con class="boton" no se verían afectadas por esta gestión de eventos. Esto es interesante porque hace a las vistas modulares y autocontenidas.

Podemos modificar dinámicamente la gestión de eventos llamando al método delegateEvents() y pasándole un objeto JSON con el nuevo valor a darle a events.

Hasta ahora hemos hablado de vistas, pero ¿qué relación mantienen con los modelos?. La idea es que cada vista normalmente tiene una referencia al modelo o colección que representa. Hasta ahora en los ejemplos que hemos visto no había modelo, pero esto en realidad no es lo habitual. Es más habitual algo como:

Código en JSbin.com

Con la propiedad collection podemos pasarle una colección a la vista.

El data binding es la vinculación entre ciertos componentes del modelo y de la vista, de modo que cuando cambia uno de ellos el otro se actualiza automáticamente. La vinculación puede ser solo en un sentido o en ambos. La de un solo sentido suele funcionar del modelo hacia la vista (si cambia el primero se actualiza la segunda) pero no al contrario. La bidireccional se suele usar en formularios, cuando estamos editando los datos del modelo.

Backbone no tiene data binding propiamente dicho, ya que el único momento en que están vinculados los datos del modelo y la vista es justo cuando se hace un render de la vista.

En Backbone es habitual vincular el modelo con la vista usando eventos. Las vistas pueden suscribirse a eventos del modelo. Al recibir el evento la vista debe hacer un rendering parcial, modificando únicamente la parte que no varía. Backbone no va a ayudarnos en esto último, tendremos que hacerlo nosotros mismos. Por ejemplo, supongamos que tenemos un widget que monitoriza el estado de un servidor y debe actualizar la vista automáticamente cuando cambie éste:

Si ahora cambiara el valor de la propiedad `estado `del modelo el estado se actualizaría sin tener que redibujar totalmente la vista. Podemos probarlo de manera sencilla tecleando en la consola del navegador:

Aunque ya hemos dicho que Backbone tal cual no tiene binding automático, existen varios plugins que proporcionan esta funcionalidad. Uno de los más conocidos es stickit, que vamos a ver aquí brevemente. Hay otros como por ejemplo backbone UI, que además incluye widgets o backbone baguette.

Veamos un ejemplo de cómo conseguir data binding automático desde el modelo hacia la vista. Hasta cierto punto la idea es similar a lo que hacíamos antes con los eventos: en la vista debemos tener ciertas secciones del HTML marcadas indicando que ahí van los datos que queremos vincular. La diferencia es que stickit los actualizará automáticamente por nosotros sin necesidad de gestionar los eventos ni implementar el rendering parcial.

Si ahora modificamos el modelo, la vista se actualizará automáticamente, por ejemplo podemos ejecutar en la consola Javascript la siguiente línea para ver cómo se actualiza la vista

Stickit soporta también el data binding bidireccional. Lo único que hay que hacer en el ejemplo anterior es cambiar las etiquetas <b> y <em> por campos de formulario de tipo texto, por ejemplo. Podremos observar que cuando se modifica el contenido del campo el atributo del modelo refleja el cambio.

Los ejemplos anteriores son con la configuración de la librería por defecto. Podemos forzar el tipo de vinculación que queramos (por ejemplo solo de una dirección en campos de formulario), configurar los eventos de vista que disparan los cambios en el modelo, incluir nuestros propios handlers,…​. La librería es bastante completa y flexible, aquí solo queremos mostrar una pequeña introducción a cómo funcionaría el data binding integrado con Backbone.

La idea básica es que una plantilla más un "objeto" formado por pares propiedad-valor va a generar el resultado final. En la plantilla se toma todo como literal excepto las partes entre dobles llaves ({{ }}), que representan variables o indican secciones especiales, como ahora veremos.

La sintaxis del lenguaje se puede consultar en el manual online. Vamos a ver un ejemplo que incluye todas las características típicas que vamos a necesitar aquí:

Estando en el lado del cliente, y usando HTML+JS veamos dónde almacenaríamos la plantilla, de dónde sacaríamos los datos y cómo uniríamos ambos elementos para obtener el resultado final.

Como Backbone en sí no prevé ni aporta nada con respecto a las plantillas, en realidad no hay una "forma correcta" de usar plantillas en el código Backbone, pero hay algunos fragmentos de código típicos que se repiten más o menos literalmente en muchas aplicaciones Backbone. Vamos a ver un par de casos de uso.

Implementa un formulario que sea una vista de Backbone y que permita dar de alta un nuevo vehículo. - El modelo asociado a la vista será una instancia de Coche - Puedes crear una plantilla Mustache para la vista, pero ten en cuenta que será totalmente estática (solo HTML), ya que no sirve para mostrar datos, sino para introducirlos. - La vista debería escuchar el evento sync sobre el modelo, que indicará que el alta en el servidor se ha producido correctamente. En ese caso se debería mostrar un mensaje indicándolo (bastará con un alert). En una aplicación real también debería escuchar el evento error que indica un error, para simplificar lo vamos a obviar aquí.

Implementa una vista de Backbone que muestre un listado con todos los coches. El listado será totalmente estático salvo por el hecho de que cuando se inserte un nuevo coche en el formulario de alta debe aparecer también aquí. Para ello:

Cada subvista será una instancia de la clase VistaContacto, y será responsable de renderizarse "ella misma" y procesar sus eventos. El código Javascript sería algo como lo que sigue:

La plantilla Mustache asociada sería la siguiente:

Esta vista no tiene nada sustancialmente diferente de las que hemos usado hasta el momento. La clave, pues, está en la vista global.

La plantilla Mustache asociada a la vista no es excesivamente interesante, únicamente contiene la parte "externa" a la lista de contactos en sí: un título y un formulario para dar de alta un nuevo contacto:

La parte realmente interesante es el código del método render(). Además de renderizar la plantilla asociada, debe ir creando una subvista por cada elemento del listado, haciendo el render() de dicha subvista y añadiendo el resultado al HTML propio.

El código anterior tiene un pequeño problema. Ya hemos visto alguna vez que cuando desde una función de una clase de Backbone llamamos a otra, this no tiene como valor el objeto actual, sino el objeto global (window). Para resolverlo, en la inicialización de la vista enlazamos (bind) la función renderContacto con la vista:

En el código Backbone típico se suele usar el _.bindAll de Underscore para vincular una función con un objeto, más que nada porque es cómodo y nos asegura el soporte en navegadores antiguos. También podríamos haber usado el bind de Javascript estándar:

Marionette es una extensión de Backbone. Le añade una serie de funcionalidades interesantes para el trabajo cotidiano con el framework. Por ejemplo ya hemos visto que Backbone "aporta poco" en cuanto a la gestión de las vistas, prácticamente lo tenemos que hacer todo nosotros. Marionette automatiza mucho más el trabajo con las vistas, implementando un render que a diferencia del de Backbone sí hace algo por defecto: serializa el modelo en JSON, aplica la plantilla, …​. Además incluye clases pensadas para representar explícitamente jerarquías de vistas. Enseguida veremos una pequeña introducción a estas funcionalidades. Por otro lado Marionette también incluye funcionalidades no relativas a vistas como por ejemplo la definición de módulos, que nos permiten organizar mejor nuestro código, o la ampliación del sistema de eventos de Backbone.

Marionette tiene dos tipos de vista pensados para resolver nuestro problema. La clase ItemView nos sirve para representar un único modelo, mientras que CollectionView representa una colección. Un CollectionView tendrá un conjunto de ItemView como vistas "hijas".

Continuando con el ejemplo del apartado anterior, para representar cada contacto usaríamos un ItemView. Marionette implementa un render por defecto que:

Una vez hemos definido la vista para un item de la lista, ya podemos definir la vista "global" para la lista de elementos. En Marionette para esto se usa un CollectionView, que incluirá como vistas "hijas" varias ItemView. Siguiendo con nuestro ejemplo, para presentar la lista de contactos: (mostramos solo lo que hay que añadir al código anterior)

Como vemos, lo único que necesitamos para definir la vista asociada a la colección es especificar qué clase va a actuar como vista para cada elemento. En nuestro caso es la clase VistaContacto. El render de la CollectionView creará automáticamente una VistaContacto por cada elemento de la colección si es necesario, llamará a su render y concatenará todos los HTML resultantes, es decir, lo mismo que antes teníamos que hacer de modo manual.

Nótese que una CollectionView no tiene HTML "propio", su HTML es el formado por la concatenación del de sus vistas hijas. Si queremos que la vista "madre" contenga información propia deberíamos usar una CompositeView, que es como una CollectionView pero se le puede asociar también un model y una template.

Marionette hace un re-render automático cada vez que se modifica la colección asociada a una CollectionView. Si nos vamos a la consola Javascript y tecleamos

veremos cómo se redibuja automáticamente la vista y aparece el nuevo contacto. Es decir, el CollectionView implementa un data binding unidireccional, del modelo hacia la vista.

En Marionette podemos definir una vista que sea una composición de otras extendiendo la clase LayoutView. Esta clase tiene una propiedad regions en la que daremos una lista de las secciones (o como las llama Marionette, regiones) que componen la vista. Para cada sección especificamos un nombre simbólico y un selector que identifique la región dentro de la página.

Una vez creada la instancia de LayoutView podemos acceder a sus regiones por identificador y mostrar una vista en cada una de ellas con show. Podemos eliminar la vista con empty.

Para anidar vistas dentro de otras podemos hacer que la vista mostrada en una región sea a su vez una LayoutView. Supongamos que ahora queremos que la región principal se divida a su vez en un título y en otra subregión para el texto del cuerpo principal.

Vamos a usar plantillas para modularizar las regiones:

Ahora el código sería algo como lo que sigue:

Para este ejercicio haz una copia de la carpeta alquiler_coches que ya tenías, y llámala alquiler_coches_subvistas.

Usando solamente Backbone, sin Marionette, cambia el listado "estático" que ya tenías y que usaba una sola vista por un listado dinámico en el que se puedan eliminar coches, y cada coche se muestre con una subvista. Cada coche debería aparecer con un botón o enlace "eliminar" que:

Para este ejercicio deberás coger tu código JS (solo los modelos, no las vistas) y juntarlo con la plantilla de aplicación Marionette que tienes en las plantillas de la asignatura. Entrega el ejercicio en una carpeta alquiler_coches_marionette.

Usando Marionette implementar las mismas funcionalidades del ejercicio anterior. Ten en cuenta que como la vista global debe mostrar el formulario de alta no te valdrá con una CollectionView sino que debes usar una CompositeView que sí puede tener una template asociada.

El código anterior no es muy difícil de leer pero tiene un problema: conforme se complica el HTML a generar se hace cada vez más tedioso usar un API de este estilo, es el mismo problema que tiene el API del DOM estándar.

En ReactJS existe una sintaxis alternativa, llamada JSX, que nos permite mezclar fragmentos de HTML (XML, en realidad) con código JS de manera mucho más natural y concisa que el API anterior. Por eso en la práctica el código que hemos visto no es "nada típico" en React. Esta versión alternativa con JSX es mucho más común:

Lo primero que hay que destacar es que escribir código JSX no es simplemente usar cadenas de HTML dentro del JS. Nótese que el HTML está tal cual dentro del código, sin delimitadores. Por eso este script no encaja con la sintaxis JS estándar y de ahí que en el type del script se haya puesto el valor especial text/jsx. ReactJS incluye una librería adicional para parsear el JSX y transformarlo automáticamente a JS convencional (al estilo de la versión "antigua" de nuestro "Hola React").

Para que el navegador compile el JSX a JS "sobre la marcha" incluimos en el HTML la librería adecuada:

Además hemos aprovechado para insertar JS en medio del HTML para que se vea que es posible hacerlo, sin más que rodearlo de llaves {…​}. Por lo demás el código es funcionalmente equivalente al ejemplo que no usa JSX, solo que con una sintaxis mucho más cómoda y concisa.

En los ejemplos anteriores hemos creado un componente React pero no lo "hemos formalizado" en una clase propia. Habitualmente definiremos una clase por componente:

Antes hemos visto que this.props representa los datos del componente, tal y como los podemos pasar en "formato HTML". Con la llamada del API setProps(props) podemos añadir o cambiar los valores. Por ejemplo podríamos hacer algo como:

Donde el setTimeOut no tiene que ver con React, lo hemos usado para que se pueda ver inicialmente el título original y luego cómo cambia pasado un segundo.

Lo interesante de React es que nosotros simplemente cambiamos los datos y automáticamente se redibujará la interfaz de la manera más eficiente posible. Podemos usar las herramientas de medición de rendimiento de React (React.addons.Perf) para comprobar qué está haciendo para actualizar la interfaz:

Para poder usar las herramientas de medición de rendimiento hay que incluir el script react-with-addons.js en lugar del react.js original.

Con las llamadas a start() y stop() comienza y termina el bloque de código en que queremos las medidas. Una vez ejecutado el stop podemos ver distintas tablas de rendimiento, por ejemplo printDOM() imprime las modificaciones que React ha tenido que hacer en el DOM para actualizar la interfaz (figura 1). Nótese que solo ha modificado el elemento necesario, no el resto.

Podemos construir componentes de "alto nivel" que agrupen componentes ya creados, por ejemplo supongamos que nos interesa crear un componente React para representar la portada de un libro. Así, una instancia del componente Libro contendría una instancia del componente Portada:

Como los componentes "hijos" heredan las propiedades del padre, podemos cambiar simplemente las "props" del padre para forzar el re-renderizado de toda la estructura, aunque como antes solo se redibujarán las partes que cambien. Por ejemplo podríamos hacer desde la consola Javascript:

Y mediante las performance tools de React podríamos comprobar que únicamente se está modificando el atributo src de la etiqueta img:

Uno de los casos de uso más habituales en componentes que encapsulan otros es cuando tenemos uno que engloba una lista de componentes de otro tipo. Por ejemplo un componente ListaLibros que englobaría un conjunto de Libro. En este caso el método render del padre debe ir creando los componentes "hijos" de manera dinámica, vamos a ver cómo:

Este es el caso más sencillo, tenemos un componente y queremos asociarle un modelo de Backbone. Al definir el componente, en el método render los atributos del modelo estarán accesibles a través de propiedades de state del mismo nombre. Por ejemplo:

Si cambiamos el modelo, el mixin disparará un re-rendering automáticamente.

Además de solo a los atributos podemos acceder al modelo completo con el método getModel(). Así, podríamos haber implementado el render como:

Vamos a ver el mismo ejemplo de antes de la colección de libros, pero ahora usando un modelo de Backbone para almacenar los datos de un libro y una colección para almacenar la lista de libros.

El mixin que hemos usado se ocupará de que cuando cambie algún modelo de la colección el componente se redibuje automáticamente. No obstante, también podríamos gestionar manualmente la comunicación, como se hace por ejemplo en este artículo. Además del mixin que hemos usado aquí, hay algunas otras implementaciones alternativas.

Podemos definir partes variables en una ruta poniéndoles un nombre precedido del símbolo ':'. La función Javascript asociada a la ruta recibirá tantos parámetros JS como partes variables tenga la ruta.

Podemos poner varias partes variables en una ruta. La siguiente ruta encajaría con #hola/Pepe/Pérez.

Para especificar alguna parte como opcional la pondríamos entre paréntesis:

En el ejemplo anterior, la ruta encajaría tanto con #hola/Pepe/Pérez, como simplemente con #hola/Pepe. En este último caso, el parámetro Javascript asociado a los apellidos sería null.

Las partes variables de las rutas se tratan al estilo de las expresiones regulares. Por ejemplo podemos poner una parte fija mezclada con la variable, o usar el símbolo * para indicar cualquier secuencia de caracteres. Esto último es útil si queremos recoger un path completo, o sea una cadena que contenga también el carácter /.

La ruta #hola/Pepito encajaría con la primera expresión, por lo que la variable adquiriría el valor ito. Si fuéramos por ejemplo a #adios/mas/cosas/por/aqui, el parámetro JS asociado a la variable var tomaría el valor mas/cosas/por/aqui

Es conveniente definir un par de rutas por defecto en cualquier aplicación: la ruta vacía '', que se usa cuando el hash fragment está vacío, y *default, que se usará con la URL actual si esta no encaja con ninguna de las definidas en el router.

En cualquier momento podemos navegar a una URL determinada con el método navigate de la clase Router:

Esta operación añadirá la nueva URL al historial del navegador. No obstante, navegar a una URL por defecto no disparará la función asociada a la ruta correspondiente, salvo que lo especifiquemos con {trigger:true}

Al contrario, podemos detectar en nuestro código que se ha disparado una ruta determinada respondiendo a los eventos con prefijo route:. El nombre completo del evento se obtiene añadiendo a este prefijo el nombre de la función asociada. Por ejemplo:

Usar una URL con hash fragments simplifica la gestión para Backbone, ya que en realidad no estamos cambiando de página. Pero puede parecer "algo rara" para el usuario. Podemos configurar Backbone para usar URLs convencionales, pero hay que solucionar dos pequeños problemas:

Al igual que en cualquier herramienta de tipo xUnit, las pruebas se escriben como casos de prueba y estos se agrupan en *suites*. No obstante la sintaxis es algo distinta a la tradicional en xUnit.

Para empezar, las pruebas no se suelen llamar tests sino specs (de "especificaciones"). Así, es habitual colocar el código de prueba en archivos con sufijo spec.js, en lugar del que sería más "tradicional" test.js.

Las suites se definen con describe, seguido de una cadena con la descripción de la suite y una función que encapsula todo su código. Cada caso de prueba (cada spec, por seguir la terminología habitual) se define de manera similar, usando la palabra it.

Como vemos, la idea de esta estructura es que quede clara cuál es la intención de cada suite y de cada caso de prueba. Las "etiquetas" de texto de describe e it sustituyen a los nombres de los métodos de test en xUnit, que si quereremos que sean descriptivos resultan engorrosos (testLibroRecienCreadoNoDeberiaEstarPrestado).

Las suites de pruebas pueden contener a su vez otras suites.

En el mundo xUnit las comprobaciones sobre el código se suelen hacer con assert. En cambio en BDD se suele usar la forma expect (que indica que esperamos determinado resultado, o que se cumpla determinada condición). Los partidarios de esta sintaxis defienden que mejora la legibilidad de las pruebas al hacer la sintaxis más similar a la del lenguaje natural.

Las expectativas se construyen con expect sobre una expresión, que es el valor real que queremos comprobar. El expect se encadena con el valor deseado a través de un matcher. El más sencillo es el de igualdad, toBe, equivalente a comprobar si el valor real es == al deseado.

Como vemos en el ejemplo, not se puede usar antes de cualquier matcher para invertir el sentido.

Jasmine tiene un amplio conjunto de matchers para comprobar si dos valores primitivos son iguales (el toBe que ya hemos visto), si lo son dos objetos (toEqual), si una cadena encaja con una expresión regular (toMatch), si un valor es undefined (toBeUndefined), o null (toBeNull), si un array contiene un valor (toContain),…​ La documentación de Jasmine contiene numerosos ejemplos.

Podemos ejecutar código para preparar las pruebas, bien antes de la suite (beforeAll) o bien antes de cada prueba (beforeEach). Igualmente podemos ejecutar código de "limpieza" cuando acabe la suite (afterAll) o después de cada prueba (afterEach)

Podemos bajar un .zip con la versión actual de Jasmine de la página con las releases, del repositorio en Github.

Al descomprimirlo veremos en la raíz un archivo specRunner.html. Es una plantilla que nos puede servir de base para ejecutar nuestras propias pruebas. Básicamente en el runner tenemos que cargar varias cosas:

En nuestro caso, el JS incluido en el spec runner sería algo como:

Una de las ventajas fundamentales de usar un framework MVC como Backbone es que nos hace separar modelo y vista. Entre otras cosas esto nos va a facilitar los tests de lógica de negocio, que básicamente tendrán que tratar únicamente con modelos y colecciones.

Las pruebas "puras" de lógica de negocio no tienen nada de particular, simplemente usamos el API de Jasmine para formular expectativas sobre el código:

Una de las cosas de las que hay que asegurarse en una vista es que genera el HTML correcto. Más que comprobar si el HTML es literalmente igual a una cadena de referencia en general será más sencillo simplemente comprobar si contiene determinados elementos. Podemos usar un plugin llamado jasmine-jquery para facilitar esta tarea. Este plugin define un gran número de matchers con los que podemos chequear de manera sencilla el contenido del HTML usando selectores de jQuery.

Por ejemplo, vamos a comprobar que el widget genera correctamente el HTML en su estado inicial. Podemos ver que los matchers de jasmine-jquery son bastante autoexplicativos.

Una ventaja de las vistas de Backbone es que son autocontenidas, es decir, que el HTML se genera dentro del el y que para comprobar que es correcto no es necesario insertar la vista en el DOM de la página. De este modo no tenemos que tocar el HTML del runner de los test para probar la parte de la interfaz.

En muchas ocasiones, más que comprobar el valor de una variable o el valor de retorno de una función nos interesará saber si una determinada función ha sido llamada correctamente (el número de veces que debería, con los parámetros adecuados, etc.). Esto es necesario cuando estamos probando un método que se llama desde otra parte de nuestro código.

En testing en general se suelen tratar estos casos usando mocks. El nombre que reciben en Jasmine es spies, por motivos evidentes.

Un caso de uso típico en vistas de Backbone es comprobar que los eventos del DOM sobre la vista disparan los callbacks adecuados. En el ejemplo del tiempo, comprobar que al pulsar sobre el botón de "ver tiempo" se llama efectivamente a la función ver_tiempo_de: