Dentro del Manual de Backbone estamos describiendo todas las clases que componen este framework Javascript. Ahora le toca el turno al ruteador y además acabaremos esta parte teórica del manual describiendo también las clases "History" y "Sync".

Las rutas "route" de BackboneJS nos sirven para manejar las URLs de la aplicación, es decir, saber cuál es la dirección en la que estamos y poder actuar de maneras distintas dependiendo de ellas.

Para explicarlo bien, vamos a comenzar con un ejemplo sobre cómo manejaba las URLs anteriormente Twitter. Aunque hoy ya no nos muestra URLs como esta, todavía siguen funcionando perfectamente: https://twitter.com/#!/erickrdch

Los navegadores cuando reciben una URL que incluye el signo "#" (almohadilla, gato, numeral) entienden que es una referencia a un área determinada dentro de la página definida por lo que hay antes de la almohadilla. Si cambiamos lo que hay después de la "#" no navegan a una nueva URL, sino que llevan la página hacia arriba o hacia abajo para mostrarnos otra zona de la página. Esto no debe ser nada nuevo para los lectores, pues es justamente lo que ocurre con los enlaces internos, hacia otras partes de la misma página.

Javascript, y en concreto BackboneJS, se valen de este comportamiento para producir lo que se llaman "deep links" o sea, enlaces a una parte interna y específica de tu aplicación.

Para que entendamos para qué nos sirve esto de los "deep links" pensemos en otro ejemplo. Imagínate que tienes una rejilla, tabular, o si lo prefieres llámale sencillamente tabla con datos ("table grid" se suele usar en Inglés). Si pulsas sobre una de las líneas de esa rejilla, imagina que entras en la edición del registro que había en esa línea y Javascript te la transforma para mostrar un formulario donde puedes modificar los datos. Pues bien, generalmente, por medio de una URL simple no vas a tener la posibilidad de acceder directamente a ese estado de tu aplicación, es decir, podrás entrar en la página que muestra el table grid, pero no vas a poder especificarle a tu aplicación que quieres que te muestre directamente una línea determinada "abierta para edición".

Un enlace profundo es justamente para crear esas URLs en las que estás accediendo directamente a un estado complejo y determinado de tu aplicación. Vamos a suponer que tengo misitio.com que muestra esta lista de usuarios en un table grid. Si tú haces misitio.com/usuario/23 te estoy dando una forma de mostrar la aplicación donde directamente verás la rejilla con todos los usuarios y donde puedas ver directamente el formulario para edición del usuario 23.

Cómo trabaja BackboneJS con los deep links

BackboneJS captura estas diferencias o cambios en las URLs, cuando se usan enlaces profundos, para poder realizar cosas específicas que se deseen implementar por medio de los deep links.

Volvemos a lo mismo de siempre, Backbone.JS utilizará los eventos para permitir que las diferentes partes de la aplicación se enteren que ha cambiado la URL y se sepa qué características tiene el nuevo enlace y poder realizar los cambios oportunos en los modelos, colecciones o vistas.

Lo genial de esto es que podrás usar enlaces dentro de tu aplicación web que vayan siempre a la misma página, con lo que tu navegador no la actualizará nunca. Esto produce lo que conocemos como aplicaciones web de una sola página, que se comportan parecido a las aplicaciones web de escritorio y que tienen un desempeño mucho mejor. Sin embargo, el detalle es que la URL siempre va cambiando, de modo que si un usuario guarda en favoritos tu aplicación, en un estado determinado, lo que está guardando es el "deep link", de modo que cuando vuelva a entrar en la aplicación, se le abrirá mostrando el mismo estado donde había sido guardada.

Esto de los deep links te vale para un gran abanico de situaciones, como por ejemplo cuando el usuario copia y pega el enlace actual para mandarlo por e-mail o tuitearlo, por ejemplo. Podrá mandar, no solo el enlace a la "home" de tu sitio, sino también a una sección o un estado concreto, lo que le aporta un gran valor a tu aplicación.

History API de HTML5, los deep links y la almohadilla o hash

En estos momentos en la mayoría de los navegadores no es necesario siquiera usar la almohadilla (gato, numeral o el símbolo "hash" como le llaman en inglés). Esto es porque ahora los navegadores modernos soportan lo que se llama "Session history management" o "History API" del HTML5, que nos permite cambiar la URL de la barra de direcciones del navegador, pero sin que éste actualice la página.

Por medio de pushState() tenemos un método que nos permite cambiar la dirección que se está mostrando en nuestro navegador mediante Javascript, pero sin que se realice una recarga del contenido que ya se está mostrando en el navegador. Pero además, este método trabaja directamente con el historial del navegador, de modo que podemos pulsar los botones de atrás y adelante del navegador y podemos retroceder y avanzar entre los distintos estados de la aplicación. Incluso podemos guardar ese estado en los favoritos perfectamente.

Pues bien, BackboneJS tiene la capacidad de trabajar con el pushState() en navegadores que lo soporten y en los casos en los que no hay compatibilidad, usar el viejo método de la almohadilla y los enlaces internos en la misma página, lo que produciría el mismo efecto. En la práctica, el uso de los hash ya no es necesario y paulatinamente va a ir desapareciendo en las aplicaciones web, en la medida que podemos producir los mismos comportamientos con URLs corrientes que no la contienen.

Router de BackboneJS

Realmente todo esto se hace de manera muy transparente para el desarrollador, por medio del "ruteador" de Backbone.JS, la clase Route. Simplemente tienes que cambiar la dirección por medio de la mencionada clase Route y el framework ya se encarga de todo, es decir, ya te cambia la URL y gestiona el historial del navegador de modo que puedas ir hacia atrás y adelante entre los diferentes estados de tu aplicación.

Afortunadamente, como decíamos, en caso que el navegador no soporte el API History del HTML5, Backbone empieza a utilizar el hash de modo automático.

¿Las rutas son como los controladores del MVC?

Recordemos que BackboneJS cambió un poco el paradigma, o al menos la manera de referirse a los típicos MVC por MVR. O sea, cambió los "Controller" por "Route", pero ¿qué tienen que ver los unos con los otros?

Las diferencias dependen mucho del framework o librería que se esté usando. Pero en líneas generales, un Controller se encarga de la lógica de negocio, mientras que el Router es algo más sencillo, porque simplemente se encarga de dirigir las peticiones o las acciones de los usuarios a los lugares concretos donde está el código que tiene que realizar lo que se solicita. Si lo quieres ver así, el Router es como una manera de recibir parámetros, que te indican qué es lo que quieres hacer en ese momento o qué estado de la aplicación debe mostrarse.

En cierto modo, el ruteadores de backbone es algo parecido a los controladores que podemos conocer en los sistemas MVC, en el sentido que los controladores permiten generar URL de tu aplicación que realmente no existen como archivos dentro de tu hosting, sino que son gestionados por el software para emular que esas páginas están físicamente en el servidor.

Gracias a BackboneJS gestionamos esas rutas como si fueran URL que existen físicamente en el servidor, aunque esos archivos realmente no se encuentren. Todo esto no es gratuito, es decir, implica que tendremos que configurar nuestro Apache, o el servidor web que estemos usando, para que interprete esas rutas y las redireccione hacia archivos que sí que existan físicamente, pero de manera transparente para el navegador. Todo eso se verá más adelante, pero si conoces los MVC seguramente ya sepas por dónde van los tiros.

History en BackboneJS

Para poder finalizar con la descripción de las clases disponibles en Backbone, tenemos que mencionar, el History y el Sync.

History es otro de los módulos de Backbone.JS de los que hemos hablado ya de pasada al describir el funcionamiento de los Route. Realmente, es la parte de Backbone que permite gestionar el historial del navegador, de modo que puedas ir pasando entre secciones de tu aplicación y que se vayan guardando en el historial de navegación.

Hemos dicho que esto lo hace BackboneJS de manera automática, pero además tienes una interfaz de código para poder hacer cosas adicionalmente a las que ya hace el framework por si solo.

Sync en BackboneJS

Es simplemente la comunicación de las colecciones y modelos con el lado del servidor, que permite hacer llamadas para leeer o guardar estados de los datos en el servidor. Todo, por supuesto, por medio de AJAX, usando el método jQuery.ajax y JSON como formato de datos para la comunicación cliente/servidor.

Existe un modelo estándar implementado en Backbone que nos facilita mucho la sincronización de los datos, pero también si tienes un sistema diferente, de manera sencilla puedes implementar esa pasarela de escrituras y lecturas desde el cliente al servidor.

Conclusión

Hasta aquí hemos conocido Backbone.js desde un punto de vista puramente teórico. Esperamos que con la información ofrecida hasta el momento hayamos podido entender bien qué es lo que ofrece este framework y hacernos a la idea de las ventajas que nos puede proporcionar el utilizarlo.

Aunque esta información todavía debería complementarse con explicaciones más técnicas sobre la implementación de las diferentes clases que componen BackboneJS, creemos que resulta imprescindible para entender más adelante cómo se usa el framework.

En los próximos artículos nos dedicaremos a conocerlo más a fondo y a realizar un ejercicio práctico que nos permita ver algo de código y entender cuáles son los mecanismos para el desarrollo de sitios basados en BackboneJS.