Redux: 最高の非同期サーバーサイドローディングテクニック？

ねえ、ありがとう！

理想的には、ロードは店舗自体で行われる必要があります

Reduxは、ストアが完全に同期していることを強制します。 あなたが説明することは、代わりにアクションクリエーターで行われるべきです。

デフォルトのサンクミドルウェアでも可能かもしれないと私は思います。 アクションの作成者は次のようになります。

export function doSomethingAsync() {
  return (dispatch) => {
    dispatch({ type: SOMETHING_STARTED });

    return requestSomething().then(
      (result) =>  dispatch({ type: SOMETHING_COMPLETED, result }),
      (error) =>  dispatch({ type: SOMETHING_FAILED, error })
    );
  };
}

ストアでの実際の（きめ細かい）アクションの処理。

ボイラープレートを削除するカスタムミドルウェアを作成することもできます。

天才！ 明らかな何かを見落としていると思いました。 私は_doing_と_storing_の分離が好きです。

このライブラリが成長するのを楽しみにしていますが、すでにかなり完成しています。 乾杯、@ gaearon！

このようなカスタムミドルウェアを作成することもできます

export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    next({ ...rest, readyState: 'request' );
    return promise.then(
      (result) => next({ ...rest, result, readyState: 'success' }),
      (error) => next({ ...rest, error, readyState: 'failure' })
    );
  };
}

デフォルトの代わりに使用します。

これにより、次のような非同期アクションクリエーターを作成できます。

function doSomethingAsync(userId) {
  return {
    type: SOMETHING,
    promise: requestSomething(userId),
    userId
  };
}

そしてそれらをに変えさせる

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, readyState: 'success' }
{ type: SOMETHING, userId: 2, readyState: 'failure' }

ああ、それもいいです、そして私が最初の質問をしたときに私が心に留めていたものの多く。 ストア内のreadyStateをチェックするためにifを追加する代わりに、アクション定数の数を減らすというトレードオフが好きかどうかはわかりません。 私はaddtionalの持つ好むかもしれないと思う_SUCCESSと_FAILUREだけ入れて回避するために、各アクションのバージョンがif内側case 。

でも、ありがとう。

ええ、それは完全にあなたの好み次第です。 types: { request: ..., success: ..., failure: ... }をアクションに変える同様のバージョンを作成できます。 これが、ライブラリに焼き付けるのではなく、ミドルウェアにすることのポイントです。誰もがこれらのことに独自の好みを持っています。

// Middleware
export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, types, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    const [REQUEST, SUCCESS, FAILURE] = types;
    next({ ...rest, type: REQUEST });
    return promise.then(
      (result) => next({ ...rest, result, type: SUCCESS }),
      (error) => next({ ...rest, error, type: FAILURE })
    );
  };
}

// Usage
function doSomethingAsync(userId) {
  return {
    types: [SOMETHING_REQUEST, SOMETHING_SUCCESS, SOMETHING_FAILURE],
    promise: requestSomething(userId),
    userId
  };
}

ああ、私はその解決策が大好きです。 最初に提案したソリューションのように、 then()とdispatch()への追加の呼び出しを行うよりもはるかに優れています。 ミドルウェアにご期待ください。

どのように（そして;-)それが機能するかを教えてください！
カスタムミドルウェアはあまりテストしていません。

} （-1ポイント😀）を省略しましたが、それは魅力のように機能しました！ 初めて。

：+1：

@erikrasサーバーで約束が解決されるのを待って、どのように実装したのか、私は

これは単なる擬似コードなので、どこにも貼り付けないでください。ただし、react-router（APIはreduxと同じくらい速く変化します）を使用しています。

app.get('/my-app', (req, res) => {
  Router.run(routes, req.path, (error, initialState) => {
    Promise.all(initialState.components
      .filter(component => component.fetchData) // only components with a static fetchData()
      .map(component => {
        // have each component dispatch load actions that return promises
        return component.fetchData(redux.dispatch);
      })) // Promise.all combines all the promises into one
      .then(() => {
        // now fetchData() has been run on every component in my route, and the
        // promises resolved, so we know the redux state is populated
        res.send(generatePage(redux));
      });
  });
});

それは何かをクリアしますか？

@iest

Slackでの問題の引用：

私はルートハンドラーを持っています

 static async routerWillRun({dispatch}) {
   return await dispatch(UserActions.fooBar());
 }

ここで、 UserActions.fooBar()は次のとおりです。

export function fooBar() {
 return dispatch => {
   doAsync().then(() => dispatch({type: FOO_BAR}));
 };
}

次に、サーバーレンダリングで次のようになります。

 yield myHandler.routerWillRun({dispatch: redux.dispatch});

しかし、それは機能しません。

ここでの問題は、 fooBarのネストされたメソッドから実際には何も返さないことだと思います。

中括弧を削除します。

export function fooBar() {
  return dispatch =>
    doAsync().then(() => dispatch({type: FOO_BAR}));
}

または、明示的なreturnステートメントを追加します。

export function fooBar() {
  return dispatch => {
    return doAsync().then(() => dispatch({type: FOO_BAR}));
  };
}

いずれにせよ、上記のようにカスタムpromiseミドルウェアを使用する方が簡単かもしれません。

@erikras （Router.runのコールバックで） initialState.componentsとして持っているものに対してfetchDataメソッドを呼び出している最後のコメントに関して、コンポーネント参照を取得するオブジェクトは、一致したルートハンドラーのみを返します。 一致したルートハンドラーではない可能性があるコンポーネント、つまり子コンポーネントに到達することについてどう思いますか？ただし、データをフェッチする必要がありますか？

これが私が話していることの例です

import React from 'react';
import Router from 'react-router';
import {Route, RouteHandler, DefaultRoute} from 'react-router';

//imagine Bar needs some data
const Bar = React.createClass({
  render(){
    return(
      <div>bar</div>);
  }
});

const Foo = React.createClass({
  render(){
    return (
      <div>
        foo
        <Bar/>
      </div>);
  }
});


const App = React.createClass({
  render(){
    return (
      <div>
        <RouteHandler />
      </div>
    );
  }
});

const routes = (
  <Route path="/" handler={App} name="App">
    <DefaultRoute handler={Foo} name="Foo"/>
  </Route>
);

Router.run(routes,'/',function(Root,state){
  console.log(state);
});

出力：

{ path: '/',
  action: null,
  pathname: '/',
  routes: 
   [ { name: 'App',
       path: '/',
       paramNames: [],
       ignoreScrollBehavior: false,
       isDefault: false,
       isNotFound: false,
       onEnter: undefined,
       onLeave: undefined,
       handler: [Object],
       defaultRoute: [Object],
       childRoutes: [Object] },
     { name: 'Foo',
       path: '/',
       paramNames: [],
       ignoreScrollBehavior: false,
       isDefault: true,
       isNotFound: false,
       onEnter: undefined,
       onLeave: undefined,
       handler: [Object] } ],
  params: {},
  query: {} }

ルート内のバーにアクセスできなくなります

@erikras素晴らしい！ それがまさに私が行きたいルートです。 共有していただきありがとうございます。

@iest一致するルートを繰り返すことで、「ルートを下る」というしゃれが意図的に

@mattybowそれは本当です。 何かをロードするためにルートにないコンポーネントが_本当に_必要な場合、唯一のオプションはReact.renderToString() 1回実行し（結果を破棄）、すべてのロードをcomponentWillMount()で実行することです。あなたが行くように約束を保存します。 これは、 react-routerがサーバー側のレンダリングをサポートする前に、私が独自に開発したルーティングソリューションで行っていたことです。 ロードを行うために非ルートコンポーネントが必要になることは、設計上の問題の兆候である可能性があることをお勧めします。 ほとんどのユースケースでは、ルートはそのコンポーネントが必要とするデータを知っています。

@erikras
そこでのソリューションの全体的な例を確認するための公開リポジトリはありますか？

@transedwardやりたかったのですが、ここで詳しく説明した方法を使用したこれまでの

高度な同型の例で+1
私はこれがどこに行くのかが大好きです！

@transedwardこれは、私がまとめた最先端の技術をすべて備えたサンプルプロジェクトです。 https://github.com/erikras/react-redux-universal-hot-example/

@erikrasこれはすごい！ PRを送信して、このREADMEおよびReact Hot Loaderのドキュメントの「スターターキット」セクションに追加していただけますか？

ありがとう！ 提出されたPR。

@erikras素晴らしい-ありがとう！

この会話のいくつかのアイデアに基づいて、約束を処理するミドルウェアを作成したことに注意してください： //github.com/pburtchaell/redux-promise-middleware。

@pburtchaell同様@acdliteすることにより、このライブラリがあります。 https://github.com/acdlite/redux-promise

これに関する2つの考え：

1. アクションに変換されるプロミスは、アクションと一緒に渡され、Reduxストアに配置される可能性があります。

次に、ページをレンダリングする準備ができているかどうかを確認するには、すべてのプロミスが完了したかどうかを確認するだけです。 おそらく、通過するすべてのプロミスをチェーンし、保留中のプロミスがない場合にプロミスを提供するミドルウェアを使用します。

1. セレクターに欠落データのアクションを呼び出させるのはどうですか？

メッセージ3をレンダリングすると、メッセージコンテナは<Message id={3}>をレンダリングし、メッセージセレクタはstate.msgs[3]が存在するかどうかを確認し、存在しない場合はメッセージ読み込みpromiseをディスパッチします。

したがって、2つを組み合わせると、コンポーネントが必要なデータを自動選択し、それらがいつ完了するかがわかります。

「シリアル化できないものをストアやアクションに入れないでください」と確信しています。 それは私にとって本当にうまく機能している（そして例えばタイムトラベルを許可されている）不変条件の1つであり、それを変更することを検討するための_非常に_説得力のある理由が必要です。

次に、ページをレンダリングする準備ができているかどうかを確認するには、すべてのプロミスが完了したかどうかを確認するだけです。 おそらく、通過するすべてのプロミスをチェーンし、保留中のプロミスがない場合にプロミスを提供するミドルウェアを使用します。

これは実際には最終的に店に約束をする必要はありません、そして私はこれが好きです。 違いは、ディスパッチチェーンの最後では、生のアクションにプロミスが含まれていないことです。 それらは、代わりに前述のミドルウェアによって「収集」されます。

プロミスを扱うときに私がよく行うことの1つは、プロミスへの参​​照を維持することです。これにより、同じことに対する他の要求が発生したときに、同じプロミスを返すだけで、デバウンスが提供されます。 次に、promiseが完了した後しばらくして参照を削除し、構成可能なキャッシュを提供します。

Reduxでそれらの参照をどうするか疑問に思うので、実際のアプリでReduxを使い始める必要があります。 actionCreatorをステートレスにする（または少なくとも状態を明示的にする）ために、それらをストアに固定したいと思います。 アクションを介してpromiseを渡すことは、それをエクスポートするための優れた方法ですが、その後、何らかの方法でそれを取り戻す必要があります。 うーん。

@wmertensの最後のポイントへの答えを本当に楽しみにしています。
複数の同時呼び出しを回避する（何かが保留中の場合は何もしない）ことは頻繁なユースケースであり、それに答える最善の方法がわかりません（actionCreatorからストアの状態にアクセスできないため）。

actionCreatorユーザー（コンポーネント）は、アクションをディスパッチできるかどうかを状態で毎回確認する必要がありますか？ 毎回それをしなければなりません..多分あなたはこれを包むあなた自身の@connectアノテーションを導入する必要がありますか？

actionCreatorからストアの状態にアクセスできないため

どうして？ サンクミドルウェアを使用すれば、問題なく実行できます。

function doSomething() {
  return { type: 'SOMETHING' };
}

function maybeDoSomething() {
  return function (dispatch, getState) {
    if (getState().isFetching) {
      return;
    }

    dispatch(doSomething());
  };
}

store.dispatch(maybeDoSomething());

それはそれを解決します！
しばらくの間（理由もなく）actionCreatorで状態にアクセスするのは悪い習慣だと思っていました^^アクションクリエーターの呼び出し元は状態にアクセスできるので、actionCreatorがアクセスできない理由がわかりません。 :)

ありがとう@gaearon

@gaearonは、サンクと個別のアクションを使用するこの手法ですhttp://gaearon.github.io/redux/docs/api/applyMiddleware.html上記の回答よりも望ましいです：

このようなカスタムミドルウェアを作成することもできます

export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    next({ ...rest, readyState: 'request' );
    return promise.then(
      (result) => next({ ...rest, result, readyState: 'success' }),
      (error) => next({ ...rest, error, readyState: 'failure' })
    );
  };
}

デフォルトの代わりに使用します。
これにより、次のような非同期アクションクリエーターを作成できます。

function doSomethingAsync(userId) {
  return {
    type: SOMETHING,
    promise: requestSomething(userId),
    userId
  };
}

そしてそれらをに変えさせる

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, readyState: 'success' }
{ type: SOMETHING, userId: 2, readyState: 'failure' }

また、

私は最後の部分について、あなたが意味したと思います：

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, result, readyState: 'success' }
{ type: SOMETHING, userId: 2, error, readyState: 'failure' }

自動生成されたものを使用するのではなく、promiseのsuccessまたはfailureコールバックに対して個別のアクションを作成するかどうかに依存していると思います。

あなたのサンクの例では：

function makeASandwichWithSecretSauce(forPerson) {

  // Invert control!
  // Return a function that accepts `dispatch` so we can dispatch later.
  // Thunk middleware knows how to turn thunk async actions into actions.

  return function (dispatch) {
    return fetchSecretSauce().then(
      sauce => dispatch(makeASandwich(forPerson, sauce)),
      error => dispatch(apologize('The Sandwich Shop', forPerson, error))
    );
  };
}

その場合、ソースのフェッチにはさまざまな状況が発生する可能性があるため、シークレットソースのフェッチに失敗した場合に一般的なエラーコールバックを設定することは必ずしも意味がありません。

したがって、サンクモデルはもう少し柔軟であることがわかります。

おそらく、ロギングのようなもの、あるいは「非同期進行中ビジーインジケーター」の切り替えでさえ、ミドルウェアのより適切な例ですか？

@ justin808

どちらも大丈夫です。 冗長性が少ないものと、プロジェクトでうまく機能するものを選択してください。 私の提案は、サンクの使用から始めて、パターンが繰り返されている場合は、それをカスタムミドルウェアに抽出することです。 あなたもそれらを混ぜることができます。

トリガーされたアクションの状態（読み込み、成功、失敗）を他の状態から分離するためのActionStoreを作成しました。 しかし、これがRedux / Fluxの基礎に反するかどうかはわかりません。 私はこれについてstackoverflowに投稿しました。

@gabrielgiussi https://github.com/acdlite/redux-promiseも、州にPromiseを保存しなくても、必要なことを達成できると思います。 状態は常にシリアル化可能であると想定されています。

@wmertensアドバイスをありがとう。 リポジトリを確認しますが、なぜ私の状態をシリアル化できないのですか？ それとも私が注意するためだけにそれを言うのですか？

@gabrielgiussiあまりよく見ていませんでしたが、あなたがそうだったようです
約束や機能を店に置く。 いずれにせよ、そのプロジェクト
私もうまくいくはずだと思います。

月、2015年8月10日には、午前19時15 gabrielgiussi [email protected]は書きました：

@wmertenshttps ：//github.com/wmertensアドバイスをありがとう。 します
リポジトリを見てくださいが、なぜ私の状態はシリアル化できないのですか？ もしくは、あなた
私が注意するためだけにそれを言いますか？

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

うわー。
（モバイルで入力、簡潔さを言い訳）

実際、私がカスタムActionオブジェクトを配置したストアでは、それらは単純な属性（id、state、payload）とPromiseを作成して返すアクショントリガーを含むImmutable.Recordであるため、Promiseをストアに配置していません。 しかし、私はおそらくどこか別の場所で何かを壊しているでしょう、je。 @wmertensに感謝します。

@gabrielgiussi

そして、Promiseを作成して返すアクショントリガー

関数やシリアル化できないものを状態にしないでください。

ごめん。 私は言ってみました

Promiseを作成して返す関数トリガー

私が実際にストアに入れているのはActionオブジェクトです（名前は最高ではありませんでした）：

export default class Action extends Immutable.Record({state: 'idle', api: null, type: null, payload: null, id: null}){
load(){
  return this.set('state','loading');
}

succeed(){
  return this.set('state','succeeded');
}

fail(){
  return this.set('state','failed');
}

ended(){
  return this.get('state') != 'loading' && this.get('state') != 'idle';
}

endedWithSuccess(){
  return this.get('state') == 'succeeded';
}

endedWithFailure(){
  return this.get('state') == 'failed';
}

trigger() {
  return (dispatch) => {
    dispatch({type: this.get('type') + '_START', action: this});
    let payload = this.get('payload');
    this.get('api').call({dispatch,payload}).then((result) => {
      dispatch({type: this.get('type') + '_SUCCESS',id: this.get('id'), result: result.result});
    }).catch((result) => {
        dispatch({type: this.get('type') + '_FAIL',id: this.get('id'), result: result.result});
      });
  }
}
}

この問題を解決するためのライブラリを作成しました（＃539を参照）。これは、保留中のアクションに対してミドルウェアが約束を返すようにし、それらすべての約束が解決されるのを待つことで機能します。

@gaearonあなたが書いたこのコードhttps://github.com/rackt/redux/issues/99#issuecomment-112212639 、

これはreduxライブラリに含まれているものですか、それとも手動で作成する必要があるものですか？ これが新しい質問である場合は申し訳ありませんが、React / Flux（Redux）に入るだけです。 このチュートリアルを始めたばかりhttps://github.com/happypoulp/redux-tutorial

@ banderson5144

含まれていません。 何ができるかを知るためだけにありますが、別の方法で自由に行うことができます。
同様のものがhttps://github.com/pburtchaell/redux-promise-middlewareとして公開されました

この有用な情報をありがとう。 私は店をリセットすることについてあなたの頭脳を選びたかった-

• 新しいユーザーのストア状態をリセットします
• ユーザーにストアとHTMLを提供する前に、いくつかの非同期アクションが完了するのを待ちます
• 以前に実行していた別のユーザーの非同期アクションが完了し、ストアが汚染されます

どうやってそれを解決したのですか/どのようにアイデアがありますか？ 代わりに、ユーザーごとに新しいストアが機能しますか？

サーバーレンダリングについて話しているのですか？ リクエストごとに新しいストアを作成します。 ドキュメントにサーバーレンダリングのガイドがあります。

ありがとう私はそれをします

理解しようとした後…

• https://github.com/ForbesLindesay/redux-wait
• https://github.com/erikras/react-redux-universal-hot-example/

これはナイーブすぎますか？ （他の誰もこれをしていないようです—私は思います）

// server.js
app.use(function (req, res) {
    match({…}, function (error, redirectLocation, renderProps) {
        …

        if (renderProps) {
            const store = configureStore();

            const promises = renderProps.components.map(function (component, index) {
                if (typeof component.fetchData !== 'function') {
                    return false;
                }

                return component.fetchData(store.dispatch);
            });

            Promise.all(promises).then(function () {
                res.status(200).send(getMarkup(store, renderProps));
            });
        }
    })
});

// home.js
export class Home extends Component {
    static fetchData() {
        return Promise.all([
            dispatch(asyncAction);
        ]);
    },

    componentDidMount() {
        const { dispatch } = this.props;

        Home.fetchData(dispatch);
    }
}

export default connect()(Home);

// action.js
export function asyncAction() {
    return (dispatch, getState) => {
        dispatch(request);

        return fetch(…)
            .then(response => response.json())
            .then(data => dispatch(requestSuccess(data)))
        ;
    }
}

また、 @ mattybowの質問https://github.com/rackt/redux/issues/99#issuecomment -112980776（データフェッチを管理するネストされたコンポーネント）の解決策を見つけようとしていましたが、そのような成功はありませんでした（そうではありませんでした）。 componentWillMountからプロミスを収集する方法を確認してください）。

@chemoish私はまた、reactとreduxを使用してサーバー側のレンダリングに頭を

あなたのソリューションはそれを達成するのに非常に良さそうです。 これはあなたのためにうまくいきましたか？ ありがとう

編集：「componentDidMount」がサーバーでレンダリングされたときにクライアントで再度トリガーされないのは正しいですか？

@ ms88privat私はまだソリューションについて多くのフィードバックを得ておらず、その限界をテストしていません。

ただし、上記のソリューションでは、各ページがそのすべての子コンポーネントのデータを知っている必要があります。 ネストされたコンポーネントがデータ管理自体について心配することについては、深く掘り下げていません（ネストされたpromiseを収集するため）。

それはあなたが期待することをしているように見えるので、今のところ私にとっては十分です。

componentDidMountが再度トリガーされます（https://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmountを参照）。 ニーズに合ったこの方法または別のライフサイクル方法を使用できます。

これを回避するには、ストアがすでにいっぱいになっている場合（または適切と思われるビジネスロジック）にfetchコードが実行されないようにします。

私が話していることのアイデアについては、 https：//github.com/reactjs/redux/blob/master/examples/async/actions/index.js#L47を調べて

@chemoish

ストアがすでにいっぱいの場合にフェッチコードが実行されないようにすることで、これを回避します

わかりました、わかりました。 ありがとう。

ただし、上記のソリューションでは、各ページがそのすべての子コンポーネントのデータを知っている必要があります。

たぶん私はあなたのソリューションを読み間違えましたが、これはサーバー側のレンダリングに関係なく必要な要件ではありませんか？ （たとえば、SPAであっても、現在のルートで更新すると、同じ状態になるはずです）

それは可能ですが、何らかの理由で、ネストされたコンポーネントが独自のデータフェッチを管理する必要がある場合があります。

たとえば、多くのページで繰り返されるコンポーネントですが、各ページにはデータフェッチの必要性があまりありません。

@chemoish同じページにいるかどうかはわかりません。 私の見解を説明しようと思います。

たとえば、3つのネストされたコンポーネントを取得しました。

• component1（static dataFetch1）
  
  
  
  • component2（static dataFetch2）
  
  
  • component3（static dataFetch3）
  
  

それぞれに独自の「componentDidMount」メソッドがあり、独自のdataFetching宣言（静的なdataFetchingメソッドを介してアクションをディスパッチします）があります。

サーバー側のレンダリングがなく、現在のURLを更新すると、コンポーネントがマウントされ、必要なすべてのデータを後でロードするために必要なすべてのアクションがトリガーされます。

サーバーサイドレンダリングでは、 match関数とrenderPropsが3つのコンポーネントすべてを抽出するため、すべての静的dataFetchingメソッドにアクセスできます。これにより、に必要なすべてのデータをフェッチできます。最初のサーバー側のレンダリング？

提供された例からmatch functionへの参照がありますか？ THX。

@ ms88privat renderProps.componentsはルーターコンポーネントの配列であり、それ以上深くはなりません。 @chemoishは、彼の実装では、より深いコンポーネントでのデータフェッチのニーズを説明できないことを意味しました。

@DominicTobias thx、この問題の解決策はありますか？ ネストされたすべてのコンポーネントを取得する可能性はありますか？

おそらくこれは役立つでしょうか？ https://github.com/gaearon/react-side-effect
ネストされた要素からすべてのメタタグを収集するために使用されます： https ：

この議論に再びぶつかって申し訳ありませんが、私は最近、非同期アクションで状態を事前入力するという同じ問題に遭遇しました。

@erikrasがボイラープレートプロジェクトをredux-async-connectに移動したことがわかります。 誰かが別の解決策を見つけたのだろうか？

@vtambourine私はhttps://github.com/markdalgleish/redialを見てきました

はい、私はそれを調べました。 しかし、データを確認する方法がわかりませんでした
コードをnに再初期化した後、フックされたフェッチは2回実行されません
クライアント。
Птでは、2016年3月18日。 夜09時54時、ショーン・マセソン[email protected]
書きました：

@vtambourinehttps ：//github.com/vtambourine私が見てきた
https://github.com/markdalgleish/redialこれは非常に役立ちます

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/reactjs/redux/issues/99#issuecomment -198517067

また、誰かがこの課題の安定した解決策を見つけたかどうかも知りたいです。 私は@erikrasの定型文が大好き@ vtambourineが述べたように、それは安定した長期的な解決策ではないように思われるredux-async-connectに移行しました： ＃81 redux-async-connectは死んでいますか？ 。

@vtambourine https://github.com/makeomatic/redux-connectで入手できるフォークがあり、手入れが行き届いています。 いくつかの変更を加えた同様のAPIがあります。興味がある場合は、チェックしてください。

@gaearonが述べたように、ミドルウェアを使用したreduxソリューションに関心のある人のために、この手法を実装し、コンポーネント自体がサーバー側で必要なデータを要求できるようにするサンプルプロジェクトがあります。

https://github.com/peter-mouland/react-lego-2016#redux -with-promise-middleware

このアプローチでアクションクリエーターをユニットテストする方法は？