Redux: API呼び出しを正しい場所に配置しようとしています

これはほぼ正しいですが、問題は_純粋なアクションクリエーターを呼び出して、何かが起こることを期待することはできない_ということです。 アクションクリエーターは、ディスパッチする必要があるものを指定する関数にすぎないことを忘れないでください。

// CounterActions
export function increment() {
  return { type: INCREMENT }
}


// Some other file
import { increment } from './CounterActions';
store.dispatch(increment()); <--- This will work assuming you have a reference to the Store
increment(); <---- THIS DOESN'T DO ANYTHING! You're just calling your function and ignoring result.


// SomeComponent
import { increment } from './CounterActions';

@connect(state => state.counter) // will inject store's dispatch into props
class SomeComponent {
  render() {
    return <OtherComponent {...bindActionCreators(CounterActions, this.props.dispatch)} />
  }
}


// OtherComponent
class OtherComponent {
  handleClick() {
    // this is correct:
    this.props.increment(); // <---- it was bound to dispatch in SomeComponent

    // THIS DOESN'T DO ANYTHING:
    CounterActions.increment(); // <---- it's just your functions as is! it's not bound to the Store.
  }
}

それでは、あなたの例を見てみましょう。 最初に明確にしておきたいのは、単一のアクションを同期的にディスパッチするだけで副作用がない場合は、非同期dispatch => {}フォームは必要ないということです（ loginErrorとloginRequest場合はtrue）

この：

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return dispatch => {
    dispatch({ error, type: LOGGED_FAILED });
  };
}

export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    // router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return dispatch => {
    dispatch({ user, type: LOGIN_ATTEMPT });
  };
}

次のように簡略化できます

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return { error, type: LOGGED_FAILED };
}

// You'll have a side effect here so (dispatch) => {} form is a good idea
export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    // router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return { user, type: LOGIN_ATTEMPT };
}

第二に、あなたのレデューサーは_副作用のない純粋関数_であるはずです。 レデューサーからAPIを呼び出そうとしないでください。

この：

const initialState = new Immutable.Map({
  email: '',
  password: '',
  isLoggingIn: false,
  isLoggedIn: false,
  error: null
}).asMutable(); // <---------------------- why asMutable?

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      console.log(action.user);
      LoginApiCall.login(action.user); // <------------------------ no side effects in reducers! :-(
      return state;
    case LOGGED_FAILED:
      console.log('failed from reducer');
      return state;
    case LOGGED_SUCCESSFULLY:
      console.log('success', action);
      console.log('success from reducer');
      break;
    default:
      return state;
  }

おそらくもっと似ているはずです

const initialState = new Immutable.Map({
  email: '',
  password: '',
  isLoggingIn: false,
  isLoggedIn: false,
  error: null
});

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      return state.merge({
        isLoggingIn: true,
        isLoggedIn: false,
        email: action.email,
        password: action.password // Note you shouldn't store user's password in real apps
      });
    case LOGGED_FAILED:
      return state.merge({
        error: action.error,
        isLoggingIn: false,
        isLoggedIn: false
      });
    case LOGGED_SUCCESSFULLY:
      return state.merge({
        error: null,
        isLoggingIn: false,
        isLoggedIn: true
      });
      break;
    default:
      return state;
  }

最後に、ログインAPI呼び出しをどこに置きますか？

これはまさにdispatch => {}アクションクリエーターの目的です。 副作用！

それは単なる別のアクションクリエーターです。 他のアクションと組み合わせてください：

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return { error, type: LOGGED_FAILED };
}

export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return { user, type: LOGIN_ATTEMPT };
}

export function login(userData) {
  return dispatch =>
    fetch('http://localhost/login', {
      method: 'post',
      headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        email: userData.email,
        password: userData.password,
      }),
    })
    .then(response => {
      if (response.status >= 200 && response.status < 300) {
        console.log(response);
        dispatch(loginSuccess(response));
      } else {
        const error = new Error(response.statusText);
        error.response = response;
        dispatch(loginError(error));
        throw error;
      }
    })
    .catch(error => { console.log('request failed', error); });
}

コンポーネントで、

this.props.login(); // assuming it was bound with bindActionCreators before

// --or--

this.props.dispatch(login()); // assuming you only have dispatch from Connector

最後に、このような大規模なアクションクリエーターを頻繁に作成する場合は、promiseと互換性のある非同期呼び出し用のカスタムミドルウェアを作成することをお勧めします。

上記で説明した手法（ dispatch => {}署名を持つアクションクリエーター）は現在Reduxに含まれていますが、1.0ではredux-thunkと呼ばれる個別のパッケージとしてのみ利用可能になります。 あなたがそれをしている間、あなたはredux-promise-middlewareまたはredux-promiseをチェックしたほうがよいでしょう。

@gaearon ：clap：それは素晴らしい説明でした！ ;）それは間違いなくドキュメントに含まれるはずです。

@gaearon素晴らしい説明！ ：トロフィー：

@gaearonどのAPI呼び出しを呼び出すかを決定するためにロジックを実行する必要がある場合はどうなりますか？ 一箇所（レデューサー）にあるべきはドメインロジックではないですか？ それをActionクリエーターに維持することは、信頼できる唯一の情報源を壊すように私には聞こえます。 さらに、ほとんどの場合、アプリケーションの状態からの値によってAPI呼び出しをパラメーター化する必要があります。 おそらく、何らかの方法でロジックをテストすることもできます。 レデューサー（アトミックフラックス）でAPI呼び出しを行うことは、大規模プロジェクトで非常に役立ち、テスト可能であることがわかりました。

レデューサー（アトミックフラックス）でAPI呼び出しを行うことは、大規模プロジェクトで非常に役立ち、テスト可能であることがわかりました。

これは記録/再生を壊します。 副作用のある関数は、定義上、純粋関数よりもテストが困難です。 このようにReduxを使用できますが、その設計には完全に反しています。 :-)

それをActionクリエーターに維持することは、信頼できる唯一の情報源を壊すように私には聞こえます。

「信頼できる唯一の情報源」とは、データが1つの場所に存在し、独立したコピーがないことを意味し

どのAPI呼び出しを呼び出すかを決定するために何らかのロジックを実行する必要がある場合はどうなりますか？ 一箇所（レデューサー）にあるべきはドメインロジックではないですか？

レデューサーは、アクションによって状態がどのように変換されるかを指定します。 これらのアクションがどこから発生するかについて心配する必要はありません。 それらは、コンポーネント、アクションクリエーター、記録されたシリアル化されたセッションなどから発生する可能性があります。これは、アクションを使用するという概念の美しさです。

API呼び出し（または呼び出されるAPIを決定するロジック）は、レデューサーの前に行われます。 これが、Reduxがミドルウェアをサポートしている理由です。 上記のサンクミドルウェアを使用すると、条件を使用したり、状態から読み取ることもできます。

// Simple pure action creator
function loginFailure(error) {
  return { type: LOGIN_FAILURE, error };
}

// Another simple pure action creator
function loginSuccess(userId) {
  return { type: LOGIN_SUCCESS, userId };
}

// Another simple pure action creator
function logout() {
  return { type: LOGOUT };  
}


// Side effect: uses thunk middleware
function login() {
  return dispatch => {
    MyAwesomeAPI.performLogin().then(
      json => dispatch(loginSuccess(json.userId)),
      error => dispatch(loginFailure(error))
    )
  };
}


// Side effect *and* reads state
function toggleLoginState() {
  return (dispatch, getState) => {
    const { isLoggedIn } = getState().loginState;
    if (isLoggedIn) {
      dispatch(login());
    } else {
      dispatch(logout());
    }
  };
}

// Component
this.props.toggleLoginState(); // Doesn't care how it happens

アクションクリエーターとミドルウェアは、副作用を実行し、相互に補完するように_設計_されています。
レデューサーは単なるステートマシンであり、非同期とは何の関係もありません。

レデューサーは、アクションによって状態がどのように変換されるかを指定します。

これは確かに非常に有効なポイントです、ありがとう。

このバージョンがドキュメントに掲載されるまで、後世のために再開します。

：+1：

レデューサーはステートマシンですが、アクションクリエーターは一般的に（ただし暗黙的に）そうです。

ユーザーが「送信」ボタンを2回クリックしたとします。 初めてHTTPリクエストをサーバー（アクションクリエーター内）に送信し、状態を「送信中」（レデューサー内）に変更します。 二度目はそれをしたくない。

現在のモデルでは、アクションの作成者は、現在の状態に応じてディスパッチするアクションを選択する必要があります。 現在「送信」していない場合は、HTTPリクエストを送信し、1つのアクションをディスパッチします。それ以外の場合は、何もしないか、別のアクション（警告など）をディスパッチします。

したがって、制御フローは事実上2つのステートマシンに分割され、そのうちの1つは暗黙的で、副作用に満ちています。

このFluxアプローチは、一般的なWebアプリのユースケースの大部分を非常にうまく処理していると思います。 ただし、複雑な制御ロジックがある場合は、問題が発生する可能性があります。 既存のすべての例には複雑な制御ロジックがないため、この問題はやや隠されています。

https://github.com/Day8/re-frameは、唯一のFSMとして機能する単一のイベントハンドラーを持つさまざまなアプローチの例です。

しかし、レデューサーには副作用があります。 したがって、このような場合に「再生」機能をどのように処理するかは興味深いです-https：//github.com/Day8/re-frame/issues/86で質問しました

一般的に、これは本当の問題だと思います。何度も何度も現れるのは当然のことです。 最終的にどのような解決策が現れるかを見るのは興味深いことです。

リフレームと副作用について投稿してください！

私の本では、まともなReduxWebアプリには3つの状態タイプがあります。

1）コンポーネントを表示します（this.stateに反応します）。 これは避けるべきですが、Reduxとは別にコンポーネントを再利用するだけで再利用できる動作を実装したい場合があります。

2）アプリの共有状態、つまりRedux.state。 これは、ビューレイヤーがユーザーにアプリを提示するために使用している状態であり、ビューコンポーネントはそれを使用して相互に「通信」します。 また、この状態は、ActionCreator、ミドルウェア、ビューの間で「通信」するために使用できます。これらの決定は、この状態に依存する可能性があるためです。 したがって、「共有」が重要です。 ただし、完全なアプリの状態である必要はありません。 または、すべてをこのタイプの状態として（アクションの観点から）実装することは非現実的だと思います。

3）他の副作用のある複雑なモジュール/ライブラリ/サービスによって保持されている状態。 vladarが説明しているシナリオを処理するためにこれらを記述します。 または、react-routerは別の例です。 独自の状態を持つブラックボックスとして扱うことも、react-router状態の一部をアプリ共有状態（Redux.state）に上げることもできます。 すべてのリクエストとそのタイミングを巧みに処理する複雑なHTTPモジュールを作成する場合、通常、Redux.stateのリクエストタイミングの詳細には関心がありません。 私はActionCreators / Middlewareからこのモジュールを使用するだけで、おそらくRedux.stateと一緒に使用して新しいRedux.stateを取得します。

リクエストのタイミングを示すビューコンポーネントを作成したい場合は、この状態をRedux.stateにする必要があります。

@vladar AC / MWが暗黙のステートマシンであるということですか？ それは、それ自体は状態を保持していませんが、それでもどこか別の場所に保持されている状態に依存しており、この状態が時間とともにどのように進化するかを制御ロジックを定義できるためですか？ 場合によっては、クロージャとして実装して独自の状態を保持し、明示的なステートマシンになる可能性があると思いますか？

あるいは、Redux.stateを「パブリック状態」と呼び、他の状態はプライベートと呼ぶこともできます。 私のアプリをどのように設計するかは、何をプライベート状態として、何をパブリック状態として保持するかを決定する行為です。 カプセル化の良い機会のように思えます。したがって、状態が互いにどのように影響するかが地獄にならない限り、状態を異なる場所に分割することは問題ないと思います。

@vladar

しかし、レデューサーには副作用があります。 そのような場合に彼らが「リプレイ」機能をどのように扱うかは興味深いです

簡単な再生を実現するには、コードを決定論的にする必要があります。 これは、Reduxが純粋なレデューサーを要求することによって達成することです。 事実上、Redux.stateはアプリを非決定論的（非同期）部分と決定論的部分に分割します。 ビューコンポーネントでクレイジーなことをしないと仮定して、Redux.stateの上で動作を再生できます。 決定論的コードを実現するための最初の重要な目標は、非同期コードを移動し、アクションログを介して同期コードに変換することです。 これは、Fluxアーキテクチャが一般的に行うことです。 しかし、一般的にそれは十分ではなく、他の副作用または変化するコードは依然として決定論的処理を壊す可能性があります。

副作用のあるレデューサーを使用して再生可能性を実現することは、非現実的に困難であるか、不可能でさえあるか、または多くのコーナーケースで部分的にしか機能せず、おそらくほとんど実用的な効果はありません。

タイムトラベルを簡単にするために、Reduxで行われるようにアクションを再生するのではなく（常に難しい）、アプリの状態のスナップショットを保存します。

タイムトラベルを簡単にするために、Reduxで行われるようにアクションを再生するのではなく（常に難しい）、アプリの状態のスナップショットを保存します。

Redux DevToolsは、スナップショットとアクションの両方を保存します。 アクションがない場合、レデューサーをホットリロードすることはできません。 これは、DevToolsが有効にするワークフローの最も強力な機能です。

タイムトラベルは、_ディスパッチされた（最終的な）生のアクションのレベルで発生する_ため、不純なアクション作成者には問題なく機能します。 これらはプレーンオブジェクトであるため、完全に決定論的です。 はい、API呼び出しを「ロールバック」することはできませんが、問題はありません。 それによって発行された生のアクションをロールバックできます。

それは、それ自体は状態を保持していませんが、それでもどこか別の場所に保持されている状態に依存しており、この状態が時間とともにどのように進化するかを制御ロジックを定義できるためですか？

ええ、それはまさに私が意味することです。 ただし、制御ロジックが重複する可能性もあります。 問題を示すためのいくつかのコード（上記の例からダブルサブミットクリック）。

function submit(data) {
  return (dispatch, getState) => {
    const { isSubmitting } = getState().isSubmitting;
    if (!isSubmitting) {
      dispatch(started(data));

      MyAPI.submit(data).then(
        json => dispatch(success(json)),
        error => dispatch(failure(error))
      )
    }
  }
}

function started(data) {
   return { type: SUBMIT_STARTED, data };
}

function success(result) {
  return { type: SUBMIT_SUCCESS, result };
}

function failure(error) {
  return { type: SUBMIT_FAILURE, error };
}

そして、「isSubmitting」状態を再度チェックするためのレデューサーがあります

const initialState = new Immutable.Map({
  isSubmitting: false,
  pendingData: null,
  error: null
});

export default function form(state = initialState, action) {
  switch (action.type) {
    case SUBMIT_STARTED:
      if (!state.isSubmitting) {
        return state.merge({
          isSubmitting: true,
          pendingData: action.data
        });
      } else {
        return state;
      }
  }
}

したがって、2つの場所で同じ論理チェックを行うことになります。 明らかに、この例での重複は最小限ですが、より複雑なシナリオでは、きれいにならない場合があります。

最後の例では、チェックはレデューサーの内部にあるべきではないと思います。 そうしないと、すぐに不整合に陥る可能性があります（たとえば、アクションは誤ってディスパッチされますが無視されますが、「成功」アクションもディスパッチされますが、予期せず、状態が正しくマージされない可能性があります）。

（それがあなたが言っていたポイントだった場合は申し訳ありません;-)

！isSubmittingは、SUBMIT_STARTEDアクションがディスパッチされたという事実ですでにエンコードされているため、gaeronに同意します。 アクションが何らかのロジックの結果である場合、そのロジックはレデューサーで複製されるべきではありません。 その場合、レデューサーの責任は、SUBMIT_STARTEDを受信したときに、他の誰かがそのSUBMIT_STARTEDを決定する責任を負っていたため、アクションペイロードで状態を考慮せず、更新することです。

単一の決定に責任を負う単一のものがあることを常に目指す必要があります。

その後、ReducerはSUBMIT_STARTEDファクトをさらに構築し、追加のロジックで拡張できますが、このロジックは異なる必要があります。 Fe：

case SUBMIT_STARTED:
  if (goodMood) loading...
  else nothing_happens

誰が何に対して責任を負うべきかを決めるのは難しい場合があると想像できます。 ActionCreator、ミドルウェア、スタンドアロンの複雑なモジュール、レデューサー？

レデューサーはホットリロードできるので、純粋に保ちながら、できるだけ多くの決定を下すことを目指します。 副作用/非同期の決定が必要な場合は、AC / MW / somewhere_elseに移動します。 また、コードの再利用に関するベストプラクティス、つまりレデューサーとミドルウェアがどのように進化するかにも依存します。

ACはstate.isSubmittingを直接変更できません。 したがって、そのロジックがそれに依存している場合、ACはstate.isSubmittingがそのロジックと同期することを保証する必要があります。 ACロジックがstate.isSubmittedを新しいデータでtrueに設定し、読み取りが戻った場合、そのように設定されていることを期待します。 他の論理によってこの前提を変える可能性があるべきではありません。 ACTIONは同期プリミティブ自体です。 基本的に、アクションはプロトコルを定義し、プロトコルは明確に定義されている必要があります。

しかし、私はあなたが何を言おうとしているのか知っていると思います。 Redux.stateは共有状態です。 共有状態は常に注意が必要です。 ACロジックでは予期しない方法で状態を変更するレデューサーでコードを書くのは簡単です。 したがって、いくつかの非常に複雑なシナリオでは、ACと減速機の間のロジックを同期させるのが難しい場合があると想像できます。 これにより、バグの追跡とデバッグが困難になる可能性があります。 このようなシナリオでは、ロジックをAC /ミドルウェアに集約し、ロジックがないかほとんどない明確に定義されたアクションに基づいてレデューサーを愚かに動作させることが常に可能であると私は信じています。

誰かがいつでも新しいレデューサーを追加して、古い依存ACを壊すことができます。 ACをRedux.stateに依存させる前に、よく考えておく必要があります。

ユーザー資格情報を使用してAPIリクエストによって返される認証トークンを必要とするアクションクリエーターがいます。 このトークンには時間制限があり、何かによって更新および管理する必要があります。 あなたが提案していることは、この状態がRedux.stateに属していないことを示しているようですか？

どこに行けばいいの？ 概念的には、不変の外部状態としてReduxストアのコンストラクターに渡されますか？

したがって、いくつかの非常に複雑なシナリオでは、ACと減速機の間のロジックを同期させるのが難しい場合があると想像できます。

うん。 それがショーストッパーだと言っているのではありませんが、一貫性がなくなる可能性があります。 ステートマシンのポイントは、イベントの出現順序に関係なく、イベントに反応し、一貫性を保つことです。

ACからのイベントの適切な順序に依存している場合は、状態エンジンの一部を暗黙的にACに移動し、それをレデューサーと結合するだけです。

たぶんそれは好みの問題かもしれませんが、ストア/レデューサーが常に一貫して動作し、どこかで一貫性を保つために外部のものに依存しないとき、私ははるかに気分が良くなります。

ACをRedux.stateに依存させる前に、よく考えておく必要があります。

複雑なケースでは（いくつかの副作用をレデューサー/イベントハンドラーに移動せずに）回避することはできないと思います。

「ホットリロードまたはリプレイ機能の削除」と「状態の1か所での管理」というトレードオフのようです。 後の場合、リフレーム提案のように実際のFSMまたはステートチャートを作成できます。前の場合は、現在Fluxにあるようなアドホックな制御ロジックです。

私はリフレームを（速すぎて）読みましたが、それはReduxと同じ種類のものですが、実装の詳細がいくつか異なります。 リフレームビューコンポーネントはオブザーバブルに基づいており、イベントはアクションです。リフレームは、クリエーターを使用せずにイベント（アクション）をオブジェクトとして直接ディスパッチします（ビューコンポーネントで構築されます）。イベントハンドラーは純粋で、Reduxと同じものです。レデューサー。

副作用の処理についてはあまり議論されていないか、見逃していましたが、ミドルウェアで処理されていると思います。 そして、主な違いがあります。 ミドルウェアはイベントハンドラー（レデューサー）をラップし、外部からそれらを使用して構成しますが、Reduxミドルウェアはレデューサーをラップしません。 言い換えれば、Re-frameは純粋なレデューサーに直接副作用をもたらし、Reduxはそれらを分離したままにします。

これは、リフレームイベントを記録して簡単に再生することができないことを意味します。

考えられる不整合について話していたとき、私は共有状態を根本原因と考え、リフレームにも同じリスクがあると思います。

違いは、ミドルウェアとレデューサーの結合にあります。 ミドルウェアがリフレームで終了すると、結果をイベントハンドラー（レデューサー）に直接渡します。この結果はイベント/アクションとして記録されないため、再生できません。 Reduxはアクションの形で代わりにフックを間に置くだけだと思います。したがって、タイピング（アクションの作成）が増え、おそらくそれを実行する余地が増える代わりに、Re-frameと同じ技術を技術的に達成できると思います。違う。

結局、ReduxがRe-frameとまったく同じアプローチを実装するのを妨げるものは何もありません。 レデューサーをパラメーターとして受け取る関数を作成し、その中で何らかの処理を行ってから、結果を使用してレデューサー関数を直接呼び出し、レデューサーミドルウェアなどと呼ぶことができます。 DevToolsを失い、カップリングを増やすことを犠牲にして、もう少し簡単にしたい場合です。

いくつかの単純化（アクションの量の減少）よりもリフレームアプローチに大きな利点があるかどうか、私はまだもっと考える必要があります。 私はそれをすぐに読んだと言ったので、私は自分が間違っていることを証明するためにオープンです。

実際、私は少し間違っていました。 違いは、ReduxとRe-frameの実装ではなく、実際には「副作用をどこに置くか」にあります。

イベントハンドラー（レデューサー）でこれを行い、アクションクリエーターが制御フローに影響を与えることを禁止する場合、技術的には違いはありません。Reduxでもfsm /ステートチャートを使用して、制御フローを1か所にまとめることができます。

しかし実際には、違いがあります。 @gaearonはそれを非常によく説明しました：Reduxはあなたのレデューサーが純粋であることを期待しています、さもなければリプレイ機能が壊れます。 したがって、Reduxの設計に反するため、これを行うことは想定されていません（レデューサーに副作用を入れます）。

リフレームでは、イベントハンドラーは純粋であるとも述べていますが、Readmeでも、HTTPリクエストはイベントハンドラーで開始されると述べています。 したがって、これは私には少し不明確ですが、彼らの期待は異なっているように見えます。副作用をイベントハンドラーに入れることができます。

次に、それらがリプレイにどのようにアプローチするかが興味深いです（そして、それは私がhttps://github.com/Day8/re-frame/issues/86で尋ねたものです）。

イベントハンドラーに副作用がある場合にそれを行う唯一の方法は、 @ tomkis1が述べたこと、

ホットリロードは、「過去の」イベントに影響を与えることができないことを除いて、引き続き機能します。時間内に状態の新しいブランチを生成するだけです。

ですから、デザインの違いは微妙かもしれませんが、私にとっては重要です。

副作用のあるミドルウェアで純粋なイベントハンドラーを作成することでHTTPリクエストを実行すると思います。 このコンポジションは、純粋ではなくなった新しいイベントハンドラーを返しますが、内部のイベントハンドラーは純粋なままです。 app-db（状態）の変更と副作用を組み合わせたイベントハンドラーを構築することを提案しているとは思いません。 コードをよりテストしやすくします。

イベントハンドラーの結果を記録する場合、ホットリロード可能にすることはできません。つまり、コードをその場で変更できます。 ミドルウェアの結果を記録する必要があり、それはReduxが行うこととまったく同じです-この結果をアクションとして記録し、それをレデューサーに渡します（それを聞きます）。

Re-frameミドルウェアはプロアクティブであり、Reduxは反応性を許可していると言えます（アドホックレデューサーはミドルウェア/ acの結果をリッスンできます）。 私が気づき始めていることの1つは、Fluxやミドルウェアで主に使用されているACはコントローラーと同じものであるということです。

私が理解したように、 @ tomkis1は、すべての単一の突然変異に対して実行された場合にパフォーマンスに影響を与える可能性があると想定しているため、おそらく指定された間隔で、状態を保存することでタイム

わかりました。レデューサー/イベントハンドラーが完全に新しい状態を返すことに気付いたので、同じことを言いました。

@merk週末はおそらくここに来ないので、おそらく月曜日にそれについての考えを書こうと思います。

リフレームドキュメントでは、イベントハンドラーでサーバーと通信することを推奨しています： https ：

つまり、これがReduxとは異なるところです。 そして、この違いは一見したところよりも深いものです。

うーん、Reduxとの違いがわかりません。

開始イベントハンドラーは、これらのHTTP要求の成功時ハンドラーまたは失敗時ハンドラー自体が単に新しいイベントをディスパッチするように編成する必要

イベントをアクションに置き換えます。 Reduxには、純粋なイベントハンドラーの特別な名前（レデューサー）があります。 何かが足りないか、今週末は脳が落ちていると思います。

イベントの実行方法（キューと非同期）のより大きな違いを嗅ぐことができます。 Reduxは、状態の一貫性を保証するために、アクションの同期とアクションごとのロックステップアクションを実行すると思います。 イベントを保存して何度も再生すると同じ終了状態になるかどうかわからないため、再生可能性にさらに影響を与える可能性があります。 アクションが常に純粋なコードをトリガーするReduxとは異なり、どのイベントが副作用をトリガーするかわからないため、それを実行できないことを無視します。

@vladap私が見ている違いを要約すると：

1.1。

• Reduxでは、アクションクリエーターでサーバーリクエストを開始します（この問題の元の質問に対する@gaearonの返信を参照してください）。 あなたのレデューサーは純粋でなければなりません
• リフレームでは、イベントハンドラー（リデューサー）で行います。 イベントハンドラー（削減者）には副作用がある可能性があります

2.2。

• 最初のケースでは、制御フローはACとレデューサーの間で分割されます。
• 2番目のケースでは、すべての制御フローが1つの場所（イベントハンドラー（リデューサー））にあります。

3.3。

• 制御フローが分割されている場合-ACとレデューサーの間の調整が必要です（暗黙的であっても）。ACはレデューサーによって生成された状態を読み取ります。 レデューサーは、ACからのイベントの適切な順序を想定しています。 技術的には、ACとレデューサーのカップリングを導入します。これは、レデューサーへの変更がACにも影響を与える可能性があるためです。
• 制御フローが1か所にある場合-追加の調整は必要ありません+イベントハンドラー/リデューサーでFSMやステートチャートなどのツールを使用できます
• 
  
  
  
  1. 純粋なレデューサーを適用し、副作用をACに移動するReduxの方法により、ホットリロードとリプレイが可能になります
  
  
• イベントハンドラー（レデューサー）で副作用を持つリフレーム方法は、Reduxで行われているように（レデューサーを再評価することによって）再生するための扉を閉じますが、他の（おそらくそれほど強力ではない）オプションはまだ可能です- @ tomkis1が述べたように

開発エクスペリエンスの違いについては、非同期のもの（タイマー、並列httpリクエスト、Webソケットなど）が多数ある場合にのみ表示されます。 同期のものについては、それはすべて同じです（ACには制御フローがないため）。

私の主張をより明確にするために、そのような複雑なシナリオの実例をいくつか準備する必要があると思います。

私はあなたを怒らせるかもしれません、それについては申し訳ありませんが、私たちは1つの基本的なことに同意しません。 たぶん私はリフレームのサンプルコードを読むべきです、私はいつかClojureを学びます。 たぶんあなたはそうしたので、あなたはもっと知っています。 あなたの努力に感謝します。

1.1。

Reduxでは、アクションクリエーターでサーバーリクエストを開始します（この問題の元の質問に対する@gaearonの返信を参照してください）。 あなたのレデューサーは純粋でなければなりません
リフレームでは、イベントハンドラー（リデューサー）で行います。 イベントハンドラー（削減者）には副作用がある可能性があります

私が太字にしたDocは、イベントハンドラーでwebapi呼び出しを開始し、成功したときにイベントをディスパッチする必要があることを明示的に示しています。 同じイベントハンドラーでこのディスパッチされたイベントを処理する方法がわかりません。 この成功したイベントはルーターにディスパッチされ（ディスパッチャーと同じだと思います）、それを処理するためにさらに別のイベントハンドラーが必要です。 この2番目のイベントハンドラーは純粋でReduxレデューサーと同等であり、最初のイベントハンドラーはActionCreatorと同等です。 私にとってそれは同じことであるか、私は明らかにいくつかの重要な洞察を逃しています。

開発エクスペリエンスの違いについては、非同期のもの（タイマー、並列httpリクエスト、Webソケットなど）が多数ある場合にのみ表示されます。 同期のものについては、それはすべて同じです（ACには制御フローがないため）。

私たちはこれに同意しません。 非同期のものは実際には問題ではありません。Reduxで再生することはできないため、ここでは開発経験がありません。 複雑な純粋なレデューサーが多数ある場合に違いが現れます。 Reduxでは、状態A、いくつかのアクションシーケンス、レデューサーを取得して再生し、状態Bを取得できます。すべてを同じに保ちますが、レデューサーにコードを変更してホットリロードし、状態Aから同じアクションシーケンスを再生します。状態Cを取得し、コード変更の影響をすぐに確認します。 @ tomkis1アプローチではそれを行うことはできません。

その上にテストシナリオを作成することもできます。 初期状態を保存し、アクションシーケンスを保存し、アクションシーケンスを状態Aに減らし、状態Bを取得してアサートします。 次に、同じ状態Bになると予想されるコードに変更を加え、テストシナリオを再生して、それが真であり、変更によってアプリが破損していないことを確認します。 私はそれが最良のテストアプローチであるとは言いませんが、それは可能です。

実際、Haskellersと同じように関数型プログラミングの熱心な実践者であると私が考えるClojuristsが、少なくともある程度の構成がなくても純粋なコードと副作用を混合することを推奨する場合、私は非常に驚きます。

遅延評価/反応性は、副作用のあるコードを純粋なコードから可能な限り移動するための基本的な手法です。 遅延評価は、Haskellが最終的に非実用的な関数型純度の概念を適用して、実用的な何かを実行するプログラムを取得する方法です。完全に純粋なプログラムでは多くのことができないためです。 モナド構成などを使用して、プログラム全体がデータフローとして作成され、パイプラインの最後のステップを純粋に保ち、コードで実際に副作用を呼び出さないようにするために、プログラムは何をすべきかについての説明を返します。 実行時に渡され、遅延実行されます。命令呼び出しによって実行がトリガーされることはありません。 少なくとも、鳥のレベルの観点から関数型プログラミングを理解する方法です。 ActionCreatorsと反応性でシミュレートするようなランタイムはありません。 免責事項、それを当然のことと思ってはいけません。FPについてあまり読んでいないことから、ここで何らかの権威であることが私が理解したことです。 オフになっているかもしれませんが、実際にはその点を理解したと思います。

同じイベントハンドラーでこのディスパッチされたイベントを処理する方法がわかりません。

私はそれを言っているのではありません。 「副作用」とは、イベントハンドラー（リデューサー）でHTTPリクエストを開始することを意味します。 IOの実行は、関数の戻りに影響を与えない場合でも、副作用です。 成功/エラーハンドラーで状態を直接変更するという意味での「副作用」を意味するのではありません。

この2番目のイベントハンドラーは純粋でReduxレデューサーと同等であり、最初のイベントハンドラーはActionCreatorと同等です。

最初のものはアクションクリエーターに相当するとは思いません。 それ以外の場合、なぜこれを行うためにアクションクリエーターが必要なのですか？ レデューサーでも同じことができるとしたら？

@ tomkis1アプローチではそれを行うことはできません。

同意します。 そして、それは私が「他の（おそらくそれほど強力ではない）オプション」を書いたときに私が意味したことです。

最初のものはアクションクリエーターに相当するとは思いません。 それ以外の場合、なぜこれを行うためにアクションクリエーターが必要なのですか？ レデューサーでも同じことができるとしたら？

ActionCreatorsは、純粋なアプリ（再生可能）から副作用を分離するために使用されます。 Reduxは設計されているため、レデューサーで副作用を実行することはできません（実行すべきではありません）。 副作用のあるコードを配置できる別の構成が必要です。 Reduxでは、これらの構成はACまたはミドルウェアです。 リフレームで見られる唯一の違いは、ミドルウェアの機能と、ハンドラーがトリガーされる前にイベント（アクション）を変換するミドルウェアがリフレームにないことです。

AC /ミドルウェアの代わりに、実際には何でも使用できます-utilモジュール、サービス（Angularサービスなど）、ACまたはミドルウェアのいずれかでインターフェースし、そのAPIをアクションに変換する別個のlibとしてビルドできます。 ACは、このコードを配置するのに適切な場所ではありません。ACは、引数からアクションオブジェクトを構築する単純な作成者/ファクトリである必要があります。 私が純粋主義者になりたいのであれば、副作用のあるコードをミドルウェアに厳密に配置する方がよいでしょう。 ActionCreatorは、ある種のコントローラーの責任を表す悪い用語です。 ただし、このコードが1ライナーのwebapi呼び出しである場合は、単にAC内に配置する傾向があり、単純なアプリの場合は問題ありません。

AC、ミドルウェア、サードパーティのライブラリは、私がサービスレイヤーと呼ぶのが好きなレイヤーを形成します。 元のFacebookWebApiUtilsは、react-routerを使用してその変更をリッスンし、それらをアクションに変換してRedux.stateを更新する場合と同じように、このレイヤーの一部になります。Relayはサービスレイヤーとして使用できます（アプリ/ビューにReduxを使用するよりも）状態）。 ほとんどのサードパーティライブラリは現在プログラムされているため、リプレイではうまく機能しません。 明らかに、すべてを最初から書き直したくないので、そうします。 私がそれについて考えるのが好きなのは、これらのライブラリ、サービス、ユーティリティなどがブラウザ環境を拡張して、再生可能なアプリを構築できるプラットフォームを形成することです。 このプラットフォームは副作用でいっぱいです、実際にそれは私が意図的に副作用を移動する場所です。 このプラットフォームAPIをアクションに変換し、アプリはこれらのアクションオブジェクトをリッスンすることで間接的にこのプラットフォームに接続します（上記の投稿で説明しようとしたHaskellアプローチをシミュレートしようとします）。 これは関数型プログラミングの一種のハックであり、純粋さを達成する方法（おそらく絶対的な学術的意味ではない）が副作用を引き起こす方法です。

私を混乱させる別のことがありますが、私はあなたを誤解する可能性があります。 複雑なロジックの場合、すべてを1か所にまとめることが有益だとおっしゃっていたと思います。 まったく逆だと思います。

このアクションビジネス全体は、概念的にはDOMイベントと似ています。 私は自分のビジネスコードを、feブラウザがmousemoveイベントを検出する方法のコードと混ぜたくありません。あなたもそうしないと確信しています。 幸いなことに、これらの責任は十分に分離されているため、私はaddListener（ 'mousemove'、...）の上で作業することに慣れています。 重要なのは、私のビジネスロジックについてもこのような関心の分離を実現することです。 ActionCreators、ミドルウェアはそのためのツールです。

私のビジネスニーズにうまく対応していない廃止されたwebapiに対してアプリを作成することを想像してみてください。 必要なデータを取得するには、いくつかのエンドポイントを呼び出す必要があります。それらの結果を使用して次の呼び出しを作成し、すべての結果をRedux.stateで使用する正規の形式にマージします。 このロジックはレデューサーに漏れないので、レデューサーのデータを何度も変換する必要はありません。 それはミドルウェアになります。 効果的には、厄介な廃止されたAPIを分離し、素敵なAPIに対して作成されるようにビジネスアプリを開発します。 完了したら、webapiを再構築するための変更を取得してから、ミドルウェアを書き直すだけかもしれません。

したがって、すべてを1つの場所にまとめることは、簡単なアプリにとっては簡単に思えます。 しかし、複雑なこととはまったく逆に、関心の分離が有益であることがわかります。 しかし、おそらく私はあなたが言及しているあなたのポイントやユースケースを理解していません。

実際、おそらく私は、データ変換の多くを正規の形式からレデューサーに移動し、代わりにレデューサー構成を使用します。これにより、一般的に純粋なこのコードの再生とテストが可能になります。

同じイベントハンドラーでこのディスパッチされたイベントを処理する方法がわかりません。
私はそれを言っているのではありません。

webapi呼び出しとレデューサーロジックを組み合わせて1か所にまとめたいと思いました。 彼らが成功したときにイベントをディスパッチすることを提案しているので、あなたがリフレームでそれをしないと私が言っていること。

webapi->多くのロジック-> webapi->多くのロジック-> ...->レデューサーの結果、チェーン全体がシングルクリックでトリガーされる場合があります。 そのような場合、ロジックのほとんどはおそらくACにあり、すべての副作用が終了するまでそれを分割しません。 これはあなたが言及しているものですか？

ここで私ができる最善のことは、テスト容易性のためにできるだけ多くのロジックを純粋関数に移動することですが、それらはACスコープで呼び出されます。

間接的に接続された一連のイベントハンドラーとしてそれを行う可能性は好きではないと思います。 それは約束または観察可能なチェーンになります。

より経験豊富なReduxersは、その考えについて異なる意見を持つ可能性があります（ @ gaearon 、 @ johanneslumpe 、 @ acdlite 、 @ emmenko ...）

@vladapこの会話は、この問題の主題から離れすぎていると思います。 あなたはすでにここで私のコメントの要点に言及しました：

したがって、いくつかの非常に複雑なシナリオでは、ACと減速機の間のロジックを同期させるのが難しい場合があると想像できます。

簡単な例：

状況1：ページのどこかにトップ10のブログ作成者のリストがあります。 これで、ブログの投稿のカテゴリが削除されました。 削除が成功したら、サーバーからこの作成者のリストを更新して最新の状態にする必要があります。

状況2：別のページにいます。 著者のリストはありませんが、トップ10のコメントのリストはあります。 ブログ投稿の一部のカテゴリを削除することもでき、削除が成功した場合はコメントのリストを更新する必要があります。

では、状態エンジンのレベルでこれをどのように処理するのでしょうか。 （Reactフックを使用して支援することもできますが、良好な状態のエンジンはそれ自体で一貫性を保つことができるはずです）

オプション：
A）このロジックをACに配置します。 次に、ACはCategoryApi （削除する）に触れ、 userList状態とcommentList状態（現在状態にあるリストを確認する）から読み取り、 UserListApi話しかけます。 CommentListApi （リストを更新するため）+ディスパッチTOP_AUTHORS_UPDATEDおよび/またはTOP_COMMENTS_UPDATED 。 したがって、基本的に3つの異なるドメインにアクセスします。

B）イベントハンドラーuserListとcommentListます。 これらのハンドラーは両方ともDELETE_CATEGORY_SUCCESSイベントをリッスンし、次にAPIサービスを呼び出し、次にTOP_AUTHORS_UPDATED / TOP_COMMENTS_UPDATEDイベントをディスパッチします。 したがって、各ハンドラーは、それ自体のドメインのサービス/状態にのみアクセスします。

この例はおそらく単純すぎますが、このレベルでも、ACでのAPI呼び出しでは状況が悪くなります。

違いは、リフレームのイベントハンドラーとは異なり、ActionCreatorsはビジネスロジックの処理に積極的であるという事実に由来します。 また、DOMイベントに基づいて実行できるACは1つだけです。 ただし、このトップレベルACは他のACを呼び出すことができます。 ドメインをより適切に分離するために、UserListApiとCommentListApiに別々のACを設定できますが、それらを配線するAC（コントローラーのようなもの）が常に存在する必要があります。 この部分は非常に古典的な命令型コードですが、リフレームは完全にイベントベースです。 少しの作業で、優先アプローチ、イベントベース、オブザーバブル、cpsなどに置き換えることができます。

@vladap別のアプローチが実行可能かどうかを確認するのは興味深いことです。レデューサーに副作用がある場合がありますが、リプレイで無視できるようにそれらを分離することもできます。

レデューサーの署名が次のように変更されるとします。 (state, action) => (state, sideEffects?)ここで、sideEffectsはクロージャです。 次に、コンテキストフレームワークに応じて、これらのsideEffectsを評価するか、無視することができます（再生の場合）。

次に、元の問題の説明の例は次のようになります。

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      return [state, () => {LoginApiCall.login(action.user)}];
    case LOGGED_FAILED:
      // do something
      return state;
    case LOGGED_SUCCESSFULLY:
      // do something else
     return state;
    default:
      return state;
  }
}

（他のすべてはほとんど同じままです）

少なくとも制御フローは1つの場所にあり、副作用は常に単純です（非同期ハンドラーで別のアクション/イベントを作成するだけで、ロジックはレデューサーにとどまるため、より多くのコードが再生されます）。

通常のFSMまたはステートチャートのようなコード（レデューサー/イベントハンドラーの構成を含む）を作成することもできます。

また、アクションクリエーターで事前定義された署名を使用してクロージャを返す必要はありません。

このアプローチがどのような問題を引き起こす可能性があるかはわかりませんが、私にとっては試してみる価値があります。

レデューサーの署名が次のように変わると言います：（state、action）=>（state、sideEffects？）ここで、sideEffectsはクロージャーです。 次に、コンテキストフレームワークに応じて、これらのsideEffectsを評価するか、無視することができます（再生の場合）。

これは実際、Elmが(State, Action) => (State, Request?)行っているのを聞いたのと似ています。 私はまだ例を見ていませんが、誰かがこれを探求したいなら、遠慮なくしてください。

おそらくいくつかのインスピレーションを得るためのさらに別のアプローチは、アクターモデルの上にイベントソーシングを実装することです-Akka Persistance 、 PersistentFSM 。 私はそれが良いとは言いませんが、他の試みを知ることは悪くありません。 アクターは副作用を使用できますが、私が正しく覚えていれば、再生方法を明示的にコードで記述する必要がある場合があります。

たぶん、再生機能は、コードが属する場所の決定を歪めている可能性があります。 「これを再生できるようにしたいので、レデューサーに行かなければならない」と考え始めているようです。 責任/役割によってコードをスライスしておらず、ビジネスロジックを人為的にスライスして再生可能にする傾向があるため、境界が不明確なコードにつながる可能性があります。

リプレイ機能を脇に置いて、ビジネスコードを作成する方法を教えてください。 私は自分のビジネスロジックをアクションログの前に置き、それを1か所に置くことを目指しています。 ビジネスロジックステートマシン、または私が使用するものはすべて、すべての難しい複雑な決定を行い、FACTS（アクション）のストリームがすでに解決されています。 レデューサーは一般的に単純なアップデーターであり、その主な責任はアクションペイロードをRedux.stateに適用する方法です。 それらにはいくつかのロジックがありますが、ある意味では、ファクトを異なる方法で解釈して、ファクト（アクション）ストリームに関する別の種類のビューを取得し、ユーザーに提示します。

責任を分断するために、私もこのように考えるのが好きです。 サーバーに再実装するように要求される可能性のあるコードは何ですか？ Feは、計算コストの高いビジネスロジック、おそらくセキュリティ上の理由、インテリジェンスプロパティを隠して、低速デバイスをより適切にサポートします。 ビューレイヤーにバインドされているため、ロジックをレデューサーからサーバーに簡単に移動することはできません。 複雑なビジネスロジックがアクションログの前に記述されている場合は、同じアクションストリームに変換するREST呼び出しに置き換えることができ、ビューレイヤーは（おそらく）機能するはずです。

欠点は、Akka Persistanceとは異なり、このコードを再生する方法がないことです。

いつかエルムをもっと深く見て、あなたの提案がどのように機能するかを理解する必要があります。

@gaearonElmに言及してくれてありがとう。 この会話（ https://gist.github.com/evancz/44c90ac34f46c63a27ae ）を同様のアイデアで見つけました（ただし、はるかに高度です）。

タスク（http、dbなど）とエフェクト（タスクのキューのみ）の概念を紹介します。 したがって、「レデューサー」は実際に新しい状態と効果を返すことができます。

それについてのクールなこと（そして私はそれについてこのように考えていませんでした）-レデューサーをチェーンしながらタスクを収集できれば-そして後でこのリストにいくつかの関数を適用することができます。 httpリクエストをバッチ処理したり、DBクエリをトランザクションでラップしたりできるとします。

または、エフェクトのほんの一部である「リプレイマネージャー」と言うこともできます。

@merkほとんどはすでに書かれていると思います。 この種の自律的な副作用コードはおそらく最もトリッキーです。 タイムトラベルが同じコードで実行されており、インターバルもリプレイモードで開始されると仮定すると、インターバルはタイムトラベルと同期されないため、リプレイで大混乱を引き起こす可能性があります。

通常のアプリケーションでは、トークンと有効期限のカウントダウンをユーザーに提示する必要がないため、技術的にはRedux.stateにある必要はありません。 管理アプリはそれを持っている必要があるかもしれません。 したがって、自分に合った方法で両方の方法で実装できます。

1つのオプションは、ログインACで有効期限のカウントダウンを開始することです。これは、無限に実行され、アプリで停止するか、ログオフでクリーンアップする必要があると思います。 間隔がトリガーされると、トークンの確認に必要な処理が実行され、期限切れになるとLOGIN_EXPIREDアクションがディスパッチされ、リスニングレデューサーがユーザーセッションをクリアして場所を変更します。これにより、ルーターが/ loginに移行します。

もう1つは、サードパーティのlibを使用して懸念事項を委任し、そのAPIをLOGIN_EXPIREDアクションに変換することです。 または、独自に記述して、ビューレイヤーでトークンとカウントダウンの状態が不要な場合は、ここに保持します。

Redux.stateに保持できますが、この状態は不安定です。 状態が大きいと、グローバル変数を使用したプログラミングと同じ問題が発生する可能性があります。 そして、それをテストすることは難しい、おそらく不可能です。 レデューサーをテストするのは簡単ですが、状態オブジェクトの特定のキーを更新しているレデューサーが1つだけの場合に機能することが証明されます。 これは、さまざまな品質の開発者が多数いる大規模なプロジェクトでは悪化する可能性があります。 誰でもレデューサーを作成することを決定でき、状態の一部を更新するのが適切であると考えることができます。すべての可能な更新シーケンスですべてのレデューサーを一緒にテストする方法を想像することはできません。

ユースケースによっては、この状態を保護することが理にかなっている場合があります。これはログインであるためです。これは非常に重要な機能であり、分離する必要があります。 この状態がビューレイヤーで必要な場合は、react-routerの場所の状態がいくつかの例でRedux.stateに複製されるのと同様の方法で、Redux.stateに複製します。 州とチームが小さく、行儀が良い場合は、1か所にまとめても問題ありません。

@vladar @vladap

うわー、そのエルムの要点はすごいクールです！ また、 Cycle.jsの「ドライバー」アーキテクチャーを思い出させます。

@merk実際、自律ログイン_EXPIREDは、アクションログの最後に取得され、リプレイによってすぐに処理されず、アクションログにまったく到達しないため、リプレイにはあまり影響しません-わかりませんリプレイがどの程度正確に実装されているか。

@gaeron高レベルでは、Elm and Cycleは、正しく理解していれば、説明しようとしていたパターンを実装しているようです。 基本プラットフォームを提供するブラウザーがあります。このプラットフォームをサービスレイヤー（http、db ...）で拡張して、アプリのプラットフォームを構築します。 次に、サービスレイヤーと相互作用し、純粋なアプリがサービスレイヤーと間接的に通信できるようにする、ある種の接着剤が必要です。これにより、アプリは実行したいことを記述できますが、実際には実行されません（Cycleドライバーに送信されるメッセージ、Elm Effectsタスクのリストを持っている）。 私のアプリはデータ構造を使用して「プログラム」を構築していると言えます（データマントラとしてのコードを思い出させます）。これは実行のためにサービスレイヤーに渡され、アプリはこの「プログラム」の結果にのみ関心があり、それが適用されます。その状態に。

@merk ：さらに。 トークンとその有効期限がRedux.state /または他のjsサービスのどこかに配置される場合、ユーザーが新しいタブでアプリを開いたときにトークンは転送されません。 ユーザーは、ログに記録されたままになることを期待していると思います。 したがって、この状態は実際にはSessionStoreにあるはずだと思います。

それがなくても、トークンの有効期限がユーザー情報の即時クリーンアップと/ loginへの移行を意味しない場合、状態が分離される可能性があります。 ユーザーがインタラクションでサーバーに触れないまで（十分なデータがキャッシュされている）、ユーザーは作業を続行でき、サーバーを必要とする何かを実行した場合にのみLOGIN_EXPIREDアクションがトリガーされます。 Redux.stateに基づくisLogged状態は、有効なトークンが存在することを意味する必要はありません。 Redux.stateのisLogged状態は、レンダリングする対象を決定するために使用されます。トークンの周囲の状態は、ビューレイヤーに非表示にして、ビューレイヤーに影響を与えるものを除いて、アクションやリデューサーを記述せずに、アクション作成者レベルでのみ維持できます。

@vladar私はあなたの一般的なポイントを得るかもしれないと思います。 今まで気づかなかったと思います。

レデューサーからアクションクリエーターに制御を戻し、いくつかの値を渡す方法は簡単ではありません。 これらの値はレンダリングに必要ではなく、一時的なものでさえありますが、非同期操作を開始するために必要であると仮定しましょう。

actionCreator() {
  ... getState
  ... some logic L1
  ... dispatch({ACTION1})
}

reducer() {
  case ACTION1
    ... some logic L2
    ... x, y result from L2
    ... some logic L3
    ... resulting in new state
    ... return new state
}

レデューサーで計算されたx、yを使用して非同期操作を開始する方法には3つのオプションがあります。 それらのどれも完璧ではありません。

1）ロジックをレデューサーからアクションクリエーターに移動し、ホットリロードのパワーを減らします。 レデューサーはダム状態アップデーターであるか、ロジックL3以降を備えています。

2）x、yをRedux.stateに保存し、一時的/一時的な値で汚染し、基本的に、私が好きだと確信していないレデューサーとアクション作成者の間のグローバル通信チャネルとして使用します。 実際の状態であれば問題ないと思いますが、このような値では問題ありません。 アクション作成者は次のように変更されます。

actionCreator() {
  ... getState
  ... some logic L1
  ... dispatch({ACTION1})
  // I assume I get updated state if previous dispatch is sync.
  // If previous dispatch is async it has to be chained properly.
  // If updated state can't be received here after a dispatch
  // then I would think there is a flaw.
  ... getState
  ... asyncOperation(state.x, state.y)
}

3）x、yを状態に保存し、それを一部のコンポーネントの小道具として使用し、componentWillReceivePropsを使用してビューレイヤーループ全体にトンネリングして、新しいアクションクリエーターと非同期操作をトリガーします。 私に言わせれば最悪の選択肢であり、ビジネスロジックをいたるところに広げます。

@vladar
一般に、この操作の結果がアクションとしてパックされ、ディスパッチされ、レデューサーによって適用される限り、非同期が開始される場所は重要ではありません。 それは同じように動作します。 アクションクリエーターまたはストアで非同期を開始する必要があるかどうかは、バニラフラックスの場合と同じです。

Reduxが再生時にこれらの非同期呼び出しを識別して無視できる必要があります。これはまさにあなたが提案していることです。

レデューサーからアクションクリエーターに制御を戻し、いくつかの値を渡す方法は簡単ではありません。

これが症状の一つだと思います。 2番目の例は、私の視点を非常によく示しています（以下を参照）。

（FSMの世界での）状態遷移の一般化されたフローを検討してください。

1. イベントが到着します
2. 与えられた現在の状態FSMは新しいターゲット状態を計算します
3. FSMは、現在の状態から新しい状態に移行するための操作を実行します

現在の状態が重要であることに注意してください！ 同じイベントが、現在の状態に応じて異なる結果につながる可能性があります。 そして、その結果、ステップ3での操作（または引数）のシーケンスが異なります。

つまり、これは、アクションが同期しているときにFluxの状態遷移がどのように機能するかとほぼ同じです。 あなたのレデューサー/ストアは確かにFSMです。

しかし、非同期アクションはどうですか？ 非同期アクションを使用したFluxの例のほとんどは、反転していると思わせるものです。

1. ACは非同期操作を実行します（現在の状態に関係なく）
2. この操作の結果として、ACはアクションをディスパッチします
3. レデューサー/ストアがそれを処理し、状態を変更します

したがって、現在の状態は無視され、ターゲットの状態は常に同じであると見なされます。 実際には、一貫した状態遷移フローは同じです。 そしてそれはこのように見える必要があります（ACを使用）：

1. ACは、アクションがディスパッチされる前に現在の状態を取得します
2. ACはアクションをディスパッチします
3. ACはアクション後に新しい状態を読み取ります
4. アクションの前後の状態を指定すると、実行する操作（または引数として渡す値）が決定されます。

まさにあなたの2番目の例。 これらのすべてのステップが常に必要であると言っているのではありません。 多くの場合、それらの一部を省略できます。 しかし、複雑なケースでは、それがあなたが行動しなければならない方法です。 これは、任意の状態遷移の一般化されたフローです。 また、FSMの境界がAC対レデューサー/ストアに移動したことも意味します。

しかし、境界を移動すると、他の問題が発生します。

1. 非同期操作がストア/レデューサーにある場合、2つの独立したFSMが同じイベントに反応する可能性があります。 したがって、新しい機能を追加するには、既存のイベントに反応するストア/レデューサーを追加するだけで済みます。
   ただし、ACでの操作では、ストア/リデューサーを追加し、ロジックの非同期部分も追加して既存のACを編集する必要があります。 他のレデューサーの非同期ロジックがすでに含まれている場合...クールではありません。
   このようなコードを維持することは明らかに困難です。
2. 同期アクションと非同期アクションの場合、アプリの制御フローは異なります。 同期アクションの場合、reducerが遷移を制御します。非同期の場合、ACは、このイベント/アクションによって引き起こされる可能性のあるすべての遷移を効果的に制御します。

ほとんどの問題は、ほとんどのWebアプリの単純な状態要件によって隠されていることに注意してください。 しかし、複雑なステートフルアプリがある場合は、間違いなくこれらの状況に直面します。

ほとんどの場合、おそらくあらゆる種類の回避策を思い付くでしょう。 ただし、状態遷移ロジックがより適切にカプセル化され、FSMがACとレデューサーの間で分離されていない場合は、そもそもそれらを回避できます。

残念ながら、状態遷移の「副作用」部分は依然として状態遷移の一部であり、個別の独立したロジックではありません。 そのため、私にとって(state, action) => (state, sideEffects)はより自然に見えます。 ええ、それはもう「reduce」シグニチャではありません％）しかし、フレームワークのドメインはデータ変換ではなく、状態遷移です。

アクションクリエーターまたはストアで非同期を開始する必要があるかどうかは、バニラフラックスの場合と同じです。

はい。ただし、Fluxは、非同期コールバックでディスパッチ（）するか、状態を直接変更する限り、ストアに非同期のものを置くことを禁止していません。 ほとんどの実装が非同期にACを使用することを推奨したとしても、それらは一種の意見がありません。 個人的には、ACをコントローラーとして扱う方がFSMに精神的に移行するよりも精神的に便利なので、MVCを彷彿とさせると思います。

@vladar

(state, action) => (state, sideEffects)

考え中。 つまり、combineReducers関数の戻り値の型を[state、SideEffects]または[state、[SideEffects]]に変更し、そのコードを変更して、レデューサーからのSideEffectsを組み合わせる必要があります。 元の（状態、アクション）=>状態リデューサータイプは、combineReducersが（状態）戻り値の型を[状態]または[状態、[]]に強制変換するため、サポートされたままになる可能性があります。

次に、ReduxのどこかにSideEffectsを実行してディスパッチする必要があります。 これは、新しい状態を適用し、SideEffectsリストを実行してディスパッチするStore.dispatch（）で実行できます。 終わりのない素晴らしい再帰に入ることができるかどうかを考えています。

あるいは、ミドルウェアレベルのどこかで実行することもできますが、Store.dispatchはアクションとともにSideEffectsリストを返す必要があると思います。

@vladar https://github.com/gaearon/redux/issues/291#issuecomment -125267259

@vladar

はい。ただし、Fluxは、非同期コールバックでディスパッチ（）するか、状態を直接変更する限り、ストアに非同期のものを置くことを禁止していません。 ほとんどの実装が非同期にACを使用することを推奨したとしても、それらは一種の意見がありません。 個人的には、ACをコントローラーとして扱う方がFSMに精神的に移行するよりも精神的に便利なので、MVCを彷彿とさせると思います。

ActionCreatorsをコントローラーとして扱うのは良い考え方ではないことに同意します。 複雑なロジックの場合、レデューサーからACに制御を戻す必要があると考えてしまうのは根本的な原因です。 私はそれを必要とすべきではありません。 ACが非同期を処理する場合、それらはせいぜい要求ハンドラーのようである必要があります-どこかで行われた決定に基づいて実行され、この要求はドメインを横断するべきではありません。

コントローラとしての役割を回避するための唯一のオプションは、スマートコンポーネントを介してロジックをルーティングし、ActionCreatorsを使用して、UIへの直接応答でロジックの最初のステップを実行することです。 実際の最初の決定は、Redux.stateおよび/またはコンポーネントのローカル状態に基づいてスマートコンポーネントで行われます。

カテゴリを削除し、webapiを使用して応答して他の何かを更新/削除するという前の例のこのアプローチは、良くありません。 私はそれが開発者の好みに基づいて異なる技術の混合につながると思います-それはAC、レデューサー、スマートコンポーネントにあるべきですか？ パターンがどのように進化するか見てみましょう。

非同期通話を店舗から遠ざけるためにポイントを購入していました。 しかし、私はそれが有効であるとは思いません。なぜなら、私見では、どこかで複雑さが大幅に高まるからです。 一方、ストア/リデューサーで非同期関数を実行してディスパッチするだけの場合、または純粋なアプローチでこれらの関数をデータとして処理し、遠く離れた場所でトリガーする限り、それほど複雑ではありません。

アクターも同様に、非同期を実行してメッセージ（アクションオブジェクト）を他のアクターに送信したり、自分自身に送信してFSMを続行したりできます。

ここには実用的なものがないようですので、締めくくります。 非同期アクションドキュメントは、ほとんどの質問に答えるはずです。 実行できる実際のコードがなければ、理論的な議論は私には価値がないように思われます。 ;-)

@gaearonは、API呼び出しを処理する正しい方法を実装する実際のコードをreduxを使用した例の1つに追加できますか（ミドルウェアを使用する「実際の」例の外）？

すべてのドキュメントを読んだ後でも実際の配置について質問があり、この問題を数回、これらの副作用を配置するファイルを理解するのに問題がありますhttps://github.com/rackt/redux/issues/291#issuecomment -123010379 。 これは、この問題のスレッドからの「正しい」例だと思います。

この分野の説明を事前に感謝します。

不純なアクションクリエーターについての重要な考えを指摘したいと思います。

アクションクリエーターに非同期呼び出しを入れること、または一般的に不純なアクションクリエーターを持つことは、私にとって大きな欠点が1つあります。それは、アプリケーションの制御ロジックを完全にスワップアウトすることは、ストアをスワップアウトすることほど単純ではないように、制御ロジックをフラグメント化することです。作成者。 私は常に非同期プロセスにミドルウェアを使用し、不純なアクション作成者を完全に回避するつもりです。

私が開発しているアプリには、少なくとも2つのバージョンがあります。1つはオンサイトのRaspberry Piで実行され、もう1つはポータルを実行します。 顧客が運営するパブリックポータル/ポータル用に個別のバージョンが存在する場合もあります。 異なるAPIを使用する必要があるかどうかは定かではありませんが、可能な限りその可能性に備えたいと考えています。ミドルウェアを使用すると、それが可能になります。

そして私にとって、アクションクリエーター間でAPI呼び出しを分散させるという概念は、状態の更新を集中管理するというReduxの概念に完全に反しています。 確かに、APIリクエストがバックグラウンドで実行されているという単なる事実は、Reduxストアの状態の一部ではありませんが、それでもアプリケーションの状態であり、正確に制御する必要があります。 そして、Reduxストア/リデューサーのように、制御が分散ではなく集中化されている場合に、最も正確に制御できることがわかりました。

@ jedwards1211まだチェックアウトしていない場合は、 https：//github.com/redux-effects/redux-effectsに興味があるかもしれません。また、＃569での議論にも興味があるかもしれません。

@gaearonかっこいい、指摘してくれてありがとう！ いずれにせよ、私自身のミドルウェアを使用することはこれまでそれほど難しくありませんでした:)

Elmのようなアプローチを作成しました： redux-side-effect 。 READMEはアプローチを説明し、それを代替案と比較します。

@gregwebs redux-side-effect好きですが、複数の異なるストアコンフィギュレーターがある場合、 sideEffect関数をレデューサーモジュールにどのように取り込むかという問題があるため、スワップ可能な制御ロジックでも扱いにくいでしょう。さまざまなビルドで使用されるモジュール。

ただし、面白いハックを使用することもできます。 sideEffectをstate自体に格納するだけで、レデューサーが自動的に利用できるようになります。 ：stuck_out_tongue_winking_eye：

https://github.com/rackt/redux/pull/569/のようなものは、私が働きたい方法にほぼ理想的ですが、もちろん、標準部分にならない限り、本番プロジェクトでは使用したくありません。 APIの。

アイデアは次のとおりです。ミドルウェアにアクションにsideEffect関数を固定させます。 少しハッキーですが、レデューサーが非同期コードを開始できるようにするために必要な可能な限り小さな変更：

sideEffectMiddleware.js ：

export default store => next => action => {
  let sideEffects = [];
  action.sideEffect = callback => sideEffects.push(callback);
  let result = next(action);
  sideEffects.forEach(sideEffect => sideEffect(store));
  return result;
};

単純なsideEffectアプローチには複数の方法があります。 バリアントを試して、報告してください

上記のsideEffectMiddlewareアプローチを使用するようにコードをリファクタリングしましたが、結果として得られるコード編成が本当に気に入っています。 sideEffect関数をどこからでもレデューサーにインポートする必要がないのは素晴らしいことです。 actionれているだけです。

@ jedwards1211パッケージのバージョン2.1.0で、コードをactionSideEffectMiddlewareとして公開しました。

@gregwebsかっこいい！ 私を共同編集者としてリストしてくれませんか？

@ jedwards1211あなたが追加されました。 たぶんあなたは適切なリプレイサポートを追加するでしょう:)私がこれを使っているところではまだそれを利用することはできません。

@gaearon記録および再生されたアクションは、ミドルウェアをまったく通過しないと思いますよね？

彼らはそうします、それは彼らが記録される時までに彼らがすでに明白なオブジェクトであるということだけです、それでミドルウェアは通常介入しません。

@gaearonうーん。 だから私は実際にその機能を試していませんが...いくつかの副作用ミドルウェアも記録/再生を壊すだろうと思いますか？ たとえばredux-effects-fetchを例にとると、プレーンオブジェクトのFETCHアクションに対してajaxリクエストを実行します。

function fetchMiddleware ({dispatch, getState}) {
  return next => action =>
    action.type === 'FETCH'
      ? fetch(action.payload.url, action.payload.params).then(checkStatus).then(deserialize, deserialize)
      : next(action)
}

レコーダがFETCHアクションのstepsから[success, failure]コールバックをクリーンアップする場合、 redux-effectsミドルウェアは状態を変更するアクションをディスパッチしませんが、それでも必要ありません。一連のajaxリクエストをトリガーするために再生します。

redux-loggerような「純粋な」ミドルウェア（追加のアクションをディスパッチしない）を「不純な」ミドルウェア（アクションをディスパッチする可能性がある）から分離する方法はありますか？

残念ながら、私はredux-effects詳しく調べていないので、あなたの質問に答えることができません。

問題ありません。いずれにせよ、レコーダーは、ミドルウェアが副作用を実行するかどうかを決定するために使用できるアクションにフラグを追加しますか？ 私は自分のミドルウェアでdevtoolsを正しくサポートできる方法を見つけようとしています

そうではありません。 devTools()はエンハンサー構成チェーンの_after_ applyMiddlewareに配置されると予想されるため、アクションに到達するまでに、それは「最終的な」アクションであり、それ以上の解釈は必要ありません。

ああ、なるほど、ミドルウェアが副作用を実行した後、アクションからフィールドを削除/微調整して、再生時にミドルウェアを通過するときに副作用がトリガーされないようにすることができます。開発ツールで動作しますよね？

ええ、それは良い方法のようです。

素晴らしい、私を啓発してくれてありがとう！

@gaearon @vladar @ jedwards1211https ： 。 基本的にはelmish (state, action) => (state, sideEffects)実装ですが、レデューサーがタプルを返す代わりに（すでに気付いたのは不可能です）、結果を生成します。
私はすぐにそれで遊んだ、ホットリロードとリプレイは大丈夫のようだ。 これまでのところ、redux機能が壊れていることはありませんが、上級のreduxerの一部が何かを見つける可能性があります。 :)
私にとって、これはreduxスタックへの非常に重要な追加のように見えます。これにより、ロジックを主にレデューサーに配置して、効果（結果が現在の状態だけに依存しない遷移アクション）を外部サービスに委任する、効果的でテスト可能なステートマシンにすることができます（ Elmのアーキテクチャ、エフェクト、サービスとほとんど同じです）。

もう1つのアプローチはredux-sagaです。これもジェネレーターを使用しますが、副作用をレデューサーから分離します。

私は意味@minedeljkovic信じる@gaearon

私にとって、これはreduxスタックへの非常に重要な追加のように見えます。これにより、ロジックを主にレデューサーに配置して、効果（結果が現在の状態だけに依存しない遷移アクション）を外部サービスに委任する、効果的でテスト可能なステートマシンにすることができます（ Elmのアーキテクチャ、エフェクト、サービスとほとんど同じです）。

https://github.com/yelouafi/redux-saga/は、 redux-thunk動作と非常によく似ているため、従来のアプローチに対する主な利点として、長時間実行されるトランザクションを容易にする構文糖衣構文の代わりに。

一方、 https：//github.com/salsita/redux-side-effectsはElmアーキテクチャに似ています。

はい、redux-sagaとredux-side-effectsは、ジェネレーターを使用して副作用を宣言し、それぞれsagasとreducersを純粋に保ちます。 それは似ています。

レデューサーでそれを好む2つの理由：

1. 効果を宣言する方法に影響を与える可能性のある現在の状態に明示的にアクセスできます（これは、このディスカッション中の@vladarのポイントの1つだったと思います）
2. 新しいコンセプトは導入されていません（Saga in redux-saga）

https://github.com/rackt/redux/issues/1139#issuecomment -165419770の私のコメントは、 redux-sagaがこれを解決せず、モデルを受け入れる以外にこれを解決する他の方法がないため、引き続き有効です。 Elmアーキテクチャで使用されます。

redux-side-effectsについての私のポイントを強調しようとしている簡単な要点を置きます： //gist.github.com/minedeljkovic/7347c0b528110889aa50

私は、「現実の世界」で十分だと思う最も単純なシナリオを定義しようとしましたが、それでもこの議論のいくつかのポイントを強調しています。

シナリオは次のとおりです。
アプリケーションには、個人ユーザーデータを入力する必要がある「ユーザー登録」部分があります。 他の個人データの中で、出生地は国のリストから選択されます。 選択は「国の選択」ダイアログで実行され、ユーザーは国を選択し、選択を確認するかキャンセルするかを選択できます。 ユーザーが選択を確認しようとしているが、国が選択されていない場合は、警告する必要があります。

アーキテクチャの制約：

1. CountrySelection機能はモジュール式である必要があり（ redux ducksの精神で）、アプリケーションの複数の部分で再利用できます（たとえば、生産国を入力する必要があるアプリケーションの「製品管理」部分でも）。
2. CountrySelectionの状態のスライスはグローバル（redux状態のルートにある）と見なされるべきではありませんが、それを呼び出すモジュールに対してローカルである（そしてそのモジュールによって制御される）必要があります。
3. この機能のコアロジックには、可動部分をできるだけ少なくする必要があります（私の要点では、このコアロジックはレデューサーにのみ実装されます（そしてロジックの最も重要な部分のみ）。すべてのredux駆動コンポーネントと同様に、コンポーネントは簡単である必要があります。である:)。 彼らの唯一の責任は、現在の状態をレンダリングし、アクションをディスパッチすることです。）

この会話に関する要点の最も重要な部分は、countrySelectionレデューサーがCONFIRM_SELECTIONアクションを処理する方法にあります。

@gaearon 、私は主に、標準のreduxに加えてreduxの副作用が制約を考慮した最も単純なソリューションの表面を提供するという私の声明に対するあなたの意見を評価します。

このシナリオを実装するための可能な代替案（redux-side-effectsを使用せずに、redux-saga、redux-thunk、またはその他の方法を使用）も非常に適用されます。

@ tomkis1 、私はあなたの意見をここに伝えたいと

（この要点https://gist.github.com/minedeljkovic/9d4495c7ac5203def688には、globalActionsが回避される実装が少し異なります。このトピックでは重要ではありませんが、誰かがこのパターンについてコメントしたいと思うかもしれません）

@minedeljkovic要点をありがとう。 あなたの例には概念的な問題が1つあります。 redux-side-effectsは、副作用のみに使用することを目的としています。 ただし、あなたの例では、副作用はありませんが、長寿命のビジネストランザクションであるため、 redux-sagaがはるかに適しています。 @slorberと@yelouafiは、これにもっと光を

言い換えれば、私にとって最も懸念される問題は、レデューサー内の新しいアクションの同期dispatchingです（https://github.com/salsita/redux-side-effects/pull/9#issuecomment-165475991）：

yield dispatch => dispatch({type: COUNTRY_SELECTION_SUCCESS, payload: state.selectedCountryId});

@slorberには「ビジネスの副作用」という用語が付いているとredux-sagaは、この特定の問題を解決するのに役立ちます。

@mindjuiceあなたの例を完全に理解するかどうかはわかりませんが、ここで示したオンボーディングの例が好きです： https ：

佐賀のパターンでは、いくつかの暗黙的なことを明示的にすることもできます。
たとえば、アクションを実行することによって何が起こったかを説明するだけで（私にとっては過去形である必要があるため、イベントが好きです）、いくつかのビジネスルールが開始されてUIが更新されます。 あなたの場合、エラーの表示は暗黙的です。 佐賀では、確認時に、国が選択されていない場合は、アクション「NO_COUNTRY_SELECTED_ERROR_DISPLAYED」などをディスパッチする可能性があります。 私はそれが完全に明白であることを好みます。

また、佐賀はアヒルの間の結合点として見ることができます。
たとえば、duck1とduck2があり、それぞれにローカルアクションがあります。 2羽のアヒルを結合するというアイデアが気に入らない場合（つまり、1羽のアヒルが2羽目のアヒルのactionsCreatorsを使用する）、何が起こったのかを説明させてから、複雑なビジネスルールを相互に結び付ける佐賀を作成することができます。アヒル2羽。

すっごく、それはめちゃくちゃ長いスレッドですが、まだ問題の解決策はありますか？

非同期のaction()あり、コードがエラーを示すか、結果を表示する必要があるとします。

最初のアプローチはそれを次のようにすることでした

// the action call
action().then(dispatch(SUCCESS)).catch(dispatch(FAILURE))

// the reducer
case SUCCESS:
    state.succeeded = true
    alert('Success')

case FAILURE:
    state.succeeded = false
    alert('Failure')

しかし、レデューサーには「副作用」が含まれているため、Redux-wayではないことがわかりました（それが何を意味するのかわかりません）。
簡単に言えば、正しい方法は、これらのalert()レデューサーからどこかに移動することです。

それはどこかに、これをactionと呼ぶReactコンポーネントである可能性があります。
だから今私のコードは次のようになります：

// the reducer
case SUCCESS:
    state.succeeded = true

case FAILURE:
    state.succeeded = false

// the React component
on_click: function()
{
    action().then
    ({
        dispatch(SUCCESS)

        alert('Success')
        // do something else. maybe call another action
    })
    .catch
    ({
        dispatch(FAILURE)

        alert('Failure')
        // do something else. maybe call another action
    })
}

これは今それを行う正しい方法ですか？
または、さらに調査してサードパーティのライブラリを適用する必要がありますか？

Reduxは決して単純ではありません。 実際のアプリの場合、理解するのは簡単ではありません。 Mabyeは、正しい方法を示す標準的な例として、実際のアプリリポジトリのサンプルが必要です。

@ Halt-hammerzeitRedux自体は非常にシンプルです。 紛らわしい断片化は、Reduxを使用する際のレデューサーからの副作用の統合/分離に関するさまざまなニーズや意見から来ています。

また、断片化は、Reduxで必要な副作用を実行するのはそれほど難しくないという事実から生じています。 私自身の基本的な副作用ミドルウェアをロールするのに約10行のコードしかかかりませんでした。 だからあなたの自由を受け入れ、「正しい」方法について心配しないでください。

@ jedwards1211 「Redux自体」には価値や意味がなく、その主な目的はFlux開発者の日常の問題を解決することであるため意味がありません。 これは、AJAX、美しいアニメーション、その他すべての_通常および期待される_ものを意味します

@ halt-hammerzeitそこにポイントがあります。 Reduxは確かに、ほとんどの人に状態の更新を管理する方法について同意してもらうことを目的としているようです。したがって、ほとんどの人が副作用の実行方法について同意していないのは残念です。

リポジトリの「examples」フォルダを見たことがありますか？

副作用を実行する方法は複数ありますが、一般的には、すべての例で行うように、Reduxの外部またはアクションクリエーターの内部で実行することをお勧めします。

はい、私は知っています...私が言っているのは、このスレッドは、副作用を実行するための最良の方法についての（少なくともここの人々の間で）コンセンサスの欠如を示しています。

おそらくほとんどのユーザーはサンクアクションクリエーターを使用しており、私たちは単なる外れ値です。

^彼が言ったこと。

私はすべての最高の心が単一の正しい解決策に同意することを望みます
9000の画面を読む必要がないように石に刻みます
糸

2016年1月7日木曜日、AndyEdwardsの[email protected]は次のように書いています。

はい、私は知っています...私が言っているのは、このスレッドは不足していることを示しています
サイドを実行するための最良の方法についてのコンセンサス（少なくともここの人々の間で）
効果。

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

だから、私は推測する、現在合意されているドルーションは、実際にすべてを行うことです
クリエイター。 私は、このアプローチを使用してみて、欠陥を見つけた場合に備えて
ここに投稿します

2016年1月7日木曜日、НиколайКучумовkuchumovn @ gmail.comは次のように書いています。

^彼が言ったこと。

私はすべての最高の心が単一の正しい解決策に同意することを望みます
9000の画面を読む必要がないように石に刻みます
糸

2016年1月7日木曜日、Andy Edwards < [email protected]
<_e i = "16">

はい、私は知っています...私が言っているのは、このスレッドは不足していることを示しています
サイドを実行するための最良の方法についてのコンセンサス（少なくともここの人々の間で）
効果。

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

これと同様のスレッドが存在するのは、Reduxユーザーの1％が、副作用に対してより強力で純粋な宣言型のソリューションを探しているためです。 誰も同意できないという印象を持たないでください。 サイレントマジョリティは思考と約束を使用し、このアプローチにほとんど満足しています。 しかし、他の技術と同様に、欠点とトレードオフがあります。 複雑な非同期ロジックがある場合は、代わりにReduxを削除してRxを探索することをお勧めします。 ReduxパターンはRxで簡単に表現できます。

はい、ありがとう

2016年1月7日（木曜日）には、ダン・アブラモフ監督の[email protected]は書きました：

Reduxユーザーの1％が探しているので、これと同様のスレッドが存在します
副作用のためのより強力な/純粋な/宣言型のソリューション。 しないでください
誰もそれに同意できないという印象を持ってください。 サイレントマジョリティは
考えて約束し、このアプローチにほとんど満足しています。 しかし、他のように
技術には欠点とトレードオフがあります。 複雑な非同期ロジックがある場合
代わりに、Reduxを削除してRxを探索することをお勧めします。 Reduxパターンは
Rxで簡単に表現できます。

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

@gaearonええ、その通りです。 そして、Reduxは私たちのさまざまなアプローチすべてに対応するのに十分な柔軟性があることを感謝しています！

@ halt-hammerzeitここで私の答えを見て、redux-sagaがredux-thunkよりも優れている理由を説明します： http ：//stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-

@gaearonちなみに、stackoverflowに関するあなたの答えには、ドキュメントと同じ欠陥があります-それは最も単純なケースだけをカバーしています
http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-async-flow-in-redux/34599594#34599594
実際のアプリケーションは、AJAXを介してデータをフェッチするだけでなく、エラーを処理し、アクション呼び出しの出力に応じていくつかのアクションを実行する必要があります。
あなたのアドバイスは、他のイベントをdispatchすることです。それだけです。
では、コードがアクションの完了時にユーザーにalert()を要求した場合はどうなりますか？
それはそれらのthunkが役に立たないところですが、約束は役に立ちます。
私は現在、単純なpromiseを使用してコードを記述しており、そのように機能します。

redux-sagaについての隣接するコメントを読みました。
それが何をするのか理解できませんでした、笑。
私はmonadsことなどにはあまり興味がなく、 thunkが何であるかはまだわかりません。また、そもそもその奇妙な言葉は好きではありません。

それでは、ReactコンポーネントでPromisesを使い続けます。

ドキュメント全体でサンクからの約束を返すことをお勧めします。

@gaearonええ、それが私が話していることです： on_click() { dispatch(load_stuff()).then(show_modal('done')) }
それで十分です。

私はあなたがまだ何かを逃していると思います。
redux-thunkのREADMEをご覧ください。
「構成」セクションで、サンクアクションクリエーターをチェーンする方法を示します。

@gaearonええ、それはまさに私がしていることです：

store.dispatch(
  makeASandwichWithSecretSauce('My wife')
).then(() => {
  console.log('Done!');
});

それはまさに私が上で書いたものです：

on_click()
{
    dispatch(load_stuff())
        .then(() => show_modal('done'))
        .catch(() => show_error('not done'))
}

そのREADMEセクションはよく書かれています、thx

いいえ、これは私のポイントではありませんでした。 makeSandwichesForEverybody見てください。 他のサンクアクションクリエーターを呼ぶサンクアクションクリエーターです。 これが、すべてをコンポーネントに入れる必要がない理由です。 詳細については、このリポジトリのasync例も参照してください。

@gaearonしかし、たとえば、私の派手なアニメーションコードをアクションクリエーターに入れるのは適切ではないと思いますか？
この例を考えてみましょう。

button_on_click()
{
    this.props.dispatch(load_stuff())
        .then(() =>
        {
                const modal = ReactDOM.getDOMNode(this.refs.modal)
                jQuery(modal).fancy_animation(1200 /* ms */)
                setTimeout(() => jQuery.animate(modal, { background: 'red' }), 1500 /* ms */)
        })
        .catch(() =>
        {
                alert('Failed to bypass the root mainframe protocol to override the function call on the hyperthread's secondary firewall')
        })
}

どのようにそれを正しい方法で書き直しますか？

@ hallt-hammerzeit actionCreatorにpromiseを返して、コンポーネントがローカルコンポーネントの状態を使用してスピナーなどを表示できるようにすることができます（とにかくjqueryを使用する場合は避けるのが難しい）

それ以外の場合は、複雑なタイマーを管理して、redux-sagaでアニメーションを駆動できます。

このブログ投稿を見てください： http ：

ああ、この場合、それをコンポーネントに保持することは問題ありません。
（注：通常、Reactでは、jQueryで命令型を表示するよりも、すべてに宣言型モデルを使用するのが最善です。ただし、大したことではありません。）

@slorberええ、私はすでに私の「サンク」（またはあなたがそれらと呼ぶものは何でも;えーと、私はこの奇妙な言葉が好きではありません）から約束やものを返しているので、スピナーなどを扱うことができます。

@gaearonわかりました、

このスレッドでのサポートに満足しています。 私の疑問は今解決されたようです。

関連する新しいディスカッション： https ：

@gaearon非常に素晴らしい説明！ ：トロフィー：ありがとう：+1：