コンポーネントベースのReact-Reduxプロジェクトのディレクトリ構造

私は、react-reduxプロジェクトのコード構造に関する質問はほとんどありませんが、私は別のアプローチについて議論したいと思います。したがって、私たちが使う主なライブラリはwebpack-react-redux -mocha-karmaです。コンポーネントベースのReact-Reduxプロジェクトのディレクトリ構造

このための古典的なフォルダ構造があると思われる：

js 
├── actions 
│ ├── action-for-componentA.js 
├── components 
│ ├── componentA.js 
├── reducers 
│ ├── reducer-for-componentA.js 
└── stores ...

これは、そこにすべての発電機は何をしているか皆とあるように思われます。しかし、私はこれがプロジェクトを構成する反応的な方法ではないと感じています。焦点はコンポーネントにあるべきであり、反応や還元の個々の構造にではありません。 ComponentX - > ChildOfXで始まるコンポーネント階層に含まれているPageXのボタンを変更する必要があるときに、まったく同じ方法でディレクトリをトラバースできるはずです。

ではなく、その中にスローされるすべてのコンポーネントとコンポーネントのフォルダを持つ私はむしろのようなものだろう：これはトラバースが容易になり、あなたが「反応」で考えるとき、それはより理にかなって

js 
├── PageX 
│ ├── action-for-pagex.js 
    ├── componentX.js 
    ├── containerX.js 
    ├── reducerX.js 
    ├── children 
     ├── childrenC 
     ├── childrenB 
      ├── componentB.js 
      ├── reducerB.js 
      ├── ... 
├── PageY 
│ ├── ... 
├── PAgeZ 
│ ├── ...

を。誰もこのアプローチで間違っているかもしれない何かを見ることができますか？

出典

2016-03-24 ralzaul

TL; DR には、標準またはアプリケーションのコードを構造化する適切な方法はありません。それは主にあなたの好みについてです。

私はReactとReduxでの経験のおかげで答えを出します。今、私はR & Rスタックを使った巨大なプロジェクトに携わっています。私たちの技術チームは、線形でスケーラブルなコーディング方法を保つ必要があるため、フォルダー構造について話すのに多大な時間を費やしました。

基本的に、私たちは、あなたが提供した2つの例をミックスしたハイブリッドアプローチを使用しています。 2番目のアプローチは「機能別フォルダ構造」と呼ばれ、最初は「種類別フォルダ構造」と呼ばれます。

React/Reduxスタックは標準化されたタイプセットのファイルを使用しているので、アプリケーションツリーをきれいに整えてスケーラブルにするのは簡単です。

当社の技術チームがあることで合意した

：各主成分がpagesフォルダの下に際立って

。
各ページには、いくつかのサブコンポーネントも含まれている場合があります。
コンポーネント
我々はまた、いくつかのヘルパー関数フォルダを維持component.jsエントリポイントを使用しており、同様に、実際に継承とsharedフォルダの下に配置されている複数の親コンポーネントから使用されている
サブコンポーネントを減速機を使用することができますいくつかの定数とユーティリティを保持するフォルダがあります。これは主に、アクション・ディスパッチャがアプリケーション・ライフサイクルで共通のアクションを使用するためです。
アプリケーションは、単一のコンテナ、単一のストア、および単純なエントリポイント（app.js）によってブートストラップされます。
すべてを適切に保持するために、ES6のインポートステートメントを使用します。ここで

私たちのファイル構造の模式的なバージョンです：

constants 
    -- const.js 
    -- const2.js 
helpers 
    --helperfunc1.js 
shared 
    --Shared Element1 
    --- component.js 
    --- reducer.js 
    --Shared Element2 
    --- component.js 
    --- reducer.js 
specs 
    -- spec1.js 
    -- spec2.js 
pages 
-Page1 
-- Subpage1 
    --- component.js 
    --- reducer.js 
    -- Subpage2 
    --- component.js 
    --- reducer.js 
    -- component.js 
-- reducer.js 
-Page2 
-- component.js 
-- reducer.js 
... 
container.js 
app.js 
reducer.js

我々は、コーディング機能を追加し、私たちのアプリケーションを維持ままとして、我々はこのアプローチのいくつかの長所を書き留めた： - ファイル名はかなり短いです読みやすい。 - ファイル構造は簡単です。 - テストは、コンポーネントとレデューサーをフォルダからインポートするのが簡単です。 - ネーミングボトルネックが捨てられました。 - 名前の問題が少なく、同じフォルダの下にあります。 - もう一度、TableDataComponent.jsはtable/component.jsよりも冗長で難しいです。 - Reactネストされたコンポーネントはフレームワークの不可欠な部分であるため、フォルダ構造はこのロジックを追跡します。コードの内側のレベルは、上にレンダリングされた要素から継承されます。 - アクションリデューサもスムーズにブートストラップされます。

私は、この素晴らしいReddit threadとこのarticleを読んで、時間を費やすことをお勧めします。いくつかの素晴らしい点は、上記のとおりです。

出典

2016-03-25 00:11:51 Theodore

に動作します。 – Nicole