No capítulo sobreProjetando a forma do estado, os documentos sugerem manter seu estado em um objeto digitado por ID:

Mantenha todas as entidades em um objeto armazenado com um ID como chave e use IDs para referenciá-lo de outras entidades ou listas.

Eles passam a afirmar

Pense no estado do aplicativo como um banco de dados.

Estou trabalhando no formato do estado para uma lista de filtros, alguns dos quais serão abertos (são exibidos em um pop-up) ou têm opções selecionadas. Quando li "Pense no estado do aplicativo como um banco de dados", pensei em considerá-los uma resposta JSON, pois seria retornada de uma API (ela mesma suportada por um banco de dados).

Então, eu estava pensando nisso 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',
  }]

No entanto, os documentos sugerem um formato mais parecido com

{
   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',
  }
}

Em teoria, não deveria importar desde que oos dados são serializáveis (sob o título "Estado").

Por isso, segui felizmente a abordagem da matriz de objetos até escrever meu redutor.

Com a abordagem objeto-chave-por-ID (e uso liberal da sintaxe de propagação), oOPEN_FILTER parte do redutor se torna

switch (action.type) {
  case OPEN_FILTER: {
    return { ...state, { ...state[action.id], open: true } }
  }

Considerando que, com a abordagem de matriz de objetos, é a mais detalhada (e dependente da função 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));
    }
    ...

Então, minhas perguntas são triplas:

1) A simplicidade do redutor é a motivação para seguir a abordagem objeto-chave-por-ID? Existem outras vantagens nessa forma de estado?

e

2) Parece que a abordagem objeto-chave-por-ID torna mais difícil lidar com a entrada / saída padrão de JSON para uma API. (É por isso que eu fui com a matriz de objetos em primeiro lugar.) Então, se você seguir essa abordagem, usa apenas uma função para transformá-la entre o formato JSON e o formato de estado? Isso parece desajeitado. (Embora se você defenda essa abordagem, faz parte do seu raciocínio que isso é menos desajeitado do que o redutor da matriz de objetos acima?)

e

3) Eu sei que Dan Abramov projetou o redux para ser teoricamente agnóstico na estrutura de dados do estado (como sugerido por"Por convenção, o estado de nível superior é um objeto ou alguma outra coleção de valores-chave como um Mapa, mastecnicamente, pode ser de qualquer tipo, " ênfase minha). Mas, considerando o exposto acima, é apenas "recomendado" mantê-lo como um objeto digitado pelo ID, ou existem outros pontos imprevisíveis com os quais vou me deparar usando uma variedade de objetos que o tornam tal que eu deveria apenas abortar esse objeto? planejar e tentar ficar com um objeto digitado por ID?