Redux: O documento `combineReducers` não explica como tenta qual parte do estado passar para o redutor

Meio que diz se você ler completamente, sem pular:

O redutor resultante chama cada redutor filho e reúne seus resultados em um único objeto de estado. A forma do objeto de estado corresponde às chaves dos redutores passados.

Mas eu concordo que isso precisa ser mais proeminente, já que as pessoas muitas vezes perdem essa frase.
As alterações de # 399 ajudariam você?

Eu prefiro menos ciência do computador, nota explícita sobre esta convenção logo após o exemplo:

Observe que os redutores são chamados de todos e counter - exatamente como as partes do estado que estamos passando para eles.

Para passar parte do estado para o redutor, o Redux emprega _convenção_ - o redutor deve ser nomeado exatamente como uma parte do estado que você deseja passar para ele.

Eu acho que o # 399 é bom, mas é uma explicação para _Usuários do Flux_. Estou voltando para Redux recém saído do barco. Alguma forma do meu texto seria mais útil para desenvolvedores de JavaScript casuais.

Uma ideia importante aqui é: A convenção faz parte da API . É igualmente importante para createRedux , createDispatcher e qualquer outra função da API. Sempre declare explicitamente as convenções porque elas fazem parte da API.

A propósito, ainda estou intrigado como passar a subparte do estado ao redutor. Devo camelCase me juntar a eles ou algo assim? state={owner: {name: 'John'} } → export function ownerName(state = [], action) ?

Obrigado pelo feedback, é muito valioso.

Eu quero enfatizar isso

A convenção faz parte da API

não é verdade.

Provavelmente deveríamos apenas evitar import * nos documentos porque as pessoas presumem que é parte integrante da API quando não é de todo, e é apenas um atalho conveniente que uso.

Os nomes das funções só importam por causa de como ES6 export e import * as funcionam.

A propósito, ainda estou intrigado como passar a subparte do estado ao redutor. Devo camelCase me juntar a eles ou algo assim? estado = {proprietário: {nome: 'João'}} → função de exportação proprietárioNome (estado = [], ação)?

Não :-). Não é uma API mágica. combineReducers(object) combina vários redutores em um e passa partes do estado para seus valores pelas chaves que você fornece. Ele só faz isso exatamente um nível de profundidade. Não há “magia de construir árvore inteira”. Depende de você dividir um redutor em mais funções:

// Function names don't matter!
function processA(state, action) { ... }
function doSomethingWithB(state, action) { ... }

function reducer(state = {}, action) {
  return {
    // Because you call them!
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}

// Not using combineReducers
let store = createStore(reducer);

Eles nem importam se você usar combineReducers helper , desde que você mesmo crie o objeto :

// Function names don't matter!
function processA(state, action) { ... }
function doSomethingWithB(state, action) { ... }

/*
function reducer(state = {}, action) {
  return {
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}
*/
let reducer = combineReducers({
  a: processA,
  b: doSomethingWithB
});

let store = createStore(reducer);

Você pode fazer isso muitas vezes.

Antes de:

// Function names don't matter!
function processSomePartOfA(state, action) { ... }
function doSomethingWithOtherPartOfA(state, action) { ... }

function processA(state, action) {
  return {
    // Because you call them!
    somePart: processSomePartOfA(state.somePart),
    otherPart: doSomethingWithOtherPartOfA(state.otherPart)
  }
}
function doSomethingWithB(state, action) { ... }

function reducer(state = {}, action) {
  return {
    // Because you call them!
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}

// Not using the helper
let store = createStore(reducer);

Você vê? São apenas funções que chamam funções. Nada de “coisas profundas” mágicas.
E você pode usar combineReducers muitas vezes também:

// Function names don't matter!
function processSomePartOfA(state, action) { ... }
function doSomethingWithOtherPartOfA(state, action) { ... }

/*
function processA(state, action) {
  return {
    somePart: processSomePartOfA(state.somePart),
    otherPart: doSomethingWithOtherPartOfA(state.otherPart)
  }
}
*/
let processA = combineReducers({
  somePart: processSomePartOfA,
  otherPart: doSomethingWithOtherPartOfA
});

function processA(state, action) { ... }
function doSomethingWithB(state, action) { ... }

/*
function reducer(state = {}, action) {
  return {
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}
*/
let reducer = combineReducers({
  a: processA,
  b: doSomethingWithB
});

let store = createStore(reducer);

A única parte em que os nomes das funções importam é quando você usa export + import * as para "obter" um objeto que você passa para combineReducers porque _é exatamente como import * funciona_ ! Ele coloca as coisas no objeto com base em suas chaves de exportação.

Acho que meu maior erro aqui é presumir que o leitor esteja familiarizado com as exportações nomeadas.

Acho que meu maior erro aqui é presumir que o leitor esteja familiarizado com as exportações nomeadas.

Acho que presumir que o leitor esteja familiarizado com o ES6 é exagero. Mas é isso que leva as pessoas a aprender e descobrir essas coisas. Portanto, é realmente bom quando a leitura está à frente do conhecimento e da experiência do leitor.

Estamos alterando os exemplos para chamar explicitamente combineReducers em reducers/index então esperamos que faça mais sentido a partir de agora: https://github.com/gaearon/redux/pull/473

Encerrando, pois isso parece ser mais bem abordado nos documentos atuais.
E não usamos mais import * em documentos também.

Você realmente acha que incorporar um comportamento implícito como esse é uma boa prática de codificação?

Para mim, isso ofusca o código e combineReducer não deveria existir, adiciona uma etapa desnecessária de abstração e complexifica o processo.

Quando você escreve uma estrutura, um recurso importante como este deve ser facilmente compreensível, obviamente não é o caso, por exemplo, a sensação de "mágica".

PS: Venho da documentação oficial do Redux: "Não é mágica"