La innovación, nuestra razón de ser
Desde mi punto de vista, una de las tareas más tediosas y aburridas a las que nos tenemos que enfrentar cuando hacemos aplicaciones de frontend es al desarrollo de formularios. Por si fuera poco, es una tarea que nos va a tocar hacer una y mil veces. Pensando en ello, se trata, en realidad, de una tarea repetitiva y, por tanto, como ingenieros de software deberíamos encontrar soluciones que incrementarán nuestra productividad.
A lo largo de estos años en Divisa iT hemos tratado de resolver esta situación. Podría remontarme a cuando hacíamos aplicaciones con JSP e implementamos una librería de custom-tags o, más recientemente, con la implementación de un asistente para la creación de formularios ya basado, completamente, en el uso de JavaScript. Claramente todo esto nos ha proporcionado una visión integral del problema y de los mecanismos más adecuados para su resolución.
Cuando comenzamos a utilizar REACT el problema surgió, nuevamente, encima del tablero. Había que desarrollar formularios y, lógicamente, de forma eficaz. En función de la experiencia que teníamos, mi intención era evitar el mayor número posible de tareas repetitivas enfocándonos en una serie de objetivos clave:
Leyendo todo esto, podríais decirme que la solución que hemos creado iba a ser bastante dogmática (opinionated como dicen los ingleses). Si os soy sincero, cuando construís elementos reutilizables se deben tomar decisiones y eso, supone, que debe funcionar de forma concreta y acotada. A decir verdad, no conozco ninguna librería que no tenga un cierto grado de dogmatismo en sus propuestas.
En las siguientes secciones os voy a intentar contar como hemos dado respuesta a cada uno de los objetivos clave enumerados anteriormente.
Es un tema amplio y arduo con numerables aspectos a considerar, por ello sólo voy a citar algunos de los que considero como más importantes. En concreto:
La verdad es que si os poneis a desarrollar un formulario de cero, sin ayuda de ninguna librería, hay tantos aspectos que hay tener en cuenta que lo más probable es que os aburráis y que además cometáis errores.
Todo ello me llevo a tomar una serie de aproximaciones que, creo, nos permiten tener un desarrollo final conforme con las distintas normativas y especificaciones de accesibilidad. Citando sólo alguna de las medidas tomadas:
Para traducir etiquetas, ayuda y placeholders utilizamos internamente react-i18next. Sin que el desarrollador tenga, por tanto, que añadirlo o considerarlo de forma explicita en su proyecto. Todo ello facilita que el desarrollo se oriente a la generación del formulario y en la creación de un esqueleto o fichero base de traducciones.
La traducción real, ya la llevaría a cabo bien un tercero bien un API de traducción o incluso sistemas híbridos.
Tal y como os comenté antes, utilizamos TypeScript acompañado de una clara división de capas. ¿Cómo aplicamos esto desde el punto de vista de los formularios? Yo diría que teniendo en cuenta dos visiones complementarias.
Sinceramente, creo que hemos hecho un esfuerzo importante para mejorar la productividad tanto de nuestros desarrollados como la experiencia del usuario final. Me voy a centrar en cuatro aspectos fundamentales:
En primer lugar, nuestros componentes pueden personalizarse utilizando un atributo de ayuda. Siempre que el usuario se coloca encima de ese icono (o lo hace de forma accesible), se muestra una ayuda en pantalla.
En segundo lugar, algunas tareas como verificar si los datos de un campo cumplen con un determinado patrón, si el campo es requerido o si incluso existen dependencias con otros campos y como afectan éstas, se pueden controlar de una forma extremadamente sencilla.
Finalmente, cuando desarrollamos formularios en ocasiones tenemos que resolver algunas situaciones complejas.
Por una parte, podríamos tener que mostrar dos campos en pantalla pero que se comporten de tal forma que en cuanto el usuario rellena uno, el otro no está disponible. En realidad, hablamos de una relación XOR entre uno o varios campos. Para resolverlo hemos creado un componente que denominamos UIAnyOf
Por otra parte, a veces necesitamos hacer grupos de repetición. Una parafernalia en cuanto a introducir botones de añadir, borrar, subir y bajar. Nuestra solución pasa por utilizar un nuevo componente que denominamos UIRepeatGroup y, por supuesto, que nuestro modelo soporte la estructura.
Como habréis visto a lo largo del post, he intentado que nuestra solución fuera lo más simple posible. Más allá de eso, he tomado otra serie de decisiones que nos permiten mejorar los tiempos de desarrollo y time-to-market.
Cuando desarrollamos formularios hay múltiples aspectos que hay que tener en cuenta. Usar soluciones como esta proporciona a los clientes mecanismos que permiten mejorar su time-to-market y, además, mejorar la productividad del equipo de desarrollo.
Tenemos mucho que avanzar y muchas mejoras pendientes, si te interesa lo que hacemos no dudes en aplicar a nuestras ofertas de empleo.