Mejorar la experiencia de desarrollo para FacturaScripts 2023

Hemos comenzado el desarrollo de FacturaScripts 2023 en la rama new-engine del repositorio en github.

Al contrario que con FacturaScripts 2018, este no será un rediseño desde cero, sino simplemente una actualización un poco más grande de lo habitual, pero sin romper demasiado. Y digo demasiado porque obviamente romperemos compatibilidad con algunas clases. El diseño del core no es lo suficientemente robusto o flexible para poder añadir nuevas funciones sin tener que romper compatibilidad en algunas ocasiones. En la ayuda tienes precisamente una sección sobre migración de plugins antiguos, para puedas ver qué hay que modificar de una versión a otra.

Mejoras para la nueva versión

Antes de pasar a detallar los cambios que traerá la nueva versión, nos gustaría que te tomases unos minutos para meditar qué echas en falta en el core actual, a nivel de desarrollo, o qué cambiarías lo antes posible. En la nueva versión queremos facilitar el trabajo de todos los programadores, por lo que el feedback es importante.

Proponer cambios

Si tienes una propuesta concreta, puedes enviarla por cualquiera de estos medios:

• En nuestro discord, en el canal de programación.
• En el roadmap, añadiendo la sugerencia (abajo del todo).
• En soporte, y lo derivaremos al grupo de desarrollo.

Propuesta de ejemplo

Me gustaría que se añadiese la función trans() a twig, para no tener que estar llamando continuamente a i18n.trans() en las plantillas twig, y no tener que pasarlo como parámetro a las macros. Ejemplo de código:

{{ trans('save') }}

Rediseño de Core/App

Se ha sustituido toda la parte de Core/App por un nuevo kernel, más limpio, rápido y con manejador de errores integrado, lo que nos permite poder lanzar excepciones en cualquier clase y que el kernel reaccione con un controlador concreto, que podemos personalizar desde los plugins.

Este nuevo kernel nos permite, por ejemplo, no conectar a la base de datos a menos que sea necesario (porque algún modelo quiera leer datos). Si en ese momento no puede conectar con la base de datos, la propia clase Database lanza una excepción concreta, que recibe el kernel y carga el controlador específico, en este caso el DatabaseError, que muestra la plantilla html con el error en pantalla.

Este pequeño cambio nos abre muchas puertas, además de aumentar el rendmiento. Ya no tenemos que hacer comprobaciones en cada petición, ahora podemos cortar la ejecución en cualquier momento lanzando una excepción, que nosotros mismos podemos controlar. El código también queda mucho más limpio, solo hay que ver el nuevo index.php

Adiós a las constantes FS_XXX, hola Setup::get()

Tenemos el código plagado de llamadas a constantes como FS_FOLDER, FS_NF0, etc. Unas se definen en el config.php, otras las carga AppSettings, un lío. Además las herramientas de análisis de código muchas veces no encuentran dónde se definen y muestran errores. En esta nueva versión se ha añadido la clase Setup, que permite consultar estas constantes y también cargarlas desde el archivo config.php o bien desde variables de entorno, lo que abre la puerta a poder desplegar FacturaScripts en docker saltando el paso de la instalación y pasando los datos de configuración de la base de datos como variables de entorno.

Antes:

echo FS_TIMEZONE;

En 2023:

echo Setup::get('timezone');

Cambios en el manejo de la base de datos

A parte de no conectar a la base de datos a menos que sea necesario, solamente se comprobará y actualizará la base de datos cuando se instale o actualice. Hasta ahora cada vez que se inicializaba un modelo, se comprobaba la tabla correspondiente y se guardaba en una lista en caché, para no comprobar de nuevo cada vez. Pero la caché se refresca cada hora y de nuevo se volvía a comprobar la tabla. Para entornos pequeños nunca ha supuesto un problema, pero en entornos como megacity es un problema de rendimiento.

A partir de ahora la case DatabaseUpdater se encargará de comprobar y actualizar las tablas de la base de datos cuando se instala o actualiza (o cuando se pulsa reconstruir en el listado de plugins).

Nueva clase Session

Hasta ahora solamente el controlador tenía cargado el usuario que ha iniciado sesión. Si desde otra clase queríamos consultar algo del usuario, debíamos pasarlo como parámetro desde el controlador. Este es un limitante en muchos escenarios y a menudo obliga a cambiar la lista de parámetros de algunas funciones, rompiendo la compatibilidad con otros plugins. Con la nueva clase Session podremos consultar desde cualquier otra clase datos relativos al usuario que ha iniciado sesión, así como la IP, obtener o validar tokens para formularios, etc.

Trabajos en segundo plano

Existen muchas tareas que tenemos que ejecutar, pero que no son imprescindibles en ese momento. Por ejemplo, cuando hacemos un asiento, debemos recalcular los saldos de las subcuentas, pero no es imprescindible en ese momento, podríamos hacerlo después. Para este tipo de situaciones necesitamos una forma de poder ejecutar tareas "en segundo plano". Esta función todavía no está implementada.

Otros cambios

Aún faltan cosas por concretar, y recibir feedback de los programadores. No se espera romper demasiado la compatibilidad con esta nueva versión, pero si facilitar mucho el desarrollo. Quedamos atentos a vuestros comentarios y sugerencias ;-)