Año nuevo, raíles nuevos

El comienzo de un nuevo año suele considerarse el momento de reinventar la self. Abonarse al gimnasio, comer de forma más sana, aprender un nuevo idioma, etcétera. Nunca me han gustado mucho los propósitos del tipo "año nuevo, tú nuevo", pero basándome en las primeras impresiones, sí que me gusta "año nuevo, Rails nuevo".

Vale, esa parte de "año nuevo" no es del todo exacta; Rails 7.0 salió a finales del año pasado, el 15 de diciembre. Ya hemos tenido una versión 7.0.1 para dar soporte a Ruby 3.1. Sin embargo, la parte de "nuevo Rails" parece acertada. Una gran actualización de versión siempre trae consigo una sensación de novedad, pero Rails 7.0 va más allá. Parece un cambio atrevido y emocionante respecto a versiones anteriores.

Durante los primeros años de Rails, su uso de la convención por encima de la configuración, y los valores predeterminados en términos de herramientas y componentes, fue considerado algo controvertido. Estos principios clave del enfoque Rails, que finalmente formaron parte de Doctrina Railsfueron también los que atrajeron a muchos desarrolladores al framework. Por supuesto, había que acostumbrarse a los valores por defecto y aprender las convenciones, pero una vez hecho esto, era un placer trabajar con Rails. Este enfoque general apoyaba el primer pilar de la Doctrina Rails: Optimizar para la felicidad del programador.

Uno de los puntos fuertes de Rails como framework ha sido su capacidad para evolucionar con el cambiante panorama tecnológico. En los últimos años, gran parte de este cambio se ha producido en el front-end, donde el deseo de interfaces reactivas ha llevado al auge de las Single Page Applications (SPAs) y al consiguiente desplazamiento de la lógica de la aplicación desde el servidor hacia el cliente. Una de las consecuencias de este cambio fue la complejidad añadida al proceso de desarrollo del front-end en términos de gestión de dependencias, transpilación, agrupación de activos, etcétera. Desde Rails 5.2, la respuesta a esta complejidad del front-end ha sido Webpacker.

¿Suscita alegría Webpacker?

Aunque Webpacker eliminaba parte de la complejidad de gestionar las dependencias y la configuración del front-end, siempre ha parecido una solución provisional, aunque necesaria. Era una forma de conectar una aplicación Rails al ecosistema de front-end existente más que una solución de front-end incorporada. Genial cuando todo funcionaba, pero aún así podías acabar teniendo que lidiar con algunos complejos problemas de dependencias de paquetes Node o depurar diversos errores de compilación -- probablemente no el tipo de cosas a las que la mayoría de los desarrolladores Rails quieren dedicar demasiado tiempo.

Parece que el equipo de Rails ha adoptado el enfoque de enfoque Marie Kondo a Webpacker porque, en Rails 7, ha desaparecido. En detrás de este movimiento se basa en los recientes avances en la web y el entorno de Internet en general, a saber, el soporte universal de ES6 por parte de los navegadores y la adopción generalizada de HTTP/2. El primero elimina la necesidad de transpilar código ES6 para convertirlo en ES6. El primero elimina la necesidad de transpilar código ES6 a ES5, y las capacidades de multiplexación del segundo mitigan el impacto de la latencia al solicitar varios archivos pequeños en lugar de un gran "paquete".

Así que puede que estés pensando, "pero aún necesito todos mis paquetes Node, ¿cómo los consigo?". La respuesta es mapas de importacióncombinados con CDNs que puedan servir módulos ES, como Skypack o JSPM. Esta combinación elimina la necesidad de herramientas de compilación o incluso de tener Node instalado localmente. La gema importmap-rails gemaincluida por defecto en Rails 7, básicamente mapea 'especificadores de módulo desnudos' a una fuente para cargar ese módulo. La configuración del mapa de importación se establece en un archivo config/importmap.rb . Los módulos específicos se solicitan en tiempo de ejecución a medida que los diseños los necesitan mediante una etiqueta <script> etiqueta de tipo "importmap" en la etiqueta <head> de ese diseño. ¡Impresionante!

Este enfoque no va a funcionar para todo el mundo. Algunos desarrolladores van a querer usar React con JSX o usar Typescript, por lo que seguirán necesitando un paso de compilación/transpilación y la capacidad de engancharse al ecosistema Node. Pues bien, esto todavía se puede hacer en Rails 7. La gema jsbundling-rails gema nos permite utilizar esbuild, rollup.js o Webpack para empaquetar nuestro JavaScript y entregarlo a través de la canalización de recursos en Rails.

Aunque algunos desarrolladores van a seguir queriendo utilizar ese tipo de enfoque dividido entre front-end y back-end, el mensaje de Rails 7 es que para la mayoría de los casos de uso, no necesariamente se necesita algún tipo de framework front-end pesado o un montón de JavaScript personalizado en el front-end para proporcionar una experiencia de usuario reactiva en el navegador. Podemos ofrecer esa experiencia utilizando una arquitectura de aplicaciones mucho más unificada mediante el uso de Hotwire.

Hotwire es Rails-y

Hotwire no es completamente nuevo -podría utilizarse en Rails 6 con algunos ajustes- pero ahora es el enfoque por defecto en Rails 7. Hotwire, desarrollado por los equipos de Basecamp y Hey, se compone de tres bibliotecas: Turbo, Stimulus y Strada, aún por lanzar.

Turbo

Turbo hace la mayor parte del trabajo pesado. Utiliza el renderizado del lado del servidor (SSR) para enviar HTML a través del cable en lugar de JSON, eliminando así la necesidad en el front-end de renderizado, gestión de estados, etc. Turbo combina varios conceptos y técnicas complementarios.

• Accionar: Intercepta los clics en los enlaces y los envíos de formularios, emite una fetch para el nuevo contenido y muestra la respuesta HTML.

• Marcos: Permite dividir una vista en partes o componentes individuales para que los clics en enlaces o el envío de formularios actualicen sólo partes específicas de la página web en lugar de realizar una recarga completa de la página.

• Flujos: Ofrece actualizaciones parciales de la página en respuesta a acciones asíncronas enviadas a través de WebSocket o un evento enviado por el servidor.

Puede que todo esto suene a funcionalidad SPA estándar. La diferencia clave de Turbo es que la lógica de toda esa capacidad de respuesta del front-end no se divide en un marco separado atornillado en la parte frontal de la aplicación Rails. En lugar de eso, se encuentra en los modelos, vistas y controladores de Rails, utilizando convenciones claras, lógicas y elegantes.

Este artículo no pretende ser un tutorial, por lo que no voy a entrar en los detalles de estas convenciones aquí, pero asegúrese de revisar el Turbo Handbook y referencia para desarrolladoresasí como el archivo LÉEME de la implementación de Turbo en Rails, turbo-rails.

Estímulo

Stimulus se presenta como un "framework JavaScript con ambiciones modestas" y pretende complementar a Turbo. Se basa en gran medida en atributos de datos HTML, utilizando objetos JavaScript llamados controladores para responder a los eventos del navegador disparados por elementos con un atributo data-controller o la asignación de acciones específicas a eventos DOM mediante atributos data-action atributos. No voy a entrar aquí en detalles, pero puedes encontrar más información en el Stimulus Handbook, referencia para desarrolladoresy el archivo LÉEME de la implementación Rails de Stimulus stimulus-rails.

Hotwire está diseñado para ser agnóstico en cuanto a marcos de trabajo. Pero tiene mucho sentido en un contexto Rails, especialmente dada la forma en que las implementaciones Rails de las librerías se integran con . ActiveRecord. Por ejemplo, podemos utilizar un broadcasts_to en nuestros modelos para configurar varias retrollamadas que se publiquen en un determinado canal, por ejemplo :todo_listcuando se produzcan cambios en los datos dentro del contexto de ese modelo (por ejemplo, mediante acciones de creación, actualización o destrucción).

class Todo < ApplicationRecord
  broadcasts_to :todo_list
end

A continuación, puede configurar los elementos del Turbo Stream para que se suscriban a la :todo_list difusión. Estos elementos se actualizarán cuando se produzcan cambios en los datos. Cualquiera que visualice una página que contenga un elemento de flujo suscrito a esa emisión concreta verá cómo su navegador actualiza ese elemento de la página en tiempo real.

Esta funcionalidad utiliza ActionCableque es un componente de Rails desde hace mucho tiempo. Lo que hace turbo-rails es conectarlo todo de forma lógica y accesible.

Para mí, lo mejor de Hotwire es que se siente como Rails. Abstrae gran parte de la complejidad del front-end mediante un enfoque innovador y algunas convenciones sólidas. Esa ha sido siempre la forma de hacer las cosas en Rails, y su integración en Rails 7 parece que se adhiere mucho más a la doctrina Rails de lo que podría hacerlo el compromiso de Webpacker.

Otros aspectos destacados

Aunque el cambio que más llama la atención en Rails 7 es el nuevo enfoque por defecto para trabajar con el front-end, también hay algunos cambios notables en términos de back-end. Los más interesantes tienen que ver con varios aspectos del trabajo con datos.

• Active Record Encryption proporciona una capa adicional de seguridad añadiendo atributos cifrados a ActiveRecord.

• La carga paralela de consultas ofrece mejoras de rendimiento en situaciones en las que las acciones del controlador deben cargar varias consultas no relacionadas de forma simultánea.

Personalmente, estoy muy entusiasmado con Rails 7 y espero poder crear cosas interesantes este año utilizando Rails 7 y las APIs de Vonage. Me encantaría conocer tu opinión sobre Rails 7. Házmelo saber en Twitter.