新しいcombineReducersドキュメントは問題ありませんが、reducerを管理する州の当事者として指定する必要があることは説明されていません。
スキップせずに完全に読んだら、それはちょっとそれを言います:
結果のレデューサーはすべての子レデューサーを呼び出し、その結果を単一の状態オブジェクトに収集します。 状態オブジェクトの形状は、渡されたレデューサーのキーと一致します。
しかし、人々はこの文を見逃すことが多いので、これをもっと目立たせる必要があることに同意します。
#399からの変更は役に立ちますか?
私は、コンピュータの能力を低くしたいのですが、例の直後にこの規則について明示的に注意してください。
レデューサーには
todos
とcounter
という名前が付けられていることに注意してください。これは、レデューサーに渡す状態の一部とまったく同じです。状態の一部をレデューサーに渡すには、Reduxは_convention_を使用します。レデューサーは、渡したい状態の一部として正確に
#399は良いと思いますが、それは_Fluxユーザー_の説明です。 ボートの新鮮なReduxに来ています。 私のテキストのいくつかの形式は、カジュアルなJavaScript開発者にとってより役立つでしょう。
ここでの重要なアイデアは次のとおりです。コンベンションはAPIの一部です。 createRedux
、 createDispatcher
およびその他のAPI関数にも同様に重要です。 規則はAPIの一部であるため、常に明示的に記述してください。
ところで、私はまだ状態のサブパートをレデューサーに渡す方法に戸惑っています。 キャメルケースはそれらに参加する必要がありますか? state={owner: {name: 'John'} }
→ export function ownerName(state = [], action)
?
フィードバックをありがとう、それは非常に貴重です。
強調したい
コンベンションはAPIの一部です
本当に真実ではありません。
おそらく、ドキュメントではimport *
を避ける必要があります。これは、APIがまったくない場合でも、APIの不可欠な部分であると人々が想定しているためです。これは、私が使用する便利なショートカットです。
関数名は、ES6 export
とimport * as
がどのように機能するかによってのみ重要になります。
ところで、私はまだ状態のサブパートをレデューサーに渡す方法に戸惑っています。 キャメルケースはそれらに参加する必要がありますか? state = {owner:{name: 'John'}}→exportfunction ownerName(state = []、action)?
番号 :-)。 それは魔法のAPIではありません。 combineReducers(object)
は、複数のレデューサーを1つに結合し、指定したキーによって状態の一部をその値に渡します。 これは正確に1レベルの深さでのみ実行されます。 「ツリー全体の魔法を構築する」ことはありません。 レデューサーをより多くの関数に分割するのはあなた次第です。
// 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);
オブジェクトを自分で作成する限り、 combineReducers
ヘルパーを使用しても問題ありません。
// 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);
これは何度でも実行できます。
前:
// 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);
分かりますか? 関数を呼び出すだけの関数です。 魔法の「深いもの」はありません。
また、 combineReducers
何度も使用できます。
// 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);
あなたが使用している場合、関数名は問題である部分のみexport
+ import * as
あなたに渡すオブジェクト「を取得」にcombineReducers
理由_thatのどれだけimport *
works_ !! エクスポートキーに基づいてオブジェクトに配置します。
ここでの私の最大の間違いは、読者が名前付きエクスポートに精通していると想定していることだと思います。
ここでの私の最大の間違いは、読者が名前付きエクスポートに精通していると想定していることだと思います。
読者がES6に精通していると仮定すると、一筋縄ではいかないと思います。 しかし、それが人々にこのことを学び、理解するように促すものです。 ですから、読書が読者の知識や経験よりも進んでいる場合、それは実際には良いことです。
私たちは、明示的に呼び出すように例を変更しているcombineReducers
でreducers/index
、これからより多くの意味を作るために起こっているので、うまくいけば: https://github.com/gaearon/redux/pull/473
これは現在のドキュメントでより適切に対処されているように思われるため、終了します。
また、ドキュメントでもimport *
を使用しなくなりました。
そのような暗黙の動作を埋め込むことは、優れたコーディング手法だと本当に思いますか?
私にとって、それはコードを曖昧にし、combineReducerは存在すべきではありません、それは抽象化の不必要なステップを追加し、プロセスを複雑にします。
フレームワークを作成するとき、このような重要な機能は簡単に理解できるはずですが、それは明らかにそうではありません。たとえば、「魔法の」感覚などです。
PS:私は公式のReduxドキュメントから来ました:「それは魔法ではありません」
最も参考になるコメント
フィードバックをありがとう、それは非常に貴重です。
強調したい
本当に真実ではありません。
おそらく、ドキュメントでは
import *
を避ける必要があります。これは、APIがまったくない場合でも、APIの不可欠な部分であると人々が想定しているためです。これは、私が使用する便利なショートカットです。関数名は、ES6
export
とimport * as
がどのように機能するかによってのみ重要になります。番号 :-)。 それは魔法のAPIではありません。
combineReducers(object)
は、複数のレデューサーを1つに結合し、指定したキーによって状態の一部をその値に渡します。 これは正確に1レベルの深さでのみ実行されます。 「ツリー全体の魔法を構築する」ことはありません。 レデューサーをより多くの関数に分割するのはあなた次第です。オブジェクトを自分で作成する限り、
combineReducers
ヘルパーを使用しても問題ありません。これは何度でも実行できます。
前:
分かりますか? 関数を呼び出すだけの関数です。 魔法の「深いもの」はありません。
また、
combineReducers
何度も使用できます。あなたが使用している場合、関数名は問題である部分のみ
export
+import * as
あなたに渡すオブジェクト「を取得」にcombineReducers
理由_thatのどれだけimport *
works_ !! エクスポートキーに基づいてオブジェクトに配置します。ここでの私の最大の間違いは、読者が名前付きエクスポートに精通していると想定していることだと思います。