Redux: コンテナとコンポーネント？

• コンテナコンポーネント
• スマートでダムなコンポーネント

私の場合、 containerはルートのハンドラーであり、そのルートのreduxの状態もプルします。 それから私は自分の状態を小道具として伝えます。

例えば、

container / properties.jsx

import React, { Component } from 'react';
import { bindActionCreators } from 'redux';
import { connect }  from 'react-redux';

import * as actions from 'actions/properties';
import Filter from 'components/properties/filter';
import List from 'components/properties/list';
import Pagination from 'components/properties/pagination';

class PropertiesContainer extends Component {
  render() {
    return (
      <section>
        <Filter filter={this.props.properties.params.filter} />
        <List items={this.props.properties.items} isFetching={this.props.properties.isFetching} />
        <Pagination pagination={this.props.properties.params.pagination} />
      </section>
    );
  }
}

function mapState(state) {
  const { properties } = state;

  return { properties };
}

function mapDispatch(dispatch) {
  return {
    actions: bindActionCreators(actions, dispatch),
  };
}

const Connector = connect(mapState, mapDispatch)(PropertiesContainer);

export default Connector;

そして、例えば、

components / properties / pagination.jsx

import React, { Component } from 'react';
import Pager from 'components/ui/pager';

class Pagination extends Component {
  render() {
    const { total, offset, limit } = this.props.pagination;
    const current = offset / limit;

    return (
      <Pager total={total} current={current} />
    )
  }
}

export default Pagination;

あなたが提供したリンクから読む：

"A container does data fetching and then renders its corresponding sub-component. "

「コンテナ」は実際にはreduxで「スマートコンポーネント」と呼ばれるものであると私はより感じます...そしてルート/ページは独自のフォルダを取得する必要があります。

「コンテナ」と「ルートハンドラ」が何らかの形で関連している理由がわかりませんか？

アプリのコンポーネントをルートごとにグループ化することは非常に一般的な方法です。 @theaquaが指摘したように、各ルートハンドラー/コンポーネントをスマート/コンテナーコンポーネントにすることも一般的です。 CombineReducersを使用している場合、同じ行に沿って状態、ルート、およびコンテナーを分割していることに気付くことがよくあります。 したがって、それらはしばしば一緒に関連付けられます。

@ronagコンテナやページを作成する必要はないと思いました。 ルートハンドラーとreduxコネクタを1か所の状態にできないのはなぜですか？ とても便利です。 複雑にしないでおく。

私のアプリケーションでは、3つのルート/ページしかありません。 一方、私はたくさんの独立したパネル/モジュールを持っています。 1つの巨大なconnectを作成することは現実的ではありません。少なくとも、パネルの観点から分割する必要があります。

状態から小道具へのすべてのマッピングとすべてのデータフェッチを単一のファイルで行うと、保守できなくなります。 特に、すべてのデータフェッチを同じ場所で行う場合。

ルートが3つある場合は、3つのルートハンドラーが必要です。 たとえば、 A.jsx 、 B.jsx 、 C.jsx /containersです。

各コンテナで、redux状態の一部（全体ではありません！）をプルすると、アクションがバインドされます。 次に、これを私の例のようにコンポーネントに渡します。 私（と私のチーム）が知っているので、それは非常に保守可能です— reduxに接続し、アクションは常にcontainersでバインドされ、 componentsなることはありません（これは小さく、私の例のようにステートレスであることがよくあります） ）。

私はあなたの提案を理解していると思います。 ただし、前述したように、すべてのデータフェッチをそこに配置すると、これら3つのファイルは非常に複雑になります。 私たちの原因では、基本的に「ログイン、アプリ、ログアウト」であり、アプリにはほとんどすべてが含まれます。

たぶん私はRelayに偏りすぎており、各コンポーネントには、フェッチするデータとその外観を説明するコンテナーがあります。

私はあなたの提案を試して、私たちがどこに行き着くかを見ます。

私はcomponentsカプセル化されたReactコンポーネントを呼び出します。これは、小道具によってのみ駆動され、Reduxとは通信しません。 「ダムコンポーネント」と同じです。 ルーターやデータフェッチライブラリなどに関係なく、同じままである必要があります。

私はcontainers Reactコンポーネントを呼び出します。これらは、Redux、ルーターなどを認識しています。これらは、アプリとより結合されています。 「スマートコンポーネント」と同じです。

@gaearon ：完璧です。 これで例が明確になります。 ありがとうございました。

@gaearonつまり、「ダムコンポーネント」はステートレスコンポーネントであり、 React 0.14以降、より単純な構文で記述できます。次に例を示します。

var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

私は正しいですか？

@soulmachineうん。

必ずしも。 構文は重要ではありません。

「ダム」コンポーネント、別名「プレゼンテーション」コンポーネントは、小道具によってすべてのデータを受け取り、Reduxを認識せず、外観のみを指定し、動作は指定しないコンポーネントです。

@theaqua @gaearonありがとう！

「コンテナ」という用語は、react / reduxの命名法ですでに非常に人気がありますが、レイアウト/グラフィックコンテナとの混同を避けるために、私が取り組んでいるプロジェクトでは「コネクタ」と呼ぶことにしました。

ところで、それらを呼び出す方法は、ここで以前にrackt / react-redux＃170で説明されています。 私はすべてをcomponentsフォルダー内に保持し、プレゼンテーション用のものは1レベル深く、 components/presentational内に保持します。コンテナー以外のアプリの部分で必要になる可能性は低いため、問題ないと思います。

@gaearonは、 dispatch 「ダム」または「スマート」と見なしたコンポーネントですか？ ディスパッチを実行するためにイベントをトップコンポーネントにバブリングする代わりに、アクションをディスパッチするリーフまたは中間コンポーネントがあると特に便利です。

ええ、私connect()そのようなコンポーネントを

コンポーネントのモジュールを構築するときはどうですか？ たとえば、ナビゲーションメニュー用に別のノードモジュールがあるとします<NavMenu>人々に次のようなコードを実行してもらいたい：

import {NavMenu} from 'my-redux-aware-components';

export function myPage(props) {
  return (<div><NavMenu routes={props.routes} /></div>);
}

だから私はそれを「NavMenuContainer」と名付けるだけですか？ それは私には奇妙に思えます。 代わりに、コンポーネントにNavMenuComponentという名前を付ける必要がありますか？ どちらも私には奇妙に思えます。 この場合、コンポーネントは接続を呼び出すだけで、状態から1つのフィールドを取得します。 このように接続するために呼び出しをインライン化するのは本当に悪いですか？

export default const NavMenu = connect(state => ({currentPath:state.routing.path})(React.createClas({...}));

接続呼び出しをインライン化するだけで「大丈夫」なのはいつか（もしあれば）についての

どのように呼んでも構いません。 それをNavMenuと呼んでみませんか？

インライン化についての質問がわかりません。
比較している2つのアプローチを提示すると役立ちます。

たとえば、そうですね。
オプション1（2つの個別のファイル、1つはコンテナー用、1つはコンポーネント用）

コンテナ/ NavMenu

import {connect} from 'react-redux';
import NavMenu from '../components/NavMenu';

export default connect(state => ({currentPath:state.routing.path})(NavMenu);

オプション2（両方を含む1つの単一ファイル）：
コンポーネント/ NavMenu

import {connect} from 'react-redux';

export default connect(state => ({currentPath:state.routing.path})(React.createClass({
  render() {
      return <div>the menu {this.props.currentPath} goes here</div>;
  }
});

インライン化とは、状態から必要なcurrentPathについてほんの少ししかないため、コンテナとコンポーネントの両方である1つのファイル（2つのファイルではなく）を持つことを意味します。 これは常に避けるべきものですか、それともこのような単純なケースで行うのが合理的ですか？

確かに、単純なケースでこれを行うのは合理的です。

うんいいね。 いつ線を引いて「これを2つの別々のファイルに移動します」と言いますか？

コンポーネントがデータの懸念事項（データの取得/計算方法、アクションのディスパッチ方法）とプレゼンテーション（外観）を混合し始めたとき。 別のコンテキストでテストまたは再利用することが困難になったとき。

@benmonroもう1つ考えました。 コンポーネントのモジュールを構築している場合は、これらのコンポーネントをアプリの状態ツリーのさまざまな部分に接続したり、さまざまな状態で個別にプレゼンテーションをテストしたりすることがあります。 この場合、コンポーネントのこのモジュール内にconnectがあると、この機能が制限されます。

ありがとう@gaearon

@sompylasar非常に良い点です！ ありがとう

コードをリファクタリングして分割した後、フォローアップの質問があります。 <NavMenuItem>コンテナもあるとします。 <NavMenu>コンポーネントは、子要素として<NavMenuItem />を参照する必要があります。 NavMenuコンポーネントでimport NavMenuItem from '../containers/NavMenuItem'を実行する必要がありますか？ これはテスト容易性@sompylasarにどのように影響しますか？

NavMenuItemを純粋なプレゼンテーションコンポーネントにし、必要なすべてのデータをNavMenuによって小道具を介して渡されます。 これにより、個別にテストできます。 したがって、2つのプレゼンテーション（NavMenu、NavMenuItem）と1つの接続された（connect（...）（NavMenuItem））コンポーネントがあります。

このディスカッションで私が見逃していること：1つのファイルにそれらがある場合、テストに浅いレンダリングを使用することはできません。 プレゼンテーションコンポーネントとコンテナコンポーネントの両方を公開してこれを回避し、個別にテストするのを見てきました。したがって、この場合は、これらが2つであることを明示するために2つのファイルが必要です。 これはまた、ここでの関心の分離と、プレゼンテーションコンポーネントが独立していて再利用可能であるという事実を浮き彫りにします。

FWIW現在の考えを反映するために、プレゼンテーションとコンテナコンポーネントの記事を更新しました。

更新されたドキュメントでコンテナコンポーネントを作成することは推奨されなくなりました。
http://redux.js.org/docs/basics/UsageWithReact.html

Reduxドキュメントの実際の例の@gaearonは、コンポーネントが子としてコンテナを持つことができるようです。
私が間違っている？ これは、内部をスマートにするダムコンポーネントのテスト容易性にどのように影響しますか？
ただし、コンポーネントを階層内の最新のコンポーネントにする方法が見つかりません...

Simple Data Listコンポーネント（ダム）をレンダリングするアプリがあります。
その中ですべてのアイテムがストアに接続されている必要があるので、それはスマートなものです。

ドキュメントによると大丈夫ですが、問題が発生する可能性はありますか？

感謝！

これは、内部をスマートにするダムコンポーネントのテスト容易性にどのように影響しますか？

これにより、テストのセットアップが少し難しくなります（ストアも初期化する必要があります）。 これが不便な場合は、 childrenを受け入れるプレゼンテーションコンポーネントをさらに抽出して、コンテナコンポーネントを内部に渡すことができるようにします。 一般に、分割はあなた次第であり、トレードオフ（書き込みの容易さ、リファクタリング、テストなど）を評価し、コンポーネントを自分で分離する方法を選択する必要があります。

わかりました、それで正しい方法はありません。 ケースバイケースで評価する必要があります。
ありがとう！

IIは2016 febbraio 8をlunedì、ダン・アブラモフ[email protected]ヘクタール
スクリット：

これは、内部でレンダリングされるダムコンポーネントのテスト容易性にどのように影響しますか
スマートなもの？

これにより、テストのセットアップが少し難しくなります（初期化する必要があります）
ストアも）。 これが不便な場合は、さらに抽出してください
コンテナを渡すことができるように子を受け入れるプレゼンテーションコンポーネント
内部のコンポーネント。 一般的に、分割はあなた次第であり、あなたはする必要があります
トレードオフ（記述のしやすさ、リファクタリング、テストなど）を評価し、
コンポーネントを自分で分離する方法を選択してください。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/rackt/redux/issues/756#issuecomment-181143304 。

ルカ・コロネロ
+39 345 8948718
ルカ。 [email protected]

「レイアウトコンポーネント」はどうですか？ つまり、ルーター/ナビゲーターに渡すために単一のコンポーネントに含める必要のあるコンテナーが多数ある場合、このラッピングコンポーネントは、「コンテナーのダムプレゼンテーションコンテナー」になりますよね？

@ Emilios1995同じ問題があります...
レイアウトコンポーネント内で使用するPageコンポーネントがあります。
このレイアウトコンポーネントには、メニュー、ヘッダー、フッターがあります。コンテンツは、ページからレイアウトに渡される子です。
メニューとヘッダーはコンテナです！ したがって、レイアウトは潜在的にコンテナですが、ストアに接続されていません。

ただし、メニューとヘッダーのレイアウトに渡そうとすると、レイアウト（コンポーネント）をレンダリングするページ（コンテナー）があり、メニューとヘッダー（コンテナー）を渡します。

これを行うと階層は正しいですが、すべてのページでメニューとヘッダーを繰り返す必要があり、それらのビットはすべてのページで同じです。

@LucaColonnelloコードがないと問題はよくわかりません。 問題を説明する簡単な例を使用してStackOverflowの質問を作成するようにお願いできますか？ よろしくお願いします。

できるだけ速くに

イルサバト27 febbraio 2016、ダン・アブラモフ[email protected]ヘクタール
スクリット：

@LucaColonnellohttps ：//github.com/LucaColonnello私はよくありません
コードなしで問題を理解します。 作成していただけますか
あなたの問題を説明する簡単な例でStackOverflowの質問？ 私は
喜んで見てください。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/reactjs/redux/issues/756#issuecomment-189672067 。

ルカ・コロネロ
+39 345 8948718
ルカ。 [email protected]

@gaearonそれは問題ではありません、私がここで作った質問だと思います： http ： //stackoverflow.com/questions/35729025/should-the-route-handlers-use-containers-or-presentational-components ？ noredirect = 1＃comment59133192_35729025

ダンのミディアムに関する記事だと思います
https://medium.com/@dan_abramov/smart -and-dumb-components-7ca2f9a7c7d0＃.3y00gw1mq
すべての問題を明確にします...

2016年3月1日午後06時19分GMT + 01：00エミリオSrougo [email protected] ：

@gaearon https://github.com/gaearonそれは問題ではありません、私はそれが問題だと思います
むしろ私がここでした質問：
http://stackoverflow.com/questions/35729025/should-the-route-handlers-use-containers-or-presentational-components?noredirect=1#comment59133192_35729025

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/reactjs/redux/issues/756#issuecomment-190820426 。

ルカ・コロネロ
+39 345 8948718
ルカ。 [email protected]

@gaearonプレゼンテーションコンポーネントにコンテナコンポーネントが含まれている可能性がある場合、どのように再利用できるのでしょうか。
ご参考までに：

• https://medium.com/@lars.jagare/pure -components-ftw-63e6e6c733f0＃.yw9hmwjuq
• https://medium.com/@rpominov/how -does-this-work-when-we-use-containers-inside-presentational-components-cb458e818913＃.rnxlghull

プレゼンテーションコンポーネントにコンテナコンポーネントが含まれている可能性がある場合、どのように再利用できるのでしょうか。

すべての使用シナリオに特定のコンテナが含まれている場合、それについて再利用できないものはわかりません。 そうでない場合は、 this.props.childrenを受け入れて、特定のコンテナーまたはプレゼンテーションコンポーネントを内部に渡す他のプレゼンテーションコンポーネントを作成します。

@gaearon [ルートコンポーネント]コンテナコンポーネントはReact-Routerにありますか？

• route.js

<Route path="/" component={Root}>
      <IndexRoute component={Main} />
      <Route path="/account/signIn" component={SignIn} />
</Route>

• root.js

export default class Root extends React.Component {
  render() {
    return (
      <div>
        <div id="container" className="container">
          {this.props.children}
        </div>
      </div>
    );
  }

ありがとう。

上記の@gaearonは、（親コンポーネントから受け渡すのではなく）ディスパッチにアクセスするためにコンポーネントを接続することを好むと述べました。

これらのコンポーネントを接続し、現在親から渡されているレデューサーからマッピングできる小道具もある場合、これらをリファクタリングしてconnectから取得しますか？ または、 ownPropsを使用して、親から渡されたままにします。

2つのオプションの間に機能/パフォーマンスの違いはありますか？

私は巨大なreduxプロジェクトでの作業経験はあまりありませんが、react / reduxファイル構造の最適化について多くのことを研究して考えてきました。 これが理にかなっているかどうか教えてください：

src/
  components/
    header/ 
      navigation.js # nav menu list
      index.js # Header component
  modules/
    header/
      actions.js # header actions (sticky scroll, collapse mobile menu, etc...)
      reducer.js # header actions reducer (export to modules index)
      index.js # HeaderContainer (connect to Header component)
    index.js # combineReducers and export default configureStore (and middleware)

別の概念：

src/
  components/
    navigation.js
    logo.js
    link.js
    list.js
    item.js
  modules/
    header/
      actions.js # header actions 
      wrapper.js # header class (smart) component - to wrap header with functionality (was previously classified as container)
      container.js # header functional (dumb) component - to contain universal components
      index.js # header actions reducer - to export into modules rootReducer 

それとも、コンポーネント、コンテナ、reduxモジュールを別々に保つ方が良いですか（同じ名前を共有している場合でも）？ ご入力いただきありがとうございます。

私はエンタープライズレベルのreact-reduxプロジェクトを扱ってきましたが、私の経験から、プロジェクトのアーキテクチャをどのように定義するかはあなた次第だと言えます。 Reactの目的が再利用可能なコンポーネントベースのUIを作成することであるという意味で実用的ではないため、コンテナ/コンポーネントベースのアーキテクチャのバリエーションには従いません。

そこで、モジュールに基づいてプロジェクト全体をグループ化するという単純なアプローチを考え出しました。これまで、スケーラビリティ、保守性、およびコードの可読性の点で非常にうまく機能していました。

私にとって、コンテナとスマートコンポーネントはまったく同じです。 簡単な定義は次のとおりです。
コンテナ/スマートコンポーネントは、JSXマークアップ+イベントハンドラー+ API呼び出し+ reduxのconnect / MSTP / MSDPを含むものです。
ダムコンポーネントは、純粋にプレゼンテーション的な機能コンポーネントです。