Estado de la interfaz de usuario (UI State) — JS: Arquitectura Front-end

Cambiar el estado de la aplicación frontend no siempre significa cambiar los datos con los que trabaja la aplicación. Los datos pueden tener un estado que solo afecta a la apariencia visual. En el servidor, en la base de datos, este estado no existe.

Imagínate un acordeón normal. Es una forma de mostrar datos en la que se puede ocultar o mostrar uno de los elementos de la lista. Para que un acordeón funcione de esta manera, se necesita un estado que describa la visualización de cada elemento: colapsado/expandido. Este estado se llama estado de la interfaz de usuario (UI), es decir, el estado de la interfaz del usuario. ¿Dónde debería almacenarse este estado?

Por ejemplo, se puede colocar dentro de los propios datos:

// Lista de empresas. La visibilidad en el acordeón está controlada por la bandera "visibility"
const state = {
  companies: [
    { id: 1, name: 'Códica', description: 'cursos en línea', visibility: 'hidden' },
    { id: 2, name: 'Google', description: 'motor de búsqueda', visibility: 'shown' },
    { id: 3, name: 'Facebook', description: 'red social', visibility: 'hidden' },
  ],
};

Más adelante, en la capa de presentación, se muestra estos datos teniendo en cuenta la bandera. Técnicamente, la tarea está resuelta, pero este método de almacenamiento tiene algunas desventajas significativas.

Comencemos por lo principal. Los datos en el frontend no aparecen de la nada. Los datos de la aplicación se almacenan en el servidor, se envían desde el servidor y se envían al servidor. Y el servidor no sabe ni debe saber nada sobre la apariencia visual, esto no se aplica a los datos. Y aquí surge un problema grave. Si el estado de la interfaz de usuario se almacena dentro de los datos, entonces tendrá que realizar constantemente dos cosas:

1. Agregar procesamiento adicional para todos los datos que vienen del servidor, agregando el estado de la interfaz de usuario.
2. Agregar procesamiento adicional para todos los datos que se envían al servidor, eliminando todo el estado de la interfaz de usuario.

Y hay muchos elementos de visualización similares, generalmente más de uno. Esto incluye la visibilidad de las ventanas modales, la clasificación, ocultar/mostrar en todas las manifestaciones posibles, diferentes modos (edición), confirmaciones y mucho más. No solo tendrá que almacenar todo esto dentro de los datos, sino que también deberá recordar constantemente la necesidad de procesamiento adicional.

Pero eso no es todo. No siempre se procesa todo el conjunto de datos de la misma manera. Es posible que un conjunto de datos se muestre en diferentes lugares de la página o solo parcialmente. Esto significa que el estado de la interfaz de usuario puede ser diferente para diferentes elementos o incluso puede no existir para algunos elementos. ¿Qué hacer en este caso? ¿Ignorar las diferencias y agregar el mismo conjunto de datos a todos o complicar la lógica y hacer que el llenado sea selectivo?

Debido a los problemas mencionados, el estado de la interfaz de usuario se almacena por separado de los propios datos. Además, para cada situación, habrá un conjunto de datos separado. Por ejemplo, para el acordeón, el estado puede verse así:

const state = {
  companies: [...],
  uiState: {
    accordion: [
      { companyId: 1, visibility: 'hidden' },
      { companyId: 2, visibility: 'shown' },
      { companyId: 3, visibility: 'hidden' },
    ],
  },
};

Destacamos algunos puntos:

1. companyId se utiliza para vincularlo con los datos. Los datos en sí no se duplican.
2. El estado de la interfaz de usuario puede generarse tanto durante la ejecución de la aplicación como en el momento de la inicialización al iniciarla. Depende de cuándo aparece cada elemento.