Redux: connect（）の推奨される使用法

私はブレントに強く同意します。 これは、Relayのようなものの背後にある基本的な考え方の多くであり、より高い結束につながります。

たぶん、「ここでは人によって好みが違う」とだけ言うべきでしょう。

@ gaearon-おそらく、データフローのトレースを複雑にする方法のデモンストレーションを含むトレードオフに関するセクションが役立つでしょう。 私はその好みの私の側に売り込むことができました。

いいね。 最初のドキュメントが落ち着いたら、開いたままにして、もう一度確認しましょう。

@gaearonいいですね！ :)再訪したいときに私にpingしてください

私はReduxを初めて使用しますが、これは昨年の私にとってかなり大きな問題であり、データ構造を大幅に変更したアプリを構築しました。 だから私はこれについて@brentvatneに本当に同意していると言わなければなりません。

多くのコンポーネントをconnect（）するときにデータフローをトレースする以外に問題はありますか？ たとえば、パフォーマンスの低下はありますか？

多くのコンポーネントをconnect（）するときにデータフローをトレースする以外に問題はありますか？ たとえば、パフォーマンスの低下はありますか？

いいえ、まったく逆です。トップダウンフローを放棄することで、パフォーマンスが向上します。

中間レベルのコンポーネントの不要な再レンダリングを回避できるためですか？

はい。

議論に追加するには：私は主にルートコンポーネントへの接続の使用を制限しています。 追加のスマートコンポーネント（フォームモーダルなど）を使用できるページがある場合、回避策は要素またはノードを渡し、ダムコンポーネントにレンダリングさせることでした。 これは、ボイラープレートがもう少しあることを意味しますが、ダムコンポーネントのテストは簡単です。 私はまだこれを実験していますが、これは簡単なテスト容易性をあきらめることなくスマートコンポーネントを作成するための最良の方法かもしれないと思います。

大まかな例を挙げると：

Foo.jsx

export class Foo extends Component {
  render () {
    return (
      <div className='foo'>
        {/* foo stuff going on in here */}
        {this.props.Bar}
      </div>
    )
  }
}

FooContainer.jsx

@connect(getState, getActions)
export class FooContainer extends Component {
  render () {
    return (
      <Foo
        Bar={<BarContainer/>}
        {...this.props}
       />
    )
  }
}

@brentvatne何かを書きたいと思ったら、それを現在のドキュメント構造のどこに収めるかを考えて、自由に先に進んでください！ :-)

2015/10/19更新：このコメントを改善し、 react-redux-provideとしてリリースしました。 以下のhttps://github.com/rackt/redux/issues/419#issuecomment-149325401を参照して

＃475から続けて、私が思いついたものについて説明しますが、この議論はおそらく現在react-redux属しています。 ;）

横向きの割り当てを使用するモジュラープロバイダー

簡単に言うと、私が採用したアプローチは、任意のコンポーネントに割り当てることができるモジュラープロバイダーを中心に展開しています。 これにより、_真の_「ダム」コンポーネントが可能になり、関心の分離が最大限に行われ、互換性のある任意の数のプロバイダーを非常に簡単かつ迅速に使用および共有できるようになります。 また、コンポーネントを更新するためのより効率的な方法を適用します。

だから...私はactions 、 constants 、 containers 、 reducers 、およびstoresディレクトリ（例内で一般的）を取り除きました）そしてそれらを単一のprovidersディレクトリに置き換えました。 あるいは、 providersディレクトリは必要ないかもしれません。このアプローチでは、スタンドアロンプ​​ロバイダーをパッケージ化して配布できるからです。 この特定のアプローチが採用されれば、いくつかの本当にクールなものが現れると思います!! （注：もちろん、これらのディレクトリを1つに統合する必要はありませんが、1）読みやすく、理解しやすく、2）定型文を減らし、3）個々のプロバイダーが十分に小さいので意味があると思います。 ）

「ダム」コンポーネントの例

// components/Branch.js

import React, { Component } from 'react';
import provide from '../utilities/provide.js';
import { branchName, tree, toggle, open, theme } from '../common/propTypes.js';
import Limbs from './Limbs.js';

<strong i="22">@provide</strong>  // maybe require specifying expected props? e.g., @provide('theme')
export default class Branch extends Component {
  static propTypes = { branchName, tree, toggle, open, theme };

  onClick(event) {
    const { branchName, toggle } = this.props;  // toggle is from a provider

    event.stopPropagation();
    toggle(branchName);
  }

  render() {
    const props = this.props;
    const { branchName, tree, open, theme } = props;  // latter 3 from providers
    const classes = theme.sheet.classes || {};
    const imgSrc = open ? 'folder-open.png' : 'folder-closed.png';

    return (
      <div
        onClick={::this.onClick}
        className={classes.branch}
      >
        <h4 className={classes.branchName}>
          <img
            className={classes.branchIcon}
            src={theme.imagesDir+imgSrc}
          />

          <span>{branchName}</span>
        </h4>

        <Limbs
          tree={tree}
          open={open}
        />
      </div>
    );
  }
}

プロバイダーの例

// providers/toggle.js

import createProvider from '../utilities/createProvider.js';

export const TOGGLE = 'TOGGLE';

export const actions = {
  toggle(fullPath) {
    return { type: TOGGLE, fullPath };
  }
};

export const reducers = {
  open(state = {}, action) {
    switch (action.type) {
      case TOGGLE:
        const { fullPath } = action;
        return { ...state, [fullPath]: !state[fullPath] };

      default:
        return state;
    }
  }
};

function merge (stateProps, dispatchProps, parentProps) {
  return Object.assign({}, parentProps, {
    open: !!stateProps.open[parentProps.fullPath]
  });
}

export const provider = createProvider(actions, reducers, merge);
export default provider;

横向きの割り当て

前述のように、アイデアは、任意のプロバイダーを「ダム」コンポーネントに簡単に割り当てることができるようにすることです。 したがって、アプリをマウントするときは、次のように行うことができます。

import React from 'react';
import { Provider } from 'react-redux';

import assignProviders from './utilities/assignProviders.js';
import createStoreFromProviders from './utilities/createStoreFromProviders.js';

import dark from './themes/dark.js';
import github from './sources/github.js';
import * as providers from './providers/index.js';
import * as components from './components/index.js';

const { packageList, sources, toggle, theme } = providers;
const { Branches, Branch, Limbs, Limb } = components;

const initialState = {
  packageList: [
    'github:gaearon/react-redux<strong i="10">@master</strong>',
    'github:loggur/branches<strong i="11">@master</strong>',
    'github:rackt/redux<strong i="12">@master</strong>'
  ],
  sources: {
    github: github({
      token: 'abc123',
      auth: 'oauth'
    })
  },
  open: {
    'github': true,
    'github:gaearon': true,
    'github:gaearon/react-redux<strong i="13">@master</strong>': true,
    'github:rackt': true,
    'github:rackt/redux<strong i="14">@master</strong>': true
  },
  theme: dark
};

const store = createStoreFromProviders(providers, initialState);

assignProviders({ theme }, components);
assignProviders({ packageList }, { Branches });
assignProviders({ sources }, { Branches, Branch });
assignProviders({ toggle }, { Branch, Limb });

React.render(
  <Provider store={store}>
    {() => <Branches/>}
  </Provider>,
  document.getElementById('root')
);

うまくいけば、これはすべて非常に簡単ですが、必要に応じて、より詳細に説明し、説明のためにコメントを追加できれば幸いです。

追加コード

これらの例では、いくつかのユーティリティ関数がインポートされていることに気付くでしょう。 これらは小さなモジュールであり（4つのうち3つは数行の長さです）、基本的には既存のredux react-reduxメソッドと

// utilities/createProvider.js

import { bindActionCreators } from 'redux';
import { connect } from 'react-redux';

/**
 * Creates an object to be used as a provider from a set of actions and 
 * reducers.
 *
 * <strong i="10">@param</strong> {Object} actions
 * <strong i="11">@param</strong> {Object} reducers
 * <strong i="12">@param</strong> {Function} merge Optional
 * <strong i="13">@return</strong> {Object}
 * <strong i="14">@api</strong> public
 */
export default function createProvider (actions, reducers, merge) {
  return {
    mapState(state) {
      const props = {};

      for (let key in reducers) {
        props[key] = state[key];
      }

      return props;
    },

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

    merge
  };
}

// utilities/createStoreFromProviders.js

import { createStore, combineReducers } from 'redux';

import { createStore, applyMiddleware, combineReducers } from 'redux';

/**
 * Creates a store from a set of providers.
 *
 * <strong i="17">@param</strong> {Object} providers
 * <strong i="18">@param</strong> {Object} initialState Optional
 * <strong i="19">@return</strong> {Object}
 * <strong i="20">@api</strong> public
 */
export default function createStoreFromProviders (providers, initialState) {
  const reducers = {};
  const middleware = [];
  let create = createStore;

  for (let key in providers) {
    let provider = providers[key];

    Object.assign(reducers, provider.reducers);

    if (provider.middleware) {
      if (Array.isArray(provider.middleware)) {
        for (let mid of provider.middleware) {
          if (middleware.indexOf(mid) < 0) {
            middleware.push(mid);
          }
        }
      } else if (middleware.indexOf(provider.middleware) < 0) {
        middleware.push(provider.middleware);
      }
    }
  }

  if (middleware.length) {
    create = applyMiddleware.apply(null, middleware)(createStore);
  }

  return create(combineReducers(reducers), initialState);
}

// utilities/assignProviders.js

/**
 * Assigns each provider to each component.  Expects each component to be
 * decorated with `@provide` such that it has an `addProvider` static method.
 *
 * <strong i="5">@param</strong> {Object} providers
 * <strong i="6">@param</strong> {Object} components
 * <strong i="7">@api</strong> public
 */
export default function assignProviders (providers, components) {
  for (let providerName in providers) {
    let provider = providers[providerName];

    if (provider.default) {
      provider = provider.default;
    } else if (provider.provider) {
      provider = provider.provider;
    }

    for (let componentName in components) {
      let addProvider = components[componentName].addProvider;
      if (typeof addProvider === 'function') {
        addProvider(providerName, provider);
      }
    }
  }
}

最後になりましたが、 provideデコレータがあります。 これは、横向きの割り当てを可能にするように設計されたconnect修正バージョンです。

// utilities/provide.js

import React, { Component, PropTypes } from 'react';
import createStoreShape from 'react-redux/lib/utils/createStoreShape';
import shallowEqual from 'react-redux/lib/utils/shallowEqual';
import isPlainObject from 'react-redux/lib/utils/isPlainObject';
import wrapActionCreators from 'react-redux/lib/utils/wrapActionCreators';
import invariant from 'invariant';

const storeShape = createStoreShape(PropTypes);
const defaultMapState = () => ({});
const defaultMapDispatch = dispatch => ({ dispatch });
const defaultMerge = (stateProps, dispatchProps, parentProps) => ({
  ...parentProps,
  ...stateProps,
  ...dispatchProps
});

// Helps track hot reloading.
let nextVersion = 0;

export default function provide (WrappedComponent) {
  const version = nextVersion++;
  const providers = [];
  let shouldSubscribe = false;

  function getDisplayName () {
    return ''
      +'Provide'
      +(WrappedComponent.displayName || WrappedComponent.name || 'Component')
      +'('+providers.map(provider => provider.name).join(',')+')';
  }

  function addProvider (name, { mapState, mapDispatch, merge }) {
    if (Boolean(mapState)) {
      shouldSubscribe = true; 
    }

    providers.push({
      name,
      mapState: mapState || defaultMapState,
      mapDispatch: isPlainObject(mapDispatch)
        ? wrapActionCreators(mapDispatch)
        : mapDispatch || defaultMapDispatch,
      merge: merge || defaultMerge
    });

    Provide.displayName = getDisplayName();
  }

  function computeStateProps (store) {
    const state = store.getState();
    const stateProps = {};

    for (let provider of providers) {
      let providerStateProps = provider.mapState(state);

      invariant(
        isPlainObject(providerStateProps),
        '`mapState` must return an object. Instead received %s.',
        providerStateProps
      );

      Object.assign(stateProps, providerStateProps);
    }

    return stateProps;
  }

  function computeDispatchProps (store) {
    const { dispatch } = store;
    const dispatchProps = {};

    for (let provider of providers) {
      let providerDispatchProps = provider.mapDispatch(dispatch);

      invariant(
        isPlainObject(providerDispatchProps),
        '`mapDispatch` must return an object. Instead received %s.',
        providerDispatchProps
      );

      Object.assign(dispatchProps, providerDispatchProps);
    }

    return dispatchProps;
  }

  function computeNextState (stateProps, dispatchProps, parentProps) {
    const mergedProps = {};

    for (let provider of providers) {
      let providerMergedProps = provider.merge(
        stateProps, dispatchProps, parentProps
      );

      invariant(
        isPlainObject(providerMergedProps),
        '`merge` must return an object. Instead received %s.',
        providerMergedProps
      );

      Object.assign(mergedProps, providerMergedProps);
    }

    return mergedProps;
  }

  const Provide = class extends Component {
    static displayName = getDisplayName();
    static contextTypes = { store: storeShape };
    static propTypes = { store: storeShape };
    static WrappedComponent = WrappedComponent;
    static addProvider = addProvider;

    shouldComponentUpdate(nextProps, nextState) {
      return !shallowEqual(this.state.props, nextState.props);
    }

    constructor(props, context) {
      super(props, context);
      this.version = version;
      this.store = props.store || context.store;

      invariant(this.store,
        `Could not find "store" in either the context or ` +
        `props of "${this.constructor.displayName}". ` +
        `Either wrap the root component in a <Provider>, ` +
        `or explicitly pass "store" as a prop to "${this.constructor.displayName}".`
      );

      this.stateProps = computeStateProps(this.store);
      this.dispatchProps = computeDispatchProps(this.store);
      this.state = { props: this.computeNextState() };
    }

    recomputeStateProps() {
      const nextStateProps = computeStateProps(this.store);
      if (shallowEqual(nextStateProps, this.stateProps)) {
        return false;
      }

      this.stateProps = nextStateProps;
      return true;
    }

    recomputeDispatchProps() {
      const nextDispatchProps = computeDispatchProps(this.store);
      if (shallowEqual(nextDispatchProps, this.dispatchProps)) {
        return false;
      }

      this.dispatchProps = nextDispatchProps;
      return true;
    }

    computeNextState(props = this.props) {
      return computeNextState(
        this.stateProps,
        this.dispatchProps,
        props
      );
    }

    recomputeState(props = this.props) {
      const nextState = this.computeNextState(props);
      if (!shallowEqual(nextState, this.state.props)) {
        this.setState({ props: nextState });
      }
    }

    isSubscribed() {
      return typeof this.unsubscribe === 'function';
    }

    trySubscribe() {
      if (shouldSubscribe && !this.unsubscribe) {
        this.unsubscribe = this.store.subscribe(::this.handleChange);
        this.handleChange();
      }
    }

    tryUnsubscribe() {
      if (this.unsubscribe) {
        this.unsubscribe();
        this.unsubscribe = null;
      }
    }

    componentDidMount() {
      this.trySubscribe();
    }

    componentWillReceiveProps(nextProps) {
      if (!shallowEqual(nextProps, this.props)) {
        this.recomputeState(nextProps);
      }
    }

    componentWillUnmount() {
      this.tryUnsubscribe();
    }

    handleChange() {
      if (this.recomputeStateProps()) {
        this.recomputeState();
      }
    }

    getWrappedInstance() {
      return this.refs.wrappedInstance;
    }

    render() {
      return (
        <WrappedComponent ref='wrappedInstance' {...this.state.props} />
      );
    }
  }

  if ((
    // Node-like CommonJS environments (Browserify, Webpack)
    typeof process !== 'undefined' &&
    typeof process.env !== 'undefined' &&
    process.env.NODE_ENV !== 'production'
   ) ||
    // React Native
    typeof __DEV__ !== 'undefined' &&
    __DEV__ //eslint-disable-line no-undef
  ) {
    Provide.prototype.componentWillUpdate = function componentWillUpdate () {
      if (this.version === version) {
        return;
      }

      // We are hot reloading!
      this.version = version;

      // Update the state and bindings.
      this.trySubscribe();
      this.recomputeStateProps();
      this.recomputeDispatchProps();
      this.recomputeState();
    };
  }

  return Provide;
}

provideデコレータについて言及する価値のあることの1つは、 react-devtoolsを使用してすべてを見ると、次のようなものが表示されることです（ BranchesはProvideBranches(theme,packageList,sources)ラップされます）

これの代わりに（元のconnectで表示され、 BranchesはConnect(Branches)ラップされます）：

制限事項

私は2日前にreduxについて学び始めたばかりなので、このアプローチの結果としてどのような制限が存在するのか（もしあれば）正直にわかりません。 頭から離れて、私は本当に何も考えることができず、すべてが私のユースケースで完全に機能しているように見えますが、おそらくより経験豊富な誰かがチャイムを鳴らすことができます。

この特定のアプローチを思いついたのは、任意のプロバイダーを割り当てることができる_真の_「ダム」コンポーネントを持つというアイデアが本当に好きだからです。 関心の分離を強制し、モジュールとして簡単に交換できるプロバイダーをいくつでも使用できるようにします。

さらに、 @ gaearonがこのアプローチを気に入っており、 react-reduxの範囲内にあると思われる場合は、追加のPRを提出していただければreact-redux-providers作成して公開し、最終的にはサンプルプロバイダー（たとえば、 react-redux-provide-toggle ）といくつかの実際の例を公開します。

中間レベルのコンポーネントの不要な再レンダリングを回避できるためですか？

はい

ここでの方向性は、状態（App状態とUI状態の両方。コンポーネントにUI状態を保持）にImmutable.jsを使用し、すべてのコンポーネントにPureRenderMixinを使用することです。 これにより、トップダウンフローを使用することによるパフォーマンスの低下が解消されませんか？

編集：下位レベルのコンポーネントの1つを再レンダリングする必要がある場合、中間レベルのコンポーネントのパフォーマンスの低下を排除できないことに気づきましたが、それでも多くのオーバーヘッドを排除する必要があります。 それについて何か経験はありますか？

@ danmaz74私たちはそのようなシナリオでパフォーマンスの問題にぶつかっています（reduxではなく、非常によく似た自家製のlibを使用しています）。 ただし、非常に「高価な」コンポーネントを含む、かなり複雑なアプリがあります。 また、アプリが大きくなるにつれて、トップレベルだけでなく多くの場所にデータを挿入することで、コンポーネント間に暗黙の依存関係が作成されるのを防ぎ、親が子のデータ要件についてあまり知らないようにすることができます。

@eldh更新してくれてありがとう、それは理にかなっています。 続行する間、それを覚えておきます:)

これに関する更新はありますか？ timburの例は私には完全に理にかなっていますが、シングルコネクトの練習は私にはよくわかりません。 私は反対の議論、すなわち「人々はここで異なる好みを持っている」に興味があります。

単一の接続を使用すると、状態をたとえば10コンポーネントの深い階層に変換するために、巨大なmapStateToProps関数が必要になります...その背後にある考えが何であるか、または何かを誤解しているかどうかは少し混乱しています...

単一の接続を使用すると、巨大なmapStateToProps関数が必要になります

誰も単一の接続を支持していません。

次に、react-reduxのconnect（）関数を使用して、Reduxに接続するコンポーネントをラップします。 これは、最上位のコンポーネントまたはルートハンドラーに対してのみ実行してください。 技術的には、アプリ内の任意のコンポーネントをReduxストアにconnect（）できますが、データフローの追跡が困難になるため、これを深くしすぎないようにしてください。

「シングル」とは、例で作成したような小さなアプリのみを指します。 これをより明確にするために、ドキュメントを自由に修正してください。 私は現在他のプロジェクトで忙しいので、誰かがPRをしない限り、この問題が動きを起こすことを期待しないでください。 あなたもそれを行うことができます。

ご説明ありがとうございます。

ついにreact-redux-provideリリースに取り掛かりました。 こちらをご覧ください。 また、数日/数週間以内に他のいくつかのものをリリースする予定です。

とてもよさそうです、ありがとう！

私は新しいreduxプロジェクトを開始したばかりで、「スマート」コンポーネントにconnectを使用しています。これは私にとってはるかに理にかなっています。パフォーマンス上のメリットがある場合は、追加のメリットがあります。 逆に、すべての制御をメインのアプリまたはルーターにまでバブルした場合、SRPは完全に失われます-物事を分解し始める前に、アプリはどのくらいの大きさにする必要がありますか？

関連する要素をコンポーネントフォルダに整理することも考えています。 主成分等の横にレデューサーを入れます。

最終的に、redux / fluxは予測可能な状態にとって大きなメリットであると思いますが、標準のmvからの精神的な変化-UIアプリの開発をシンプルにし、誰もがアクセスできるようにしたものは何でも、最終的にはfluxが抽象化され、移動しますmv *のように見えるものに戻ります。

これは＃1285で修正されています。

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

ねえ、私はここで役立つかもしれないいくつかのものについて書いた。 :)

https://medium.com/@timbur/react -automatic-redux-providers-and-replicators-c4e35a39f1

https://github.com/reactjs/redux/issues/419#issuecomment -183769392も＃1353に役立つと思い

@timbur素晴らしい記事！ この質問についてのあなたの考えも共有していただけませんか： //github.com/reactjs/react-redux/issues/278

これがやみくもに明白であるかどうかはわかりませんが、このスレッドに来るreduxに不慣れな人にとっては、言われていることの多くはおそらく少し抽象的なものだと思うので、明確にするためにここに追加する価値があると思います。

私が最初にreduxを使い始めたとき、アプリがそれほどデカップリングを必要としないと思ったので、誤って「コンテナ」（接続されたコンポーネント）を（単なる古いダム）「コンポーネント」の中に点在させました。 私はどれほど間違っていた。 これらのコンポーネントの多くを再利用する必要があることに気付いたとき、かなりのリファクタリングを行う必要があり、多くのスマートなものをツリーの最上部に移動しましたが、これはすぐに扱いにくくなりました。 上部にある「プロバイダー」は、コンテキストを提供しますが（必要に応じて）、基本的にすべてのアプリを提供します（すべきではありません）。

私がアプローチするのに最適な方法は、プロバイダーを最上位にして、ダムコンポーネントを構成するコンテナーの階層を作成することです。 コンテナは他のコンテナ内にのみ存在する必要があります。 アプリは、コンポーネントを使用してデータを表示するコンテナーの階層である必要があります。

多くの場合、リストを使用してこれを行う良い方法は、スマートコンポーネントを介してIDを渡すことです。 IDの必要性は、何かがアプリのドメインに属していることを示しています。 したがって、可能な場合は、あるコンテナ内のIDのリストを取得し、それらを別のコンテナに渡します。別のコンテナは、IDを使用して必要な情報を取得できます。 各コンテナ内でコンポーネントを使用して、IDを必要とせずにその情報をレンダリングします。

以下に、コンポーネントを使用してそれらを表示するコンテナー階層を介してアプリの接続された部分を渡す方法の（複雑な）例をモックアウトしました。

// Provider component that renders some containers and some components and provides the store
class TodoAppProvider {
  constructor() {
    // setup store etc.
  }

  render() {
    return (
      <Provider store={this.store}> {/* Provider from 'react-redux' */}
        <AppLayoutComponent title="My Todos" footer={<TodoFooter />}>
          <TodoListsContainer />
        </AppLayoutComponent>
      </Provider>
    );
  }
);

// AppLayoutComponent
// Lots of nice css, other dumb components etc. no containers!
export default const AppLayoutComponent = ({ title, children, footer }) => (
  <header>
    {title}
  </header>
  <main>
    {children /* This variable can be a container or components but it's not hardcoded! */}
  </main>
  <footer>
    {footer}
  </footer>
);

// TodoFooter
// Another dumb component
export default const TodoFooter = () => (
  <footer>
    &copy; {Date.now() /* we are copyrighted to the millisecond */}
  </footer>
);

// TodoListsContainer
// Smart component that renders all the lists
class TodoListsContainer extends React.Component {
  render() {
    return () {
      <div>
        {todoLists.map(id => (
          {/* this container renders another container */ }
          <TodoListContainer key={id} todoListId={id} />
        ))}
      </div>
    }
  }
}

const mapStateToProps = state => ({
  todoLists: getTodoLists(state),
});

export default connect(mapStateToProps)(TodoListsContainer);

// TodoListContainer
// Gets the props and visibleTodo IDs for the list
class TodoListContainer {
  render() {
    const { id, title, visibleTodos } = this.props;
    return (
      <div>
        {/* Render a component but passes any connected data in as props / children */}
        <TodoListPanelComponent title={title}>
          {visibleTodos.map(id => (
            <TodoContainer todoId={id} />
          ))}
        </TodoListPanelComponent>
      </div>
    );
  }
}

const mapStateToProps = (state, { todoListId }) => ({
  ...getTodoList(state, todoListId), // A todo object (assume we need all the attributes)
  visibleTodos: getVisibleTodos(state, todoListId), // returns ids
});

export default connect(mapStateToProps)(TodoListContainer);


// TodoListPanelComponent
// render the panel to sit the todos in
// children should be todos
// No containers!
export default const TodoListPanelComponent = ({ title, children }) => (
  <div>
    <h3>{title}</h3>
    <div>
      {children}
    </div>
  </div>
);

// TodoContainer
// This just wraps the TodoComponent and passed the props
// No separate class or JSX required!
const mapStateToProps = (state, { todoId }) => ({
  ...getTodo(state, todoId),
});

const mapDispatchToProps = (dispatch, { todoListId }) => ({
  handleFilter: () => dispatch(hideTodo(id)), // Pass ALL smart stuff in
});

export default connect(mapStateToProps, mapDispatchToProps)(TodoComponent); // Passing in the component to connect

// TodoComponent
// Render the component nicely; again, as all of its connected stuff passed in
// The FilterLinkContainer is an example of a smell that will come back to bite you!
export default const TodoComponent = ({ content, isComplete, handleFilter }) => (
  <div>
    <div>
      {content}
    </div>
    <div>
      {isComplete ? '✓' : '✗'}
    </div>
    <div>
      {/* Don't do this, can't re-use TodoComponent outside the app context! */}
      <FilterLinkContainer />

      {/* Instead do this (or similar), component can be reused! */}
      <Link onClick={handleFilter}>
        'Filter'
      </Link>
    </div>
  </div>
);

したがって、ここでのコンテナ階層はTodoAppProvider > TodoListsContainer > TodoListContainer > TodoContainerです。 それらはそれぞれ互いにレンダリングされ、コンポーネント内でレンダリングされることはなく、生のビューコードは含まれていません（Reactのラッピングの理由で時折divを除いて）。

最終的に、私がそれを考えるのが好きなのは、UIが気にする便利な方法にデータをマップする接続されたコンポーネントのツリーを最初に作成するかのようです。 ただし、UIはまったくなく、コンテナだけの階層を介してマップされた状態のツリー

connect()複数回使用すると、パフォーマンスが低下しますか（または別のアーキテクチャ上の理由）？ 次の方法で接続エントリポイントを抽象化することにより、コンポーネントに頻繁に使用される小道具を提供しようとしています。

// connectCommonProps.js (mergeProps not included for the sake of simplicity)

const _mapStateToProps = (state) => ({ [often used slices of state] });

const _mapDispatchToProps = (dispatch) => ({ [often used actions] });

const connectCommonProps = (mapStateToProps, mapDispatchToProps, component) => {
    // First connect
    const connectedComponent = connect(mapStateToProps, mapDispatchToProps)(component);

    // Second connect
    return connect(_mapStateToProps, _mapDispatchToProps)(connectedComponent);
};

export default connectMapAndFieldProps;

// Some component that needs the often used props
...
export default connectCommonProps(..., ..., Component);

私はここで怠惰で、宣言を単純に保つため、2つのバージョンのmapStateToPropsと2つのバージョンのmapDispatchToProps組み合わせませんでした。 しかし、 connectそれを任せるのは悪い考えかどうか疑問に思います。

@timotgl ：Danはアクティブなメンテナではなくなりました。直接pingしないでください。

複数のコンポーネントの接続に関するReduxFAQエントリであなたの質問に答えていると言っていましたが、別のことについて質問しているようです-意図的に複数の接続を単一のコンポーネントにラップしていますか？ これまで誰かがそうしているのを見たことがないとは言えませんし、Reduxコードを_たくさん_見たことがあります。

個人的には、別のアプローチを試すことをお勧めします。 「共通の小道具」HOCか、ほとんどの場合それらを子に渡すだけのものを用意するか、セレクターを使用して特定のコンポーネントのmapState関数で共通の小道具を取得し、それらを必要な特定の小道具と組み合わせます。

@markerikson申し訳ありませんが、それを知りませんでした、at-mentionは削除されました。

したがって、まず第一に、それは機能し、コンポーネントは、react devツール内の他の接続されたコンポーネントのように見えます。追加のラッパーなどはありません。

OOP /継承パラダイムを関与させたくなかったので、HOCに反対することにしました。これは、コンポーネントにいくつかの小道具を提供するだけなので、それ以外の動作は変更されません。

mapStateToProps配線することの良い点。 それは機能しますが、少なくとも2つのエントリポイントがあります。1つのヘルパー関数を呼び出して接続する方が簡単なようです。

「2つのエントリポイント」の意味がわかりません。

私が描いているのは次のようなものです：

import {selectCommonProps} from "app/commonSelectors";

import {selectA, selectB} from "./specificSelectors";

const mapState = (state) => {
    const propA = selectA(state);
    const propB = selectB(state);
    const commonProps = selectCommonProps(state);

    return {a, b, ...commonProps};
}

@markerikson 2つのエントリポイントとは、 mapDispatchToPropsについても、場合によってはmergePropsについても同じことを行う必要があることを意味します。

mergePropsを使用することはほとんどありません。これは最後の手段として使用されます。エスケープハッチとして使用することはお勧めしません。 また、実際には実際のmapDispatch関数を記述せず、代わりに「オブジェクトの省略形」を使用することをお勧めします。

import {addTodo, toggleTodo} from "./todoActions";

class TodoList extends Component {}

const actions = {addTodo, toggleTodo};
export default connect(mapState, actions)(TodoList);

すべての「一般的な」アクションクリエーターを再エクスポートするindex.jsファイルを簡単に作成して、次のようなことを行うことができます。

import * as commonActions from "app/common/commonActions";
import {specificAction1, specificAction2} from "./actions";

const actionCreators = {specificAction1, specificAction2, ...commonActions};

export default connect(null, actionCreators)(MyComponent);

mergePropsを使用することはほとんどありません。これは最後の手段として使用されます。エスケープハッチとして使用することはお勧めしません。

こんにちは@markerikson 、なぜ誰かがmergePropsの使用を避けるべきなのか興味がありますか？ mapDispatchToPropsのアクションで必要になる可能性があるが、コンポーネントでは必要のない小道具をmapStateToPropsから「非表示」にするのは非常に便利です。 それは悪いことですか？