Oauth2 の「リダイレクト フロー」を使用してユーザーを認証するアプリケーションがあります。つまり、ユーザーは別の Web サイトにリダイレクトされてログインし、その後自分のサイトにリダイレクトされます。
ドキュメントやその他の情報源はすべて、ビジネス ロジックはアクション クリエーターまたはリデューサーのいずれかに配置する必要があると主張しているようです。ただしlogin()、状態をまったく変更しない関数があります。それは、アプリケーションの現在の状態を localStorage のプレーンオブジェクトとして保存し、ユーザーを承認サーバーにリダイレクトすることです。ユーザーがログインしてリダイレクトされると、(別のコードによって) 状態が復元され、初期状態としてストア クリエーター関数に渡されます。
私の質問: 関数のロジックはlogin状態を取得するだけですが、状態を変更しないため、リデューサーには属しません。また、アクション作成者の定義であるアクションも返しません。アプリケーション構造のどこに配置すればよいですか?
実際にはアクションを作成しないアクション作成者がいても「大丈夫」ですか? 私は今 redux-thunk でこれを行っています (必要があるためgetState())。問題なく動作しますが、実際には「アクション作成者」ではないため、気分が悪くなります。一方で、logout()返す関数もあります。同じ場所に住んでいるように感じるアクション。まれなケースだと思いますが、この方法で状態を保存し、訪問者を他のサイトにリダイレクトする (またはリダイレクトせずに状態を保存するだけである) 理由がたくさん考えられるため、実際にはそうではありません。
PS。reduxストアをlocalStorageと自動的に同期するライブラリがあることは知っていますが、これは問題のポイントではありません。
編集:いくつかの明確化:
ビジネス ロジックを配置する場所に関する Redux ドキュメントから:レデューサーまたはアクション クリエーターにロジックのどの部分を配置する必要があるかについて、明確な答えは 1 つもありません。
読み進めると、ビジネス ロジックを配置する場所は、レデューサーまたはアクション クリエーターの 2 つだけであることが明らかになりました。今、私がやりたいことは状態に影響を与えず、レデューサーは定義上状態に影響を与えるため、このロジックをアクションクリエーターに入れることに傾いています。
アクション クリエーターに関するドキュメント:アクション クリエーターはまさに、アクションを作成する関数です。「アクション」と「アクション クリエーター」という用語は混同しやすいので、できるだけ適切な用語を使用してください。[...] Redux では、アクション作成者は単純にアクションを返します
アクションに関するドキュメント:アクションはプレーンな JavaScript オブジェクトです。
私のログイン例の擬似コード:
function login() {
// retrieving and serializing the state, then:
localStorage.set('my_app_id_state', my_serialized_state);
window.location = url_to_authorization_service;
}
アクション クリエーターの目的であるアクションを返さないため、このコードは明らかにアクション クリエーターでは使用できません。ただし、状態を取得する必要があるため、完全に独立させることもできません。
繰り返しになりますが、問題は、このコードをアプリケーション構造のどこに置くかです。
繰り返しますが、コードは機能し、すべてがうまくいっているので、これは学術的な質問だと思いますが、ここで Redux の本質的なルールを明らかに破っていることに非常に悩まされています。たぶんそれはただの例外ですか？
