¿Cómo puedo comenzar a diseñar una aplicación React Redux?

Creo que realmente deberías leer este blog medio si quieres aprender cómo diseñar una aplicación React-Redux.

Esto explica claramente lo que necesita saber antes de comenzar cualquier aplicación.

He puesto una parte de esto aquí para que puedas echar un vistazo.

• Como principiante de JavaScript, ¿qué debo saber, comprender y dominar para considerarme capaz de construir aplicaciones y programas avanzados y del mundo real?
• ¿Cuál es la mejor interfaz de usuario web de reconocimiento popular?
• ¿Cómo uso Firebase para alojar aplicaciones Node.js?
• ¿Qué estilo de interacción PHP MySQL debería elegir?
• ¿Cuántas etiquetas h2 debo usar?

React + Redux Architecture: separación de preocupaciones

¿Tener una comprensión básica de React Redux es lo suficientemente bueno como para construir una aplicación? No, definitivamente no lo es. ¡No es así como lo hacemos!

En este blog, he tratado de conectar uno de los aspectos más importantes requeridos en la arquitectura de una aplicación React-Redux, que es SEPARACIÓN DE PREOCUPACIONES.

¿Por qué necesitas esto?

Cuando comencé a trabajar en la aplicación React Redux, estaba buscando blogs o artículos que pudieran ayudarme a encontrar un enfoque correcto hacia la arquitectura de una aplicación.

Pero no pude encontrar ningún artículo que pudiera conectarlo todo claramente, así que se me ocurrió todo lo que aprendí a través de mi experiencia.

No solo inicie su aplicación diseñando el componente y la estructura reductora, hay muchas cosas que deben tenerse en cuenta antes de hacer nada de eso. Hay una cosa que todos deben seguir:

Nunca comprometer la calidad.

Comencemos con lo básico.

Reaccionar

React se ha convertido en la opción más preferida cuando se trata de escribir aplicaciones JavaScript del lado del cliente . Su reutilización de código , escribir código en JSX y DOM virtual ha hecho que reaccionar sea popular y fácil de trabajar.

¿Pero por qué Redux?

Redux es una biblioteca que controla el estado de su aplicación JavaScript. Proporciona un ” flujo de datos unidireccional ” que ayuda a administrar y organizar mejor los datos y facilita mucho la depuración.

Enrutador
Esto es de gran importancia ya que es un punto de entrada de su aplicación . Puede haber varias rutas en su aplicación y necesitaría funcionalidades como validación, autenticación, redirección, etc., según el requisito. Manejarlos vendrá en la parte de Redux que será cubierto más adelante en este blog.

React Router Redux es la biblioteca más popular para el enrutamiento.

Ahora, antes de comenzar a discutir la arquitectura, es muy importante separar las preocupaciones tanto de React como de Redux. Si no hacemos esto, podríamos cometer pequeños errores que podrían conducir a grandes fallas en el flujo de nuestra aplicación.

SEPARACIÓN DE INTERESES

La separación de preocupaciones ( SoC ) es un principio de diseño para separar un programa de computadora en secciones distintas, de modo que cada sección aborde una preocupación separada.

SEPARACIÓN DE INTERESES

Aquí, las dos secciones son React y Redux.

Queremos asegurarnos de que nuestra aplicación sea mantenible, extensible, flexible y reutilizable.

Estos son puntos clave que lo ayudarán a decidir qué parte de la aplicación debe ir a la parte de datos y la parte de representación.

Parte de reacción / representación

Lo que debe hacer

1. Renderice contenido HTML con los datos proporcionados.
2. Tener múltiples estados de IU dependiendo de los datos, para que quede claro por qué se muestra.
3. Despachar acciones sobre la interacción del usuario o eventos del ciclo de vida (condicional)
4. Animación usando ReactCSSTransitionGroup o cualquier otra biblioteca.

Lo que no debe hacer

React es una biblioteca de representación. Solo debe dar una vista de los datos que se le proporcionan y nada más de lo que está destinado a hacer.

Estos puntos lo ayudarán a comprender que:

• No debería solicitar datos, si no está presente
  No es parte de la representación. El componente solo debe mostrar la interfaz de usuario, ya que los datos están disponibles. Si los datos no están presentes, muestre un estado predeterminado o un estado de error según el escenario.

Por ejemplo: tomemos una aplicación TODO; Tenemos un componente Reaccionar que se supone que muestra detalles de un TODO con ‘id’ 6. El componente no debería tener una verificación, si los datos no están disponibles, envíe una acción para recuperar los datos.

La mejor solución será obtener datos de las acciones . El componente solo se encargará de representar el contenido HTML en función de los datos proporcionados.

Pero la pregunta aquí es: ¿quién enviará las acciones si los componentes no lo hacen?
Sabemos que el punto de entrada a su aplicación son las rutas. Cuando una ruta coincide, se carga un componente correspondiente a esa ruta y se llama al controlador de ruta para esa ruta. Por lo tanto, el controlador de ruta se encargará de enviar esa acción.

El componente no debe enviar acciones para solicitar datos

• Almacenar datos en su estado local (se puede usar si es una animación o una entrada del usuario)

  Puede almacenar entradas de usuario como texto, número, pero aún así es mejor mantenerlo en la tienda redux porque nunca está seguro de cuándo algún otro componente podría utilizar los datos del componente. Y luego tendrá que seguir presionando los datos en los componentes del contenedor superior para que puedan compartirse con los inferiores. Para evitar todo esto, almacene todo en la tienda redux .

Tomemos un ejemplo de un temporizador. Tenemos que mostrar el tiempo necesario para una prueba. Tenemos un estado local que se establece en 0. En componentDidMount, tenemos un temporizador en ejecución que establece el valor del temporizador local cada segundo.

Esto funcionará bien si no tiene ningún otro requisito. Pero esto fallará en estos 2 casos:

1. Si tenemos que mostrar una alerta cuando el temporizador ha cruzado 120 segundos . No tenemos la información del temporizador fuera del componente. En este caso, fallará.

2. Si alguien cambia a otra pantalla donde se desmontará el componente Temporizador, los datos se perderán. Entonces, cuando regrese a la pantalla, se montará un componente nuevamente y el temporizador comenzará desde cero, que no es lo que queremos.

La mejor solución será tener el temporizador ejecutándose en acciones y dejar que actualice la tienda cada segundo. Entonces, cada componente tendrá acceso al valor de tiempo y no importa si el componente está montado o no.

• No debe enviar acciones en los eventos del ciclo de vida de un componente si la acción no está directamente relacionada con el evento del ciclo de vida

  Los eventos del ciclo de vida, si no se usan correctamente, pueden provocar tantos problemas que podrían no ser fáciles de depurar. Incluso si puede encontrar el problema, es posible que tenga que hacer tantos cambios que podrían hacer que su componente sea aún más complejo y podría terminar cambiando completamente la estructura. Por lo tanto, tenga mucho cuidado al usar eventos del ciclo de vida.

– Tomemos una aplicación TODO para entender. Tenemos un componente que muestra una lista de todos que distribuye una acción de un evento del ciclo de vida.

Eche un vistazo a los 4 diagramas a continuación. Intente identificar la razón por la cual son correctas o incorrectas antes de desplazarse hacia abajo para obtener explicaciones.

Aquí, en el ejemplo:

1. Obtener detalles de la lista si no está disponible: Esto no es correcto porque TODO LIST ya no será un componente reutilizable, ya que siempre dependerá de un tipo de datos que está tratando de recuperar. Además, tendremos que agregar una condición para verificar si los datos están disponibles o no. Está haciendo más que solo una representación.
2. Iniciar animación del componente de encabezado: Esto es incorrecto porque el evento está relacionado con un encabezado. Si la acción tiene que enviarse, debe enviarse desde el ciclo de vida del componente de encabezado.
   Sin embargo, la mejor solución sería enviar la acción de animación desde el punto de entrada. Podría ser cuando se golpea la ruta o se envía cualquier acción para mostrar esta interfaz de usuario que contiene el componente de encabezado.
3. Lista de tareas vistas por el usuario: este es el ejemplo correcto. Cuando se monta la lista de tareas, un usuario puede ver la lista y eso es lo que se actualiza a través de la acción.
4. Restablecer el estado de la interfaz de usuario en el desmontaje del componente : este es un muy buen uso del ciclo de vida del componente. Suponga que está viendo una IU de TODO en particular de una lista. Tiene su propia pantalla. Tiene pocas pestañas para TODO, como comentarios, notas, me gusta, etc. Siempre desea que TODO se abra con la pestaña de comentarios seleccionada. Entonces, en componentDidUnmount de TODO, restablecerá la selección de pestaña a comentarios.

Parte de Redux

Discutimos la representación y la interacción del usuario hasta ahora, que formará parte de React. ¿Qué pasa con las otras cosas importantes de nuestra aplicación?

La respuesta es “Redux”.
Tiene 3 partes: acciones, reductores y tienda .
He agrupado las preocupaciones en 2 grupos:
1. Cerebro – Esto usará solo acciones parte de Redux
2. Almacenamiento – Esto usará Reductores y Tienda

1. cerebro

Por lo tanto, los datos de la aplicación se mantienen en la tienda y representación redux en React. Todo lo demás que formará parte de su aplicación vendrá en el “cerebro”. Decidirá cómo funciona su aplicación y qué representación se mostrará.

Todo lo que será parte de un cerebro se escribirá en ACCIONES .

Aquí están las preocupaciones que serán parte de Brain. Para cada uno de estos, habrá una entidad que se encargará de abordar esa preocupación.
Por ejemplo: Habrá una clase / archivo diferente para manejar rutas como routeHandlers y para validaciones routeValidator.

• Lógica de negocios
  Esto se compone de un modelo que tiene lógica / algoritmo para determinar el estado de nuestra aplicación. Puede incluir operaciones algebraicas simples para establecer pasos para realizar una tarea en particular.

  Por ejemplo, tomemos una aplicación de prueba. Al comienzo de una prueba, deben suceder las siguientes cosas:

  1. mostrar carga
  2. buscar datos del cuestionario
  3. iniciar el temporizador de prueba
  4. eliminar carga
  5. preguntas de carga

  Este es el algoritmo que se seguirá para comenzar una prueba.

• Rutas de manejo
  Esto contendrá todas las cosas que deberían suceder después de llegar a cualquier ruta.
  1. Compruebe si la ruta es válida. Por ejemplo: si alguien golpea una ruta / todo / 18. Tendremos que validar si existe un TODO con id 18 o no. Si no, entonces tome las medidas necesarias.
  2. Compruebe si el usuario tiene permiso para seguir esa ruta
  3. Desviar si es necesario
  4. Compruebe si hay suficientes datos disponibles para esa ruta, si no, busque los datos
• Llamadas API
  Todas las solicitudes de AJAX vendrán aquí. Esto comprenderá:
  1. Un algoritmo que deben seguir todas las solicitudes de AJAX.
  2. Gestión de errores o problemas de conectividad a Internet.
  3. Sincronizar o enviar llamadas paralelas a múltiples API.
  4. Agrupando múltiples API para que pueda reutilizarse.
• Autorizaciones
  Esto incluye todos los tipos de autenticaciones que formarán parte de su aplicación:
  1. autorización del usuario
  2. para ver una IU particular
  3. por tomar una acción particular
  4. por golpear una ruta particular
• Validaciones
  1) datos de entrada del usuario
  2. datos de solicitudes AJAX
• Control del estado del componente
  1. El estado del componente se puede cambiar / controlar según la acción
  2. Supongamos que queremos realizar una operación pesada que puede llevar unos segundos. Deberíamos tener un control para cambiar el estado del componente a ‘espera’ para que pueda mostrar algún cargador en la interfaz de usuario hasta que se complete la operación.

2. Almacenamiento

1. Esto contendrá reductores (funciones puras) y un solo objeto llamado store que guardará el estado de su aplicación
2. La única forma de cambiar su estado es enviando una acción y se actualizará según el tipo de acción y los datos pasados ​​con la acción.
3. La Tienda activará eventos cuando se actualice su estado.
4. La vista puede suscribirse a esos eventos y actualizarse en consecuencia.

RESUMEN

1. Deberíamos usar React porque te permite escribir código en JSX, proporciona la reutilización del código y te permite controlar la representación innecesaria de los componentes.
2. Utilice Redux porque proporciona un ” flujo de datos unidireccional ” que ayuda a administrar y organizar mejor los datos y facilita mucho la depuración.
3. React solo debe representar contenido HTML , tener múltiples estados de interfaz de usuario, enviar acciones sobre la interacción del usuario y realizar animaciones .
4. React no debe solicitar datos si no está presente y no debe enviar acciones en los eventos del ciclo de vida de un componente si la acción no está directamente relacionada con el evento del ciclo de vida.
5. Redux tiene 3 partes: acciones, reductores y tienda .
   Redux se ocupará de estas 2 preocupaciones:
   1. Cerebro – Esto usará solo acciones parte de Redux
   2. Almacenamiento – Esto usará Reductores y Tienda
6. Brain se compone de funcionalidades que definen su aplicación.
   Incluye:
   1. Lógica empresarial
   2. Rutas de manejo
   3. Llamadas API
   4. Autenticaciones
   5. Validaciones
   6. Control del estado del componente
7. El almacenamiento contendrá reductores (funciones puras) y un único objeto llamado store que guardará el estado de su aplicación. La única forma de cambiar su estado es enviando una acción.

Ahora, cuando haya decidido los roles / responsabilidades de reaccionar y reducir parte. Puedes diseñarlos individualmente.