Ir al contenido principal

Organización del estado

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Redux FAQ: Organización del estado​

¿Debo poner todo mi estado en Redux? ¿Debería usar useState o useReducer de React?​

No hay una respuesta "correcta" para esto. Algunos usuarios prefieren mantener cada dato en Redux para tener una versión completamente serializable y controlada de su aplicación en todo momento. Otros prefieren mantener estados no críticos o de la interfaz de usuario, como "¿está este desplegable abierto actualmente?", dentro del estado interno de un componente.

Usar el estado local del componente está bien. Como desarrollador, es tu trabajo determinar qué tipos de estado componen tu aplicación y dónde debe residir cada pieza de estado. Encuentra un equilibrio que te funcione y úsalo.

Algunas reglas generales para determinar qué datos deben ir en Redux:

  • ¿A otras partes de la aplicación les importa este dato?

  • ¿Necesitas poder crear datos derivados basados en esta información original?

  • ¿Se usan los mismos datos para manejar múltiples componentes?

  • ¿Tiene valor para ti poder restaurar este estado a un momento dado (p. ej., depuración viaje en el tiempo)?

  • ¿Quieres almacenar en caché los datos (p. ej., usar lo que ya está en el estado en lugar de volver a solicitarlo)?

  • ¿Quieres mantener estos datos consistentes durante la recarga en caliente de componentes (que pueden perder su estado interno al ser reemplazados)?

Más información​

Artículos

Debates

¿Puedo poner funciones, promesas u otros elementos no serializables en mi store?​

Se recomienda encarecidamente poner solo objetos planos serializables, arrays y primitivos en tu store. Es técnicamente posible insertar elementos no serializables, pero esto puede romper la capacidad de persistir y rehidratar el contenido del store, además de interferir con la depuración viaje en el tiempo.

Si te parece aceptable que funciones como la persistencia o la depuración viaje en el tiempo no funcionen como se espera, eres libre de poner elementos no serializables en tu store de Redux. Al final, es tu aplicación y cómo la implementes depende de ti. Como con muchas cosas en Redux, asegúrate de entender las concesiones involucradas.

Más información​

Debates

¿Cómo organizo datos anidados o duplicados en mi estado?​

Los datos con IDs, anidados o con relaciones deben almacenarse generalmente de forma "normalizada": cada objeto debe almacenarse una sola vez, identificado por su ID, y otros objetos que lo referencien deben guardar solo el ID en lugar de una copia completa. Puede ser útil imaginar partes de tu store como una base de datos, con "tablas" individuales por tipo de elemento. Librerías como normalizr y redux-orm pueden ayudar ofreciendo abstracciones para gestionar datos normalizados.

Más información​

Documentación

Artículos

Debates

¿Debo guardar el estado de formularios u otro estado de UI en mi store?​

Las mismas reglas básicas para decidir qué debe ir en el store de Redux se aplican también a esta pregunta.

Basándonos en esas reglas, la mayoría del estado de formularios no necesita ir en Redux, ya que probablemente no se comparte entre componentes. Sin embargo, esta decisión siempre dependerá de ti y tu aplicación. Podrías optar por guardar parte del estado de formularios en Redux porque estás editando datos que originalmente vinieron del store, o porque necesitas que los valores en progreso se reflejen en otros componentes. Por otro lado, puede ser más sencillo mantener el estado del formulario localmente en el componente, y solo despachar una acción para guardar los datos en el store cuando el usuario termine con el formulario.

Por esto, en la mayoría de casos probablemente tampoco necesitarás una librería de gestión de formularios basada en Redux. Sugerimos probar estos enfoques en este orden:

  • Incluso si los datos provienen del almacén de Redux, comienza escribiendo la lógica de tu formulario manualmente. Es probable que sea todo lo que necesites. (Consulta los artículos de Gosha Arinich sobre formularios en React para una excelente guía sobre esto).

  • Si consideras que escribir formularios "manualmente" es demasiado complejo, prueba bibliotecas basadas en React como Formik o React-Final-Form.

  • Si estás completamente seguro de que debes usar una biblioteca de formularios basada en Redux porque otros enfoques no son suficientes, entonces puedes considerar Redux-Form y React-Redux-Form.

Si almacenas el estado de formularios en Redux, debes considerar las implicaciones de rendimiento. Despachar una acción por cada pulsación de tecla en un campo de texto probablemente no sea eficiente, y deberías explorar formas de almacenar cambios localmente antes de despachar. Como siempre, analiza las necesidades específicas de rendimiento de tu aplicación.

Otros tipos de estado de UI siguen estos mismos principios. El ejemplo clásico es rastrear un indicador isDropdownOpen. En la mayoría de casos, al resto de la aplicación no le importa esto, así que normalmente debería permanecer en el estado del componente. Sin embargo, dependiendo de tu aplicación, puede tener sentido usar Redux para gestionar diálogos y otros elementos emergentes, pestañas, paneles expandibles, etc.

Información adicional​

Artículos