Comparativa de estructura de código entre ambos fragmentos

Utilizando la misma escala que en la Sección 5.2.3.3 se relevó lo que los encuestados pensaban sobre la estructura del código llegado en ambos enfoques. Mientras que en el enfoque tradicional la estructura del código dejaba aislado en dos archivos distintos el componente implementado, uno con la estructura y lógica, y otro con el estilo. El enfoque CSS-in-JS dejaba las tres partes en un mismo archivo. La estructura del código es importante ya que delinea la estructura del proyecto general al cual pertenece, una mala estructura puede resultar en pérdida de tiempo por parte de los desarrolladores en buscar diversos archivos, o incluso partes de distintos componentes. Esto a fin de cuentas termina perjudicando al proceso de creación de software.

El grupo de programadores menos experimentados en frontend realizó una elección pareja, quedando todos los valores equiparados en tres elecciones, a excepción de “mucho mejor en fragmento A” que cuenta con dos elecciones a su favor, y “mucho mejor en fragmento B” que cuenta con 4 elecciones (Figura 5.33), dando de esta forma una pequeña ventaja al enfoque CSS-in-JS.

Figura 5.33: Comparativa estructura de código entre enfoques, programadores generales

Mientras tanto entre los programadores especialistas en frontend se nota una fuerte tendencia hacia el enfoque CSS-in-JS propuesto en este trabajo, con un 75% de las elecciones acumuladas entre los grupos “mucho mejor en fragmento B” y “mejor en fragmento CSS-in-JS”. Dejando el 25% restante en el elemento neutro que por la escala utilizada es contado como elemento a favor de fragmento CSS-in-JS (Figura 5.34).

Figura 5.34: Comparativa estructura de código entre enfoques, programadores especialistas en frontend

5.2.3.5 Comparativa de portabilidad entre ambos fragmentos

La portabilidad es uno de los puntos claves del enfoque CSS-in-JS, ya que se reduce el componente a tan solo un archivo que contiene tanto el estilo, como la estructura y comportamiento del mismo. A diferencia del enfoque tradicional que mantiene el estilo por separado en un archivo, generalmente, global con todos los estilos de la aplicación. También la portabilidad es uno de los atributos de calidad principales a la hora de diseñar una aplicación web, ya que idealmente se espera poder portar elementos entre distintos sistemas, no tiene sentido implementar por ejemplo en un conjunto de sistemas hermanos el mismo botón en cada uno. Para mesurar dicho atributo la escala utilizada es la misma que la propuesta en la Sección 5.2.3.3

En la encuesta esto se evidencia ya que el 60% de los encuestados sin especialidad en frontend optaron por la opción "mucho mejor en fragmento B", llegando en total a 80% de opiniones a favor del fragmento CSS-in-JS (Figura 5.35).

Figura 5.35: Comparativa portabilidad entre enfoques, programadores generales

Esta tendencia se ve magnificada en la encuesta a programadores especialistas en frontend, donde el 100% otorgó una valoración positiva al fragmento CSS-in-JS, y el 87.5% lo consideró dentro del grupo "mucho mejor en fragmento B" (Figura 5.36). Lo cuál

demuestra que en ambas poblaciones estudiadas se considera una gran mejora a la portabilidad del enfoque tradicional el enfoque CSS-in-JS propuesto por este trabajo.

Figura 5.36: Comparativa portabilidad entre enfoques, programadores especialistas en frontend

5.2.3.6 Comparativa de facilidad para modificar componentes entre ambos

fragmentos

Al pensar en acoplar un nuevo elemento a un sistema como puede ser el enfoque para realizar los estilos se debe pensar en la mantenibilidad del código a futuro y cómo impactarán los cambios en los mismos a largo plazo. Por lo tanto un factor clave a relevar es la facilidad para modificar los componentes, la escala utilizada es la misma que en la Sección 5.2.3.3.

La población de programadores no especialistas en frontend denotó un apoyo del 73,33% al fragmento CSS-in-JS, distribuyendo en partes iguales 10 opiniones entre los grupos "mucho mejor en fragmento B" y "mejor en fragmento B" (Figura 5.37). Dejando en claro la facilidad a simple vista para realizar modificaciones, guiada por el hecho de que no hay que intercalar entre archivos para realizar cambios en un componente dado.

Figura 5.37: Comparativa de facilidad para modificar componentes,, programadores generales

Por su parte el grupo de programadores especialistas en frontend mostró contundencia al elegir con un 100% de las elecciones opciones positivas para el enfoque CSS-in-JS

propuesto, dejando el 37,5% de las elecciones en la opción "mucho mejor en fragmento B" (Figura 5.38).

Figura 5.38: Comparativa de facilidad para modificar componentes, programadores especialistas en frontend

Al finalizar con el Experimento #2 se pueden ver resultados favorables para el enfoque CSS-in-JS propuesto en este trabajo, dejando mayor contundencia sobre las características del mismo entre los programadores especialista en frontend. Estos programadores fueron quienes utilizaron previamente la herramienta que implementa las funcionalidades de este enfoque durante sus tareas diarias.

También se puede ver una preferencia de los programadores no especialistas en factores claves como la portabilidad y la facilidad a la hora de modificar el código, piezas claves en gran parte de los escenarios de desarrollo. Mientras que no demuestran un apoyo tan masivo en otros aspectos como la legibilidad del código generado (aunque sigue sosteniendo una victoria el enfoque propuesto en este trabajo), y principalmente en la estructura del mismo.

Capítulo 6: Conclusión

En el enfoque tradicional de desarrollo de aplicaciones web utilizando React plantea mantener el estilo de un componente en un archivo CSS global y la lógica junto a la estructura del mismo componente en un archivo JSX. Esto acarrea problemas como la dificultad a la hora de modificar un estilo de un componente, principalmente acentuado a la hora de reutilizar componentes ya que se debe a que además de aislar la funcionalidad y estructura del componente en cuestión a ser reutilizado, también se debe buscar dentro del archivo CSS (que contiene los estilos de toda la aplicación) las clases necesarias para su correcta visualización. También a la hora de añadir estilos, ya que no pueden repetirse los nombres de los estilos dentro de la aplicación. Otro problema con este enfoque son las dependencias entre archivos, ya que se debe referenciar de forma continua desde el archivo JSX a las clases existentes en el archivo CSS.

La evolución natural del enfoque llevó a nuevas herramientas que se basan en CSS-in-JS, las cuales permiten detallar los estilos en el mismo archivo JSX donde son declarados los componentes. El problema en las mismas radica en que se centran en inyectar directamente dichos estilos en el HTML de salida (generalmente utilizando métodos como tablas de estilos globales, o dejándolos inline bajo un tag style), sin generar un archivo CSS por separado. Además, la mayoría de estos enfoques delegan al usuario la responsabilidad del nombrado de las clases CSS y la referencia de las mismas en cada elemento JSX. Es decir, no aportan a evitar los errores tipográficos ni facilitar la escritura para el programador. En este trabajo final, se abordaron estos problemas mediante la presentación de un enfoque que modifica la sintaxis de JSX para permitir añadir los estilos dentro de los archivos JSX evitando al desarrollador tener que realizar el nombrado de los estilos. Los estilos son asignados automáticamente a un nuevo tag JSX personalizado, luego dicho tag puede ser utilizado libremente como cualquier otro pero con la ventaja de tener un estilo ya asociado. La definición de los estilos se realiza en forma de objetos planos de JavaScript, una sintaxis familiar para un desarrollador frontend. Y permite la extracción de los estilos en archivos CSS separados por componentes para permitir un post procesamiento por parte del usuario, dejando así abierta la posibilidad de adición dentro de cualquier ciclo de vida ya existente. Para poder validar los beneficios del enfoque se realizó un caso de estudio basado en dos experimentos:

● Experimento 1: Implementación una página conocida utilizando el enfoque propuesto en este trabajo, y su comparativa con la implementación tradicional. La página a analizar fue el 'Hello World' proporcionado por la herramienta de configuración automática de entorno provista por React. También se analizó una página de acceso tradicional implementada específicamente para este trabajo final.

● Experimento 2: Realización de encuesta sobre la herramienta implementada en este trabajo final a diversos programadores. Los resultados de la misma se encuentran divididos entre programadores específicos de frontend (es decir, aquellos que realizan interfaces de usuario con React dentro de su labores cotidianas), y

programación, y en desarrollo utilizando React de cada programador, seguido por su conocimiento de enfoques CSS-in-JS. Finalmente, se realizó una comparativa entre el enfoque propuesto por este trabajo y el enfoque tradicional donde se debía valorar los mismos bajo diversas características.

En el primer experimento se validó que con el enfoque propuesto se eliminan en su totalidad las líneas de CSS existentes en el proyecto, además también el correcto funcionamiento del mismo al poder replicar de forma exacta una página web. También se valida la baja en números de archivos necesarios para realizar el mismo trabajo, y la eliminación total de referencias a archivos externos aumentando la mantenibilidad. Sin embargo dado que el caso estudiado es demasiado chico, debería experimentarse en trabajos futuros con sistemas más complejos los cuales requieran la interacción de múltiples componentes y además posean integración con otros sistemas.

En el segundo experimento se validó la aceptación por parte de la comunidad de programadores, ya que el enfoque propuesto fue valorado positivamente en comparación al enfoque tradicional bajo las variables: legibilidad, estructura de código, portabilidad, y modificabilidad. Esta devolución positiva fue dada por parte de la mayoría de los encuestados, tanto especialistas en el área de frontend como programadores novatos en dicha área. Siendo los especialistas en el área quienes mayor devolución positiva generaron.

6.1 Contribuciones

El beneficio más importante de este trabajo es ayudar al desarrollador a la hora de programar componentes en React, permitiendo que los mismos se encuentren auto contenidos dentro de un mismo archivo, y aumentando la legibilidad, portabilidad, y modificabilidad de dichos componentes. Específicamente, se pueden resaltar las siguientes contribuciones:

● Desliga al desarrollador del nombrado de las clases CSS, esto se da mediante el sistema de acople de estilos a tags JSX personalizados. Al realizar esta paridad entre tags personalizados y estilos el desarrollador no debe realizar ninguna referencia explícita dentro de la estructura del componente a estilos deseados para cada tag JSX.

● Genera código CSS como resultado final, lo cual permite al desarrollador realizar tareas de post procesamiento sobre el mismo, ya sea para minificarlo, o insertarlo de alguna forma particular dentro de la aplicación web. También esto ayuda a la inclusión de la herramienta en flujos de trabajo tradicionales que esperan como salida del proceso de desarrollo los archivos CSS.

● Permite contener el componente en un solo archivo JSX, esto mejora la portabilidad ya que a la hora de extraer el componente está contenido en un solo archivo. De esta forma el insertar un componente en otro proyecto si no se puede exportar por otros medios es tan simple como mover un archivo.

● Modifica el proceso de transpiling, a diferencia de otras herramientas no es necesario importar ninguna función en los archivos, ya que la modificación se da directamente sobre el árbol de sintaxis abstracta a la hora de transformar código JSX a JavaScript. Desligando al programador de tener que declarar el uso de esta herramienta de forma explícita en cada componente.

● Elimina dependencias entre archivos en cuanto a estilos del componente, quiere decir que no existen dependencias a otros archivos para aplicar estilos sobre un componente. Esto permite mayor facilidad para modificar componentes y propagar dichos cambios. También previene errores por parte del desarrollador a la hora de referenciar dichos estilos existentes en otro archivo.

6.2 Limitaciones

Si bien la herramienta ayuda a un mejor proceso de desarrollo, se hallaron algunas limitaciones:

● No permite múltiples estilos sobre un mismo tag JSX, esto quiere decir que no pueden existir en un mismo componente dos elementos div con distintos estilos asociados, lo cual genera limitaciones en cuanto a los componentes que se pueden generar. Esto da como resultado en algunos casos que deba dividirse innecesariamente un componente

● Modifica el proceso de empaquetamiento, lo que da como resultado que a la hora de ser incluída esta herramienta en un entorno preexistente se debe generar cambios en el sistema de empaquetamiento utilizado para que los archivos generados por la misma sean tomados en cuenta. En la práctica es recomendable añadir un paso al comienzo del empaquetado que sea la generación de JavaScript estándar, y luego continuar con el proceso tradicional.