Ir al contenido principal
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 →

Estructura Básica del Reductor y Forma del Estado

Estructura Básica del Reductor

Es fundamental entender que toda tu aplicación tiene solo una única función reductora: la que pasaste a createStore como primer argumento. Esta única función reductora debe realizar varias tareas esenciales:

  • La primera vez que se llama al reductor, el valor de state será undefined. El reductor debe gestionar este caso proporcionando un valor de estado predeterminado antes de procesar la acción recibida.

  • Debe examinar el estado anterior y la acción despachada para determinar qué tipo de operación debe realizar.

  • Si se requieren cambios reales, debe crear nuevos objetos y arrays con los datos actualizados y devolverlos.

  • Si no se necesitan modificaciones, debe devolver el estado existente sin alteraciones.

El enfoque más sencillo para escribir la lógica del reductor es consolidar todo en una única declaración de función, así:

function counter(state, action) {
if (typeof state === 'undefined') {
state = 0 // If state is undefined, initialize it with a default value
}

if (action.type === 'INCREMENT') {
return state + 1
} else if (action.type === 'DECREMENT') {
return state - 1
} else {
return state // In case an action is passed in we don't understand
}
}

Observa que esta función simple cumple todos los requisitos básicos: devuelve un valor predeterminado si no existe (inicializando el store), determina el tipo de actualización necesaria según la acción y devuelve nuevos valores, y mantiene el estado anterior si no se requiere trabajo.

Pueden aplicarse ajustes simples a este reductor. Primero, las repetitivas declaraciones if/else resultan engorrosas rápidamente, por lo que es habitual usar switch. Segundo, podemos emplear valores de parámetros predeterminados para gestionar el caso inicial "sin datos existentes". Con estos cambios, el reductor quedaría así:

function counter(state = 0, action) {
switch (action.type) {
case 'INCREMENT':
return state + 1
case 'DECREMENT':
return state - 1
default:
return state
}
}

Esta es la estructura básica que utiliza una función reductora típica de Redux.

Forma Básica del Estado

Redux te anima a pensar en tu aplicación según los datos que necesitas gestionar. Los datos en cualquier momento dado constituyen el "estado" de tu aplicación, y su estructura y organización se denominan comúnmente "forma". La forma de tu estado influye significativamente en cómo estructuras la lógica del reductor.

Un estado de Redux suele tener un objeto plano de Javascript como raíz del árbol de estado. (Es posible usar otros tipos de datos como número único, array o estructura especializada, pero la mayoría de bibliotecas asumen que el valor raíz es un objeto plano). La forma más común de organizar datos dentro de este objeto es dividirlos en subárboles, donde cada clave principal representa un "dominio" o "porción" de datos relacionados. Por ejemplo, el estado de una app Todo básica podría verse así:

{
visibilityFilter: 'SHOW_ALL',
todos: [
{
text: 'Consider using Redux',
completed: true,
},
{
text: 'Keep all state in a single tree',
completed: false
}
]
}

En este ejemplo, todos y visibilityFilter son claves principales en el estado, y cada una representa una "porción" de datos para un concepto particular.

La mayoría de aplicaciones manejan múltiples tipos de datos, que pueden agruparse en tres categorías:

  • Datos de dominio: información que la aplicación debe mostrar, usar o modificar (como "todos los Todos obtenidos del servidor").

  • Estado de la aplicación: datos específicos del comportamiento de la app (como "el Todo #5 está seleccionado actualmente" o "hay una solicitud en curso para obtener Todos").

  • Estado de UI: datos que representan cómo se muestra actualmente la interfaz (como "el diálogo modal EditTodo está abierto").

Dado que el store representa el núcleo de tu aplicación, debes definir la forma del estado según tus datos de dominio y estado de la aplicación, no según tu árbol de componentes UI. Por ejemplo, una forma como state.leftPane.todoList.todos sería inadecuada, porque el concepto de "todos" es central para toda la aplicación, no solo para una parte de la UI. La porción todos debería estar en la raíz del árbol de estado.

Rara vez existirá una correspondencia directa entre tu árbol de UI y la estructura del estado. La excepción sería si estás rastreando explícitamente aspectos de la interfaz en tu store de Redux, pero incluso en ese caso, la estructura de los datos de UI y los datos de dominio probablemente serían diferentes.

La estructura típica del estado en una aplicación podría verse aproximadamente así:

{
domainData1 : {},
domainData2 : {},
appState1 : {},
appState2 : {},
ui : {
uiState1 : {},
uiState2 : {},
}
}