web-dev-qa-db-ja.com

Reduxコンポーネント/コンテナの構造化方法

私はreduxを使用していますが、コンポーネントの整理方法がわからないので、メインコンポーネントの名前をフォルダーおよび内部のすべてのコンポーネントの名前としてフォルダーに保存するのが最善だと思います。

 components 
リンク/ヘッダータイトルなどの一般的なもの
フォーム/ボタン、入力など
 Player /プレーヤーを形成するすべての小さなコンポーネント
 index.jsこれはトップレイアウトコンポーネントです。
 playBtn.js 
 artistName.js 
 songName.js 
 Episode /別のコンポーネント

次に、コンテナフォルダーには、ページごとに1つのコンテナーがあり、実際にReduxに接続しているのはこれらのコンテナーのみです。

 containers /
 HomePageApp.js 
 EpisodePageApp.js 
 ...

そして、アクションはページごとではなく、トップコンポーネントごとに1つなので、Reduxに接続するページコンテナーでは、そのページで使用されるコンポーネントのすべてのアクションを渡します。例えば：

アクション/
 Player.js 
 Episode.js 
 ...

私はこれを正しくやっていますか？私はそれについてグーグルで多くの情報を見つけていません、そして私が見つけたものは小さなプロジェクトに限定されていると思います。

ありがとう！

javascriptreactjsreduxreactjs-flux
43
Franco Risso

公式の例には、いくつかのトップレベルのディレクトリがあります。

  • components for “ dumb” React Reduxを認識しないコンポーネント。
  • 「スマート」のcontainers React Reduxに接続されたコンポーネント。
  • すべてのアクション作成者のactions。ファイル名はアプリの一部に対応します。
  • reducersはすべてのレデューサー用で、ファイル名は状態キーに対応します。
  • storeストアの初期化。

これは、中小規模のアプリに適しています。

よりモジュール化し、関連する機能をグループ化する場合、 Ducks または ドメインごとに機能をグループ化する他の方法 は、Reduxモジュールを構築するための優れた代替方法です。

最終的には、最適な構造を選択してください。 Reduxの作成者が、自分よりも自分にとって便利なものを知る方法はありません。

94
Dan Abramov

これは、ベストプラクティス/コードスタイルに関する質問であり、明確な答えはありません。ただし、非常に洗練されたスタイルが React reduxボイラープレート プロジェクトで提案されました。それはあなたが現在持っているものと非常に似ています。

./react-redux-universal-hot-example
├── bin
├── src
│   ├── components // eg. import { InfoBar } from '../components'
│   │   ├── CounterButton
│   │   ├── GithubButton
│   │   ├── InfoBar
│   │   ├── MiniInfoBar
│   │   ├── SurveyForm
│   │   ├── WidgetForm
│   │   └── __tests__
│   ├── containers // more descriptive, used in official docs/examples...
│   │   ├── About
│   │   ├── App
│   │   ├── Home
│   │   ├── Login
│   │   ├── LoginSuccess
│   │   ├── NotFound
│   │   ├── RequireLogin
│   │   ├── Survey
│   │   ├── Widgets
│   │   └── __tests__
│   │       └── routes.js // routes defined in root
│   ├── redux
│   │   ├── init.js
│   │   ├── middleware
│   │   │   └── clientMiddleware.js  // etc
│   │   └── modules // (action/creator/reducer/selector bundles)
│   │       ├── auth.js
│   │       ├── counter.js
│   │       ├── reducer.js  
│   │       ├── info.js
│   │       └── widgets.js
│   ├── server
│   │   ├── middleware
│   │   └── actions // proxy to separate REST api...
│   └── utils
│   │   ├── validationUtility.js // utility only (component-level definitions inside respective dir)
│       └── createDevToolsWindow.js  // etc
├── static
│   ├── dist
│   └── images
└── webpack
15
Kloar

スマートコンポーネントとダムコンポーネントを同じファイルに保存することを好みますが、スマートコンポーネントにはデフォルトのエクスポートを使用し、プレゼンテーション/ダムコンポーネントにはエクスポートを使用します。これにより、ディレクトリ構造のファイルノイズを減らすことができます。また、コンポーネントを「表示」でグループ化します（管理=> [admin.js、adminFoo.js、adminBar.js]、在庫=> [inventory.js、inventoryFoo.js、inventoryBar.js]など）。

4
dakt

コンポーネントのディレクトリについては強い意見はありませんが、アクション、定数、およびレデューサーを組み合わせるのが好きです。

state/
  actions/
    index.js
    ...
  constants.js
  reducers.js

stateをwebpackでエイリアスするので、コンテナコンポーネントでimport {someActionCreator} from 'state/actions';を実行できます。

この方法では、アプリ内のすべてのステートフルコードが1つの場所に存在します。

reducers.jsは、reducers/のようなactions/ディレクトリを作成するだけで複数のファイルに分割でき、インポートステートメントを変更する必要がないことに注意してください。

2
w00t

Reduxには、アクションの1つのエントリポイント（actions /フォルダー）とリデューサーのエントリポイント（reducers /フォルダー）があります。

ドメインベースのコード構造を使用すると、ドメイン/機能の実装とメンテナンスが簡素化されます...一方、コンポーネントの依存関係とアプリの状態/ロジックのメンテナンスが複雑になります。

再利用可能なコンポーネントはどこに配置しますか？機能/ドメインフォルダー内？他の機能/ドメインの再利用可能なコンポーネントが必要な場合、ドメイン間に依存関係を作成する必要がありますか？ mmhは大きなアプリにはあまり適していません！

レデューサーを組み合わせる必要がある場合、domain-code-structureは以前に与えたものを取り除きます。

ドメイン/機能ごとに単一のreduxモジュールのみを作成しています。 domain-code-structureは一部/ほとんどの場合に適しているはずですが、これはReduxではありません。

0
luk_z