Experimentando con Elm en el trabajo

Llevo cuatro años trabajando como desarrollador full stack en una empresa cuyo producto principal es un SaaS, es decir, una aplicación web. En este tiempo la compañía ha cambiado varias veces de estrategia y eso también ha impactado el plano técnico. En una de esas ventanas de cambio vi la oportunidad de proponer mi tecnología favorita para el front end: Elm.

Al final los planes tomaron otro rumbo y hoy Elm no se usa en la empresa, pero igualmente quiero compartir la experiencia de haber preparado una propuesta real de integración de Elm dentro de un sistema preexistente. Lo que sigue asume conocimiento básico del lenguaje y algo de experiencia en front end.

El experimento nació tras conversar con el ingeniero principal, quien me sugirió migrar una pieza pequeña como prueba de concepto. Elegimos una página interna, el explorador de usuarios, usada por soporte y el área comercial para revisar y corregir datos de clientes. No es una pantalla muy concurrida y además era lenta, así que era una candidata ideal por el bajo riesgo y el alto potencial de mejora.

Como parte del experimento hice pair programming algunos días con dos colegas para que conocieran Elm y pudieran opinar con criterio ante el resto del equipo. Se unieron cuando ya tenía casi todo armado, y luego ambos dejaron la empresa por motivos ajenos al proyecto, lo que fue un pequeño contratiempo. El resto del trabajo lo avancé en semanas de cooldown entre iniciativas y algún fin de semana.

Integración con Webpack

El entorno legacy era un monolito en PHP, con Vue en ciertas secciones, y el JavaScript empaquetado con Webpack. Integrar Elm fue directo usando elm-webpack-loader. Creé un punto de entrada llamado main.js que inicializa la aplicación Elm con sus flags y puertos, y lo añadí como entry en la configuración de Webpack. En la página se añadió una etiqueta script que carga el bundle generado y un contenedor con un id para montar la aplicación.

La organización de carpetas quedó así, a grandes rasgos, permitiendo múltiples miniaplicaciones Elm bajo elm Entrypoint nombre, cada una con su propio punto de entrada y rutas: Api para comandos a la API, Data para tipos, Entrypoint con submódulos que incluyen Route con módulos por ruta, Main.elm como entrada de Elm, Route.elm con el tipo de ruta, y un main.js para Webpack; además Util con utilidades, View con componentes, Layout.elm con constantes de vista, Ports.elm y ports.js para los puertos, y Run.elm como envoltorio de Browser.element.

El archivo elm.json quedó en la raíz, con elm configurado en source-directories. Cada main.js dentro de Entrypoint inicializa su Main.elm correspondiente, le pasa flags y conecta los puertos mediante una función exportada desde ports.js.

Puertos para enrutar

La funcionalidad reconstruida abarcaba dos pantallas: listado de usuarios y detalle con edición de un usuario. Por eso necesitábamos navegación con comportamiento de single page application, aunque solo fueran dos rutas.

En una app Elm independiente lo normal es usar Browser.application, que expone onUrlRequest y onUrlChange. Aquí no era viable porque Browser.application toma control de toda la página y nosotros solo incrustamos Elm en una sección, con menús y otras partes fuera de su control. Opté por Browser.element y resolví la navegación con puertos. Del lado de JavaScript escuché el evento popstate de window para detectar cambios en la URL y enviar mensajes a Elm, y a la inversa, Elm pedía cambios de ruta usando window.history.pushState. Con esto también sincronizamos parámetros de búsqueda tipo param=value.

Definí dos puertos, uno de entrada y otro de salida, ambos enviando un mensaje con dos campos: una etiqueta kind para identificar el tipo de evento y un payload value que se decodifica con decodificadores JSON. Este patrón es común en la comunidad Elm porque hace los intercambios estrictos y fáciles de extender.

Manejo centralizado de rutas

Para simplificar la creación de miniaplicaciones, envolví Browser.element en una función Run.elementWithFlagsAndRoute. Esta función centraliza la decodificación de flags, gestiona los puertos del enrutamiento y ofrece un punto único para reaccionar a cambios de URL. Para interpretar la URL usé lydell elm app url. Si el decodificador de ruta devuelve Nothing entendemos que es una navegación externa y dejamos que el navegador cargue el recurso.

La función routeChanged es similar a update, pero específica para cambios de ruta: guarda la ruta en el modelo, inicializa el submodelo y puede disparar comandos de carga de datos propios de la ruta activa. Este enfoque es manual pero explícito, y funciona bien cuando el enrutado se resuelve desde fuera de Elm mediante puertos.

Arquitectura Elm anidada

Definí un módulo Entrypoint nombre Main por miniaplicación, responsable del estado global y de orquestar las rutas. Usé una arquitectura Elm anidada: Main delega en init, update y view de cada ruta, implementadas en módulos Entrypoint nombre Route nombre.

Si lo hiciera de nuevo, separaría con claridad un modelo global compartido y un modelo por ruta. En esta prueba trabajé con un único modelo central y, en cada ruta, utilicé registros extensibles para que cada submódulo solo viera las partes del modelo que le incumbían, como usuarios o apiConfig. Esta técnica reduce acoplamiento pero exige disciplina al limpiar estado al cambiar de ruta y a veces obliga a repetir campos en el modelo global y en el de la ruta.

El tipo Route distinguía entre listado con una consulta y detalle con un identificador. En el update de Main mapeaba de manera explícita la dupla ruta y mensaje hacia el update de cada submódulo, encajando también los comandos con Cmd.map. Esta repetición también aparece en init y view. Hay maneras de factorizar, pero la verbosidad es el coste típico de anidar arquitecturas Elm y una de las razones por las que no siempre se recomienda.

Cierre

Aunque la integración no llegó a producción, el ejercicio demostró que incrustar Elm en un monolito con Webpack y manejar el enrutamiento mediante puertos es totalmente viable. En un próximo texto me gustaría contar cómo organicé la vista, la creación de componentes y su documentación con ElmBook, incluyendo patrones reutilizables y pruebas visuales.

Referencias útiles: SaaS, Webpack, elm webpack loader, elm browser, evento popstate en MDN y pushState en MDN.