En el capitulo sobreDiseñando la Forma del Estado, los documentos sugieren mantener su estado en un objeto con clave de ID:

Mantenga cada entidad en un objeto almacenado con una ID como clave, y use ID para hacer referencia a ella desde otras entidades o listas.

Pasan a declarar

Piense en el estado de la aplicación como una base de datos.

Estoy trabajando en la forma de estado para una lista de filtros, algunos de los cuales estarán abiertos (se muestran en una ventana emergente) o tienen opciones seleccionadas. Cuando leí "Piensa en el estado de la aplicación como una base de datos", pensé en pensar en ellos como una respuesta JSON, ya que sería devuelta 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

{
   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 mientraslos datos son serializables (bajo el encabezado "Estado").

Así que seguí felizmente el enfoque de la matriz de objetos, hasta que escribí mi reductor.

Con el enfoque object-keyed-by-id (y el uso liberal de la sintaxis de propagación), elOPEN_FILTER parte del reductor se convierte

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 seguir el enfoque de identificación por objeto? ¿Hay otras ventajas en la forma de ese estado?

y

2) Parece que el enfoque de identificación de objetos por clave hace que sea más difícil lidiar con la entrada / salida JSON estándar para una API. (Es por eso que elegí la matriz de objetos en primer lugar). Entonces, si sigues ese enfoque, ¿solo usas una función para transformarlo de un lado a otro 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 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 lo sugiere"Por convención, el estado de nivel superior es un objeto o alguna otra colección de valores clave como un Mapa, perotécnicamente puede ser de cualquier tipo" énfasis mío). Pero dado lo anterior, ¿es simplemente "recomendable" mantenerlo como un objeto con clave de ID, o hay otros puntos de dolor imprevistos con los que me voy a encontrar usando una serie de objetos que hacen que deba abortar eso? planificar e intentar seguir con un objeto con clave de identificación?