Ya sabéis lo que tiemblo ante los cambios introducidos en Phoenix Framework, no es la primera vez que un cambio nos obliga a cambiar completamente la forma con la que trabajamos con Phoenix Framework, así que ahora, con la publicación de las novedades de Phoenix 1.8, ¿qué podemos esperar? ¿qué cambios hay?
Voy a basarme en la publicación del 30 de marzo sobre el lanzamiento de Phoenix 1.8.0-rc, si quereis echar un vistazo al documento en inglés ahí está el enlace.
Lo primero es los requisitos, Phoenix 1.8 funcionará con Erlang/OTP 25+ y no se menciona versión mínima de Elixir, pero echando un vistazo a su Github el @elixir_requirement está configurado a la versión de Elixir 1.15. En mi opinión, son requisitos bastante conservadores y muestran la estabilidad tanto de Erlang (que lanzará pronto Erlang/OTP 28) y Elixir (que ya lanazaron Elixir 1.18).
TailwindCSS y DaisyUI
Con esta elección estoy algo dividido. Es decir, por un lado, en proyectos como el libro de Phoenix Framework he optado por incluir DaisyUI para facilitar a los programadores de backend el trabajo con la parte de frontend. Pero por otro lado, hay controversia con respecto a DaisyUI.
TailwindCSS llegó como una forma flexible de trabajar con estilos CSS sin tener que tocar otro fichero que no fuese HTML. Todo está junto con las etiquetas y es muy flexible. Se generan CSS muy ligeros. No hay grandes clases sino muchas clases pequeñas que lo hacen todo.
Este enfoque tiene dos posiciones:
- Por un lado permite gran flexibilidad a los diseñadores teniendo HTML y estilos en un mismo sitio.
- Por otro lado obliga a escribir una cantidad importante de clases dentro de cada etiqueta HTML.
DaisyUI viene como solución pero al mismo tiempo recuerda a la gente que huyó de Bootstrap, BulmaCSS y otros frameworks similares algo recurrente y similar. Es una vuelta atrás pero aún manteniendo la compatibilidad completa con TailwindCSS. Es más, puedes agregar DaisyUI en tu proyecto y utilizar únicamente TailwindCSS dejando DaisyUI solo para la configuración del tema (theme).
Creo que es un tema denso y en el que todos tienen algo que decir. Por mi parte, agradezco que DaisyUI venga integrada, pero me parece que requerirá un ajuste en el libro de Phoenix Framework.
Mejoras en autenticación
Otra facilidad más que se agrega al complemente phx_auth incluido en Phoenix Framework. Hablamos de la posibilidad de realizar un inicio de sesión sin contraseña, enviando un correo electrónico (email) al usuario donde incluimos un enlace con un token para iniciar sesión automáticamente.
Como dice el creador en el artículo, no sufras, esta es solo una opción, puedes usarla o no.
También se agrega el plug llamado require_sudo_mode. Este plug insta al usuario a introducir la contraseña antes de realizar una acción determinada. Por ejemplo, puede posicionarse en acciones muy sensibles como eliminar la cuenta, cambiar los datos del perfil o cualquier otra acción sensible desde el punto de vista de negocio de tu aplicación web.
Más cambios en la parte de autenticación. Ahora con scope se permite asignar recursos al alcance y estos alcances a los usuarios, de modo que los usuarios tengan acceso a recursos de la organización, grupo, equipo o simplemente compartidos entre los miembros del alcance concreto.
Simplificaciones en LiveView
Sí, la generación de phx.gen.live eran algo tediosas y muchos dieron feedback al equipo de Phoenix para simplificar tanto core_components.ex como la generación de estos ficheros.
Tengo que decir que me fastidia un poco porque en el libro expliqué y utilicé la versión extensa pero también tengo que admitir que la nueva versión es mucho más sencilla y se entiende mucho mejor, así que es un gran cambio, muy positivo.
Otra gran simplificación ha sido la de los layouts. Hasta ahora siempre teníamos root.html.heex como la plantilla base siendo una plantilla estática y app.html.heex la plantilla dinámica. Ahora la plantilla estática sigue siendo root.html.heex pero la plantilla dinámica es opcional.
También se han agregado miguitas de pan (breadcrumbs) que pueden indicarse con <Layouts.app breadcrumb="..."> dentro del código HTML. Igualmente se debe pasar <Layouts.app flash={@flash}> a la etiqueta que rodeadrá nuestro código HTML para incluir el layout de app.html.heex.
@impl true
def render(assigns) do
~H"""
<Layouts.app flash={@flash}>
<:breadcrumb>
<.link navigate={~p"/posts"}>All Posts</.link>
</:breadcrumb>
<:breadcrumb>
<.link navigate={~p"/posts/#{@post}"}>View Post</.link>
</:breadcrumb>
<.header>
Post {@post.id}
<:subtitle>This is a post record from your database.</:subtitle>
<:actions>
<.link class="btn" navigate={~p"/posts/#{@post}/edit"}>Edit post</.link>
</:actions>
</.header>
<p>
My LiveView Page
</p>
</Layouts.app>
"""
end
Conclusiones
Eso es todo, al parecer. Seguramente se incluyan otros cambios hasta el momento de publicar definitivamente la versión 1.8 pero podemos ver que ya hay cambios que marcan nuestro código actual como legacy, ya tenemos deuda técnica que resolver, así que te dejo que vayas revisando la documentación y creando tus tareas a futuro para cuando haya que hacer el mantenimiento evolutivo de tu aplicación web. Cualquier cosa, ya sabes que puedes comentar, comprar algún libro como el de Phoenix Framework y mantenerte al tanto de las noticias del boletín. ¡Saludos!
