Redux: El documento `combineReducers` no explica cómo adivina qué parte del estado pasar al reductor

Lo dice un poco si lo lees por completo, sin saltarte:

El reductor resultante llama a cada reductor secundario y reúne sus resultados en un solo objeto de estado. La forma del objeto de estado coincide con las claves de los reductores pasados.

Pero estoy de acuerdo en que esto debe ser más prominente, ya que las personas a menudo pierden esta oración.
¿Le ayudarían los cambios del n. ° 399?

Preferiría menos conocimientos de informática, una nota explícita sobre esta convención justo después del ejemplo:

Tenga en cuenta que los reductores se denominan todos y counter , exactamente como las partes del estado que les estamos pasando.

Para pasar parte del estado al reductor, Redux emplea _convention_; reducer debe nombrarse exactamente como parte del estado que desea pasarle.

Creo que el número 399 es bueno, pero es una explicación para los _usuarios de Flujo_. Llego a Redux recién salido del barco. Alguna forma de mi texto sería más útil para los desarrolladores casuales de JavaScript.

La idea importante aquí es: La convención es parte de la API . Es igualmente importante para createRedux , createDispatcher y cualquier otra función de la API. Indique siempre las convenciones de forma explícita porque son parte de la API.

Por cierto, todavía me desconcierta cómo pasar una subparte del estado al reductor. ¿Debería unirme a camelCase o algo así? state={owner: {name: 'John'} } → export function ownerName(state = [], action) ?

Gracias por la retroalimentación, es muy valiosa.

Quiero enfatizar que

La convención es parte de API

no es realmente cierto.

Probablemente deberíamos evitar import * en los documentos porque la gente asume que es parte integral de la API cuando no lo es en absoluto, y es solo un atajo conveniente que uso.

Los nombres de las funciones solo importan debido a cómo funcionan ES6 export y import * as .

Por cierto, todavía me desconcierta cómo pasar una subparte del estado al reductor. ¿Debería unirme a camelCase o algo así? state = {owner: {name: 'John'}} → función de exportación ownerName (state = [], action)?

No :-). No es una API mágica. combineReducers(object) combina varios reductores en uno y pasa partes del estado a sus valores mediante las claves que proporcione. Solo hace esto exactamente a un nivel de profundidad. No hay "magia para construir un árbol completo". Depende de usted dividir un reductor en más funciones:

// 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);

Ni siquiera importan si usa combineReducers helper siempre que cree el objeto usted mismo :

// 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);

Puedes hacer esto muchas veces.

Antes:

// 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);

¿Verás? Son solo funciones que llaman a funciones. No hay "cosas profundas" mágicas.
Y también puedes usar combineReducers muchas veces:

// 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);

La única parte donde los nombres de las funciones importan es cuando usas export + import * as para "obtener" un objeto que pasas a combineReducers porque _ así es como funciona import * ! Pone cosas en objetos según sus claves de exportación.

Creo que mi mayor error aquí es asumir que el lector está familiarizado con las exportaciones con nombre.

Creo que mi mayor error aquí es asumir que el lector está familiarizado con las exportaciones con nombre.

Creo que asumir que el lector está familiarizado con ES6 es exagerado. Pero eso es lo que empuja a la gente a aprender y resolver estas cosas. Por lo tanto, es algo bueno que la lectura esté por delante del conocimiento y la experiencia del lector.

Estamos cambiando ejemplos para llamar explícitamente a combineReducers en reducers/index así que, con suerte, tendrá más sentido a partir de ahora: https://github.com/gaearon/redux/pull/473

Cierre, ya que esto parece estar mejor abordado en los documentos actuales.
Y tampoco usamos import * en documentos.

¿Realmente crees que incrustar un comportamiento implícito como ese es una buena práctica de codificación?

Para mí, ofusca el código y combineReducer no debería existir, agrega un paso innecesario de abstracción y complejiza el proceso.

Cuando escribe un marco, una característica importante como esta debería ser fácilmente comprensible, obviamente ese no es el caso, por ejemplo, la sensación "mágica".

PD: vengo de la documentación oficial de Redux: "No es magia"