ADR. Gestión de estados (Front End)

Título

Selección de la librería para la gestión de estados en el lado cliente.

Estado

Aceptado

Contexto

ReactJS ofrece gestión de estados, hooks (también personalizados) pero complica excesivamente el código el tratamiento de estados entre componentes, teniendo que utilizar contextos, portales o proveedores para ello. Es así que se decide tomar la decisión de optar por una librería externa.

Decisión

Debido a las características del proyecto, se plantean tres opciones:

• Redux. La más extendida y utilizada en el mercado actualmente.

  • Ventajas:

    • Sigue un patrón de diseño (Flux), creado por Facebook, que facilita el desarrollo. Flux se segmenta en action, dispatcher, view y store.

  • Desventajas:

    • Curva de aprendizaje bastante elevada, para el tiempo del que disponemos.
    • Aplicar nuevo patrón, desconocido hasta ahora, que genera código boilerplate.
    • Puede llegar a ralentizar la aplicación, si no se gestiona correctamente.

• Zustand Seleccionada. Es más comparable a la tercera opción. Comparar Zustand y Recoil con Redux no tiene mucho sentido, ya que aunque pueden tener funcionalidades comunes, están orientadas de forma muy diferente.

• Ventajas.

  • Ofrece un mayor rendimiento que Redux, en gran parte por la sencillez de su implementación, no tenemos tantos "participantes", dependiendo entre sí.

• Desventajas.

  • No sigue patrón como tal. Es decir, la libre elección de la estructura la decide el programador.

• RecoilJS. Funcionalidades similares a Zustand, incluyendo llamadas asíncronas. La decisión de no utilizar esta librería se debe a que está en fase experimental (Cabe recalcar que es una iniciativa de Facebook) pero en producción no suele dar buenos resultados, hablando de proyectos un poco serios.

Consecuencias

El aprendizaje de Zustand no supone un gran esfuerzo. Utilizar Redux en un proyecto de estas dimensiones y con el marco temporal establecido, no va a suponer una mejora en la aplicación (Bajo nuestro punto de vista).