Redux: 提案：「ストア」の名前を「レデューサー」に変更

-1このリポジトリの学習曲線はすでに急勾配になっています。 新しいフラックスユーザーのために新しい用語を導入することによって、それを急勾配にしないようにしましょう。

内部的にはレデューサーと呼ぶことができ、公に店舗として保管しているので、簡単に手に入れることができます。

正直なところ、今の状況はもっと混乱していると思います。 完全に逸話的ですが、私は何人かの人々に、「店」が無国籍である可能性があることを考えて、IRLがすべて混乱するようにしました。

従来のFluxの「ストア」の主な特徴は、1）状態を保持し、2）変更イベントを発行することです。 Reduxではどちらも当てはまりません。

用語を明確にする必要があることに同意します。場合によっては、より適切な命名法を見つけることもあります。
最初のステップとしてJSDocが必要だと思います。次に、用語のセクションも役立ちます。
一般に、一定レベルの一貫性を維持する必要があります。

FPっぽくはないけれど「お店」でもない言葉があるのではないでしょうか。
ドメイン？

OTOHそれはすでにReduxと呼ばれているので、少なくとも「レデューサー」は関連しているように聞こえます。

状態を一歩前進させる「ステップアップデート」または「ステッパー」はどうですか。 これがElmの文献で使用されており、 step 、 update 、またはnextという関数を持っているのを見てきました。

ドメインにはnode.jsの手荷物が含まれています。

それらは機能のストアではありませんが、フラックスストアのように状態ロジックをそこに配置します。 彼らは、フラックスストアがそうであるはずのように、州のマネージャーです。

ただし、名前の変更に熱心な場合は、レデューサーで問題ありません。

特に「レデューサー」は実際に何であるかを正確に説明しているためです:)

アップデーター？ 説明的で、レデューサーよりもしゃれた音が少ないように聞こえます。

私もreducer好きです

なぜ「レデューサー」が卑劣なのかわからないと思います。 説明の少ない新しい用語を発明するよりも、実際の用語を使用する方が良いのではないでしょうか。

私は両方とも有効かもしれないと思います、そしてそれはあなたがそれを見る視点から異なります：アクションの_reducer_（状態への）、または状態の_updater_。

「アップデーター」は、その変異を意味します。 「Reducer」は、古い状態を変更するのではなく、新しい状態を返すことを明確にします。

それは私が思うに賛成の強みであり、reduxが突然変異で正しく機能しないという問題に役立つかもしれません

FPに精通していない人にもReduxをフレンドリーに保つ必要があることはありがたいですが、より良いドキュメントでそれを解決することができます。 私は現在のドキュメントが好きですが、一見すると少し圧倒されます。 高度なもの（ミドルウェア、ホットリロード）よりも使い慣れたもの（アクションクリエーター、レデューサーロジック）を前景にした優れたドキュメントサイトが非常に役立ちます。

それでも、ここでの次の急速な成長から判断すると、私たちは何か正しいことをしているに違いありません:)

これがより良いドキュメントと一緒に起こった場合、私は「ストア」を「レデューサー」に変更することを受け入れます。

重要な要素は、「フラックスのようなものですが、心配しないでください」という雰囲気を維持することです。 私は人々にそれが逆流症か何かに似ていると思わせたくありません。それは逆流症のように聞こえますが、その素晴らしい特性のいくつかを壊します。 また、FPを学ぶ必要があると彼らに思わせたくありません。 私たちがそれを維持できる限り、私はこの変更で大丈夫です。

よくわからない提案：Reduxクラスの名前をStoreに変更すると（考えてみてください。その2つの目的は、状態を保持し、変更イベントを発行することです）、トップレベルAPIは次のようになります。

const store = createStore(reducers);

<Provider store={store} />

これはアイデアをかなりうまく伝えていると思います。 レデューサーはストアロジックの行き先ですが、それ自体はストアではありません。

store.dispatchは気分が悪いのですが、私はこれが好きです。

ええ、それは私が本当に好きではないことの1つですが、他の方法は理にかなっています： store.getState() 、 store.setState() 、 store.subscribe()

考えてみると、実際には何も「ディスパッチ」していません。
うーん、ネーミングはうさぎの穴です。

さて、これまでのところ、次のとおりです。

• アクション（作成者）
• （ストア）レデューサー
• ミドルウェア機能
• コールバック（リスナー）関数
• 関数呼び出しチェーンをトリガーするもの（ディスパッチャーと呼ばれる）
• 可変状態を保持するもの（セッターとゲッターを使用）

たぶん、一歩下がって名前を考え直すことができますか？

たぶんstore.dispatchはそれほど悪くはありません。 多くのストアではなく、単一のストアがあり、レデューサーから構成していることを説明できます。 ストアなし=個別のディスパッチャーは必要ないため、 dispatchはストアで直接入手できます。

@gaearon同意します。

@emmenko良い要約。 用語の内訳は、_actioncreators_と_actions_を区別する必要があります。 また、ミドルウェア+レデューサーを含む_dispatcher_または_dispatchstrategy_と、_dispatchcycle_をトリガーする_dispatch_メソッドを区別する必要があります。

これをやろう：

• ストアの名前をレデューサーに変更
• https://github.com/gaearon/redux/issues/137#issuecomment -113252359に従って、「Reduxインスタンス」の名前をStoreに変更し
• 従来のフラックスストアで目を細めると、レデューサーが閉じ込められているのがわかることを説明します

誰かが新しいドキュメントの取り組みを主導したいですか？ 用語集、README、簡単な「実行する」チュートリアル、そしておそらくより詳細な「設計上の決定」ガイドなど、いくつかの構造化が必要になります。

@gaearon私はこれを率いるボランティアをします:)私はすでに概要を始めています。

ありがとう：+1：

私はこれを率いるボランティアをします

ありがとう！ ：+1 ：： + 1 ：： + 1：

個人的には、最終的な結果として、次のような自動生成されたWebサイトが必要です。

• 入門
• チュートリアル
• 実例

...そして便利な機能として：

• 生成されたドキュメントa-la docco （例： jasmine ）ソースコードが明確に説明されるように

しかし、マークダウンとjsdocから始めることは、もちろん最初のステップです;）

そうです、最初のステップはMarkdown形式で書かれたドキュメントを入手することだと思います。それから、それらを本当に素晴らしいドキュメントサイトに移植することができます。 ：+1：JSDocの場合も。 今夜https://github.com/gaearon/redux/pull/87で最後の突き刺しをし

フローは優先ATMではないと思います。

レデューサーと呼ばれる店舗の場合は+1。

私はこれらのより宣言的でステートレスなものをストアと呼ぶのが好きではありませんでした。

私は新しい名前のアイデアが好きです。 私はまた、名前の変更を提案したいConnectorのようなものにSubscription 。 Connectorは非常に一般的であり、reduxの状態とディスパッチャーをその子に接続しているように見えますが、サブスクリプションは何が起こっているかをよりよく説明していると思います。 サブスクリプションと一緒にディスパッチャーを取得するのは少し難しいですが、それは問題ないと思います。

-レデューサーと呼ばれるストアの場合は-1。名前としては、新規ユーザー（少なくとも関数型プログラミングのバックグラウンドがないユーザー）にとってはあまり直感的ではありません。 アップデーターまたはトランスフォーマーの方が良いかもしれません。もっと明確にしたい場合は、ストアアップデーターの方がよいでしょう。

「トランスフォーマー」は何度も提案されています。 アップデータのような可変性を示唆するものではなく、レデューサーよりも親しみやすく、ストアの「ストレージ」の意味を持ちません。

トランスフォーマーはどうですか？

レデューサーの場合は+1

Twitterの@faassenが指摘しているように、「[].reduce() ： (state, action) => state渡されるため、これらはレデューサーと呼ばれます。 かくかくしかじか"

山火事のような角度の広がりと次のような言葉を使用します

• 指令
• 分離する
• トランスクルージョン

プログラミングを無視すること、変換すること、そして減らすことは別物です。 最も正確な名前を選びます。

データを保存しない場合は、ストアとは呼ばないでください。

ある形式から別の形式に変換していますか、それとも多くの値から1つの値に減らしていますか？

トランスフォーマー=>マップ
レデューサー=>リデュース

私には減らされたように聞こえます。

私もreducersです！ ：+1：

エルムからインスピレーションを得てください。 https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

最良の単語はupdateです。 ストアはナンセンスで、常に「モデル」でした。 車輪の再発明や人々の混乱を招く必要はありません。

それらをアップデーターと呼んでいる私の牛肉は、人々は彼らが変異性であると思われるかもしれないということです。 ネーミングが非変異性を明確にするのに役立つなら、それは大きなボーナスになるでしょう。

ある形式から別の形式に変換していますか、それとも多くの値から1つの値に減らしていますか？

たまってます。 「アクションが状態を次の状態に変える方法。」 概念的には、初期（未定義）状態から多くのアクションが削減されており、メモ化は単なる最適化です。

ステートトランスフォーマー

可能な限り再発明/再発見を避けるようにしてください。 人々はそれをreduce 、 scan 、 fold 、およびupdateと呼んでいます。

reducerは、JavaScriptの観点からは正確なようです...
たとえそれがより正確であっても、別の言語の概念から名前を付ける価値を見ないでください。

それがどうあるべきかについて確固たる立場を持ってはいけませんが、IMOは計算のタイプを最も正確に表すものでなければなりません。 それがほとんどのプログラマーにとってわかりにくい言葉である場合、それはドキュメントによって相殺することができます。

@vramanaそうではありませんmap 、それはreduce 、それは以前に蓄積かかるため、 stateと新しいactionを返す新しいstate 。

アプリのすべてのアクションの配列がある場合は、この関数を使用して、アプリを最終的なアプリの状態に減らします。

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

さて、あなたが実際に持っているのは、時間内にactions streamです。これは、概念的には配列と同じですが、時間内に（ streamに減らすことができます） state s）。

私はそれを（データ構造へのイベントログの）投影として考えるのが好きです。
DBの人々は、これを「マテリアライズドビュー」と呼んでいました。

私は縮小または折り畳みが好きです、それはさまざまなコミュニティによってよく理解されています

私はレデューサーよりもトランスフォーマーの方が好きです。英語での通常の単語の使用法から、それが何を意味するのかは明らかです。

レデューサー。
まず、それはjavascriptライブラリであり、javascriptには[].reduce(reducer, initialState)ます。
次に、Redu（cer）xはすでにライブラリ名に含まれています。
第三に、 https：//blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ 、他の人や図書館は「削減者」という用語を使用します。

レデューサーは正確で、バニラJSで前例があります。 それをどのように改善できるかわからない。

それならレデューサーです。

（＃140の進捗状況に従ってください）

時折、私はそれらを「店」と呼ぶ古い議論を見つけ、それが後知恵でどれほどばかげて混乱していたかに驚かされます。

「状態コンテナ」？

はい、これは良い変更でした:)