Redux: 例-アクションタイプの名前空間を実装する方法は？

accountTypeをアクションに入れますか？ レデューサーファクトリを記述し、同じコードを何度も使用して、さまざまなアクションに応答するレデューサーを生成する方法については、 examples/real-world/reducersも参照してください。

同様に、アクションクリエーターは単なる関数であり、他の関数の束を返す関数を作成できることを忘れないでください。

既存の例では無視されていると言う問題の特定の小さな例を提供していただければ、本当に役立つと思います。

その後、その特定の例を単純化する方法を見つけるお手伝いをします。 コードなしで質問に答えて特定の何かを提案することは非常に難しいです。

@gaearon私はあなたがこれでどこに向かっているのか知っていますが、私は再利用可能なレデューサー、アクションクリエーター、またはDRYのものを作成しようとはしていません。まったく逆です。

アクションのグループを互いに分離しようとしているので、2人でシステムの2つの異なるセクションで作業し、アクションタイプ名に名前空間がないために、誤って互いのレデューサーをトリガーし始めないようにすることができます。

これがそれをより明確にすることを願っています。

https://www.npmjs.com/package/flux-constantをcreateActionTypesという非常に単純なヘルパー関数と組み合わせて使用​​することで、プロジェクトでこの問題を解決しました。

基本的に、私のコードは次のようになります。

// create-action-types.js
var fluxConstant = require('flux-constant');
module.exports = function (types) {
    return fluxConstant.set(types);
};

// in foo-action-types.js
module.exports = createAtionTypes([
    'ADD_FOO',
    'REMOVE_FOO'
]);

// in some-store.js
var fooActionTypes = require('foo-action-types');
function (state, action) {
    switch(action.type) {
        case fooActionTypes.ADD_FOO: 

        case fooActionTypes.REMOVE_FOO:
   }
}

すべてのアクションタイプを定数として1か所に保持してみませんか？
次に、同じ名前を2回エクスポートできないため、衝突することはありません。

これをよりよく視覚化するために、これがストアの初期状態であるとしましょう。

let initialState = {
  "testerAccount": {
    "videoUploads": [],
    "messages": []
  },
  "customerAccount": {
    "videoUploads": [],
    "messages": []
  },
  "systemUserAccount": {
    "videoUploads": [],
    "messages": []
  }
};

これらのセクションごとにビデオまたはメッセージを追加するための個別のレデューサーを実装するときに、アクションタイプ名の衝突をどのように回避しますか？

@gaearonが提案していることは、問題の核心を解決するものではありません。時間の経過とともに、多くの問題を引き起こす巨大なタイプのファイルになってしまうため、ダクトテープによるアプローチになります。

コードのマージ中にすぐに問題が発生しますが、後で名前のハックで解決する必要があります。例：

ADD_VIDEO_UPLOAD、ADD_TESTER_VIDEO_UPLOAD、ADD_VIDEO_UPLOAD_IN_SOME_SECTIONなど。

これもまた大きな頭痛の種です。

@koulmomoこれはまさに私が探していたものです、ありがとう：）：+ 1：シンプルでパワフルです。

@gaearonこのパッケージまたはredux-constantという名前の新しいパッケージのいずれかを使用する例が少なくとも1つあるはずだと思いますか？

私の意見では、名前空間の問題を解決するドキュメント/例のアプローチを促進することが新しいデフォルトになるはずです。

これであなたの助けをありがとう:)

あなたの例では、1セットのタイプ、1セットのレデューサージェネレーター、1セットのアクションクリエーターがない理由がわかりません。 アクションには、それらを区別するためのaccountTypeプロパティが含まれます。 アクションの作成者は、それをパラメーターとして受け入れます。 レデューサーファクトリはaccountTypeを受け入れ、このアカウントタイプのアクションのみを処理するレデューサーを返します。

ここではflux-constantが優れたソリューションだとは思いません。 instanceofチェックに依存しているようです。 つまり、アクションをシリアル化して後で再生することはできません。これは、逆シリアル化されたタイプが生成されたタイプと一致しないためです。

人々はしばしば、Fluxの本質的な機能を壊していることに気付かずに、Fluxを「よりシンプル」にしようとし

あなたの例では、1セットのタイプ、1セットのレデューサージェネレーター、1セットのアクションクリエーターがない理由がわかりません。 アクションには、それらを区別するためのaccountTypeプロパティが含まれます。 アクションの作成者は、それをパラメーターとして受け入れます。 レデューサーファクトリはaccountTypeを受け入れ、このアカウントタイプのアクションのみを処理するレデューサーを返します。

私はあなたの例の明らかな対称性に誤解されました。 ここにDRYがないことを意味していることを理解しました。機能の対称性は、 https： //github.com/rackt/redux/issues/786#issuecomment-142649749で述べたようにのみ明らかです。

ここに図書館は必要ないと思います。 大会を設立しよう！ たとえば、サブプロジェクトまたは機能が非常に分離している場合は、アクションタイプfeature/ACTION_TYPEを呼び出すことをルールにします（例： testers/UPLOAD_VIDEOまたはcustomers/UPLOAD_VIDEO 。 これらの「グループ」が実際にディスク上の実際のフォルダ（またはより適切なパッケージ）に対応している場合、これは特に便利です。

違反はコードレビューで簡単に見つけられます。 _本当に_したい場合は、これを自動化できますが、手動の名前空間が何をもたらすのかわかりません。 各モジュール内で、機能を簡単に制御し、作業の偶発的な重複を防ぎ、ドキュメントとして、すべての定数を1つのファイルで宣言する必要があります。

コード分​​割、名前空間化されたアクションタイプなどを使用したhuge-apps例を追加することにしました。ただし、これは別の問題になります。

文字列は、名前空間にとって本質的に悪いものではありません。 URLは文字列であり、正常に機能しているようです。

@gaearonそうです、flux-constantに基づくソリューションでのシリアル化の問題を忘れました。

名前内のモジュール/名前空間を簡単に区別できる限り、文字列ベースの名前空間に問題はありません。

命名規則ベースのソリューションは、私が以前に見たものです。

https://github.com/erikras/ducks-modular-redux

しかし、私はあなたの経験に基づいて、これを行うためのより良いまたは「正しい」方法があるかもしれないことを望みました。

フラックス定数アプローチを、実際に何らかの方法でシリアル化できるものに変換しようと思います。

このための時間があれば、「巨大なアプリ」の例を追加してください。これにより、他の人の時間を大幅に節約でき、後で簡単にフォローできる何らかの規則を確立できる可能性があります。

ありがとうございました ：）

ええ、申し訳ありませんが、残念ながら私はしばらくの間大きなアプリに取り組んでいませんでした、そして私が取り組んだときでさえ、何が起こるかについての良い概要を提供するので、定数がセクションにグループ化された単一の巨大なファイルがあるのが実際に好きでしたアプリで。

@pbcチェックアウトhttps://gist.github.com/jhewlett/acceb0e84bf043c17b66

この「問題」がドキュメントでより詳細に説明されているのを見てみたいと思います。 @pbcのような同じ質問があります。 「すべてのアクションタイプを定数として1か所にまとめてみませんか？」とは思いません。 プロジェクト間で複数のモジュールを再利用し、「規則を確立する」という推奨事項がある場合に機能します。 CSSランドのBEMのようなものに非常によく似ています。 ただし、BEMからCSSモジュールに移行し、大きなプロジェクトのアクションタイプにもハッシュクラス名が必要なCSSモジュールに似たものを推測します。

私の知る限り、シリアル化と競合の欠如の両方を達成する方法はありません。

再利用可能なモジュールの適切な規則では、リバースドメイン名、githubのユーザー名/リポジトリ、npmの登録済みモジュール名など、既存の「一意性プロバイダー」を使用できます。

編集：CSSモジュールは、CSSの上にカスタム言語を定義し、前処理中にクラス名の前に付けることによってこれを行います（とにかく慣例に要約されますが、生成されたものです）。

質問とディスカッションは+1。 私はまた、 @ pbcとしてこの正確な問題に多くの苦労をし

シリアル化可能な文字列アクションタイプの解決策を見つけたと思います。 それは私たちの精神が何かに人為的な制限を課す状況の1つだと思います。

基本的な考え方は、型定数を文字列値に関連付ける必要がないということです。 したがって、ランダムに生成された値、ハッシュされたファイルパス、または型定数文字列値に固有のその他のものを使用できます。 レデューサーでは、型定数を名前でインポートし、名前で比較します。 その名前は他のアクションや他のレデューサーで使用される可能性がありますが、値は同じではないため、問題ではありません。

ここでの例： https ：

これは賢明です。 アクション名に人間が読める部分を残したい場合でも、一意のプレフィックスを生成することは完全に機能します。

もちろん、それらがユニークであることを証明できれば。
最善の方法は、既存の一意性プロバイダー（逆ドメイン名またはnpmモジュール名）を使用することです。

慣例による名前空間は、モジュールを作成するときに、制御できないさまざまな場所で使用できる危険があります。

ActionTypeが「Area」のモジュール「Geometry」があるとします。 このモジュールは2つの場所で使用されます。

1. AppA-> Drawing-> Geometry（namespace = "Drawing / Geometry / Area"）
2. AppB-> Trigonometry-> Shape-> Geometry（namespace = "Trigonometry / Shape / Area"）

これで、モジュールが使用される場所に応じて、2つの競合する名前空間ができました。

• ActionType "Area"のGeometryモジュールにこのフルパスをハードコーディングすることはお勧めできません。
• むしろ、名前を単純にしてください：「エリア」。
• レデューサー構成と同様の方法で、それぞれに含まれる親にプレフィックスを追加して名前空間を構成します。

私は次のパターンで実験しています：

以下を含むコレクションのタイプごとにディレクトリを作成します。

• consts
• レデューサー
• コンポーネント
• サガ

次の形式でconstを作成します。

// song-store/song-store-consts.js
export const ADD = 'SONG_STORE.ADD'
export const REMOVE = 'SONG_STORE.REMOVE'

レデューサー、佐賀の定数またはアクションを使用する場合はimportそれらを持つすべての* ：

// song-store/song-store-actions.js
import * as SONG_STORE from './song-store-consts'

export function addSongStore(name) {
  return {
    type: SONG_STORE.ADD,
    name
  }
}

export function removeSongStore(songStoreId) {
  return {
    type: SONG_STORE.REMOVE,
    songStoreId
  }
}

悲しいことに、木の揺れには向いていません。 ES6が許可されていればいいでしょう：

import { ADD, REMOVE } as SONG_STORE from './song-store-actions'

Webpack2がimport *をインテリジェントにツリーシェイクできるかどうかは誰でも知っているので、 *インポートされたとしても使用されないエクスポートのコードはバンドルされません。

これは非常に一般的な問題のようであり、次のいずれかの場合に頻繁に発生します。

• 名前の競合は、望ましくない動作を引き起こします。
• 固有のアクションタイプの作成に関連する定型文について不平を言う。

私たちはいくつかの異なる解決策を試しましたが、何も固執していないようでした：

1. すべてのアクションタイプを定数として1つの場所に保持すると、管理が容易になりますが、アプリが大きくなると少し扱いに​​くくなることがわかりました。
2. @samschによって言及されたランダムに生成された値は本当に私の注意を引き、それは確かに機能しますが、はい、人間が読める部分を失うと、一緒に暮らすのがより難しくなります。
3. @philholdenによる上記のコメントは、私たちが通常機能駆動型アーキテクチャを使用し、ディレクトリ構造が非常に説明的であるため、私にとって本当に魅力的でした。

過去数か月間実験した後、ディレクトリ構造を使用してアクションタイプに名前空間を付けることにしました。 これらを手動で入力すると古くなるので、 __filename何かをしようとしましたが、コードのバンドルなどが原因で機能しません。次に、キーワード__filenamespaceを変換する最初のBabelプラグインを作成しました。 __filenamespaceを静的文字列に変換します。これはうまく機能しているようです。

例

App/testerAccount/index.js ：

// Something like this
const ADD_VIDEO_UPLOAD = `${__filenamespace}/ADD_VIDEO_UPLOAD`;
const ADD_COMMENT = `${__filenamespace}/ADD_COMMENT`;

// Will be transformed into something like this
const ADD_VIDEO_UPLOAD = 'App/testerAccount/ADD_VIDEO_UPLOAD';
const ADD_COMMENT = 'App/testerAccount/ADD_COMMENT';

お気軽にお試しください。お役に立てば幸いです。 特に、問題の作成者およびライブラリの作成者として@pbcまたは@gaearonからフィードバックを得るのは素晴らしいことです。

https://www.npmjs.com/package/babel-plugin-filenamespace

私は誰かが「標準」を提供することを本当に望んでいました。 このためにシンボルやオブジェクトは必要ありません。必要なのは規則だけです。

"featureName$actionType"または"fileName/ACTION_TYPE"または"PROJECT.FEATURE.ACTION"ますか？ 私たち全員が何かに同意できれば、レデューサーを共有するのは簡単になります。

他の利用可能な規則が不足しているため、アヒルは事実上の標準になっていると思います。

const ACTION = 'app/feature/ACTION';で十分です。

@gaearonは常に、アクションとレデューサーの1：1の関係はおそらく悪い考えであると述べており、私は本当に同意します。 しかし、2つの異なるビューが実際に同じレデューサーを呼び出したい場合はどうでしょうか。
例えば。 単純な設定切り替えは、2つの異なる場所から有効または無効にできます。
/ myaccount / toggleNotification
/ dashboard / toggleNotification
したがって、同じ内容で2つのレデューサーを作成する必要があります
レデューサー/notifications.js
cc： @ samit4me 、 philholden

別の考えでは、これは、ファイル内に2つ以上のレデューサーが異なるアクション名で同じジョブを実行するという良い考えだと思います。 これは、レデューサーを見るだけで、特定の状態がいくつの異なる場所から変更されているかを理解できる方法です。

とにかく、専門家から聞いてみたいです。 ありがとう。

@ivks ：ここにいくつかの考えがあります。

まず、アプリケーション内の複数の場所から同じアクションをディスパッチできます。

次に、同じレデューサーで複数のアクションタイプをリッスンし、それらを同じ方法で処理することができます。

第3に、「1：1関係」の側面は、複数のスライスレデューサーが同じアクションをリッスンし、それぞれが状態のビットを個別に更新できるようにすることです。 はい、ほとんどの場合、特定のアクションを気にするレデューサーは1つしかない場合がありますが、複数のレデューサーを応答させることは、Reduxの意図されたユースケースです。

@markerikson

次に、同じレデューサーで複数のアクションタイプをリッスンし、それらを同じ方法で処理することができます。

私は実際にredux-actionsを使用していましたが、タスクを実行するユーティリティメソッドcombineActionがあることを知りませんでした。 ちょうどそれを見つけて、あなたの上記の声明はちょうど同じことを述べています。 （もっと明確にすべきだった、ごめんなさい）
返信ありがとうございます。

DucksがActionTypesで正しく定義されているとは思いません。

npm-module-or-app / reducer / ACTION_TYPEの形式のアクションタイプが必要です

その理由は、1つのアクションが複数のレデューサーによってサブスクライブされる可能性があるためです。 @mherodevが言ったように、 const ACTION = 'app/feature/ACTION';方が理にかなっています。さらに、アクションのスキーマconst ACTION = 'action://app/feature/ACTION';を追加したいと思い

アクションタイプを識別するために、グローバルに自己増分する整数を使用しないのはなぜですか？ 例えば

let id = 0

function generateActionType (label /* for readability */) {
  id++
  return `app/feature/${id}/${label}`
}

これについて少し考えて、他の開発者と衝突しないようにするために、ディレクトリを調べるlintルールを作成しています（すべてのレデューサーがあり、各レデューサーには定数として独自のアクションタイプがあります）

同じ値の定数が2つある場合に違反を報告するように、リンティングを計画しています。

何か提案があれば、私に知らせてください:)