En el capítulo sobre Diseño de la forma del estado , los documentos sugieren mantener su estado en un objeto codificado por ID:
Mantenga todas las entidades de un objeto almacenadas con un ID como clave y utilice ID para hacer referencia a ellas desde otras entidades o listas.
Continúan diciendo
Piense en el estado de la aplicación como una base de datos.
Estoy trabajando en la forma del estado para obtener una lista de filtros, algunos de los cuales estarán abiertos (se muestran en una ventana emergente) o tienen opciones seleccionadas. Cuando leí "Piense en el estado de la aplicación como una base de datos", pensé en pensar en ellos como una respuesta JSON, ya que se devolvería desde una API (respaldada por una base de datos).
Así que estaba pensando en ello como
[{
id: '1',
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
{
id: '10',
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}]Sin embargo, los documentos sugieren un formato más parecido a
{
1: {
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
10: {
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}
}En teoría, no debería importar siempre que los datos sean serializables (bajo el título "Estado") .
Así que fui felizmente con el enfoque de matriz de objetos, hasta que escribí mi reductor.
Con el enfoque de objeto codificado por id (y el uso liberal de la sintaxis de propagación), la OPEN_FILTERparte del reductor se convierte en
switch (action.type) {
case OPEN_FILTER: {
return { ...state, { ...state[action.id], open: true } }
}Mientras que con el enfoque de matriz de objetos, es más detallado (y dependiente de la función auxiliar)
switch (action.type) {
case OPEN_FILTER: {
// relies on getFilterById helper function
const filter = getFilterById(state, action.id);
const index = state.indexOf(filter);
return state
.slice(0, index)
.concat([{ ...filter, open: true }])
.concat(state.slice(index + 1));
}
...Entonces mis preguntas son triples:
1) ¿Es la simplicidad del reductor la motivación para optar por el enfoque de objeto codificado por id? ¿Hay otras ventajas en esa forma de estado?
y
2) Parece que el enfoque de objeto con clave por id hace que sea más difícil lidiar con la entrada / salida JSON estándar para una API. (Es por eso que me decidí por la matriz de objetos en primer lugar). Entonces, si sigue ese enfoque, ¿usa una función para transformarlo entre el formato JSON y el formato de forma de estado? Eso parece torpe. (Aunque si defiende ese enfoque, ¿es parte de su razonamiento que eso es menos torpe que el reductor de matriz de objetos anterior?)
y
3) Sé que Dan Abramov diseñó redux para ser teóricamente agnóstico de estructura de datos de estado (como sugiere "Por convención, el estado de nivel superior es un objeto o alguna otra colección de valores clave como un mapa, pero técnicamente puede ser cualquier tipo , " énfasis mío). Pero dado lo anterior, ¿es simplemente "recomendado" mantenerlo como un objeto codificado por ID, o hay otros puntos de dolor imprevistos con los que me voy a encontrar al usar una matriz de objetos que hacen que deba abortar eso? ¿Planea e intenta ceñirse a un objeto codificado por ID?