Redux: リダイレクトを使用したログイン/サインアップページのデータフローの処理に関するベストプラクティス

そこにshouldRedirectを入れる代わりに、 isLoggedInを追跡するだけのセッションリデューサーを用意してはどうでしょうか。 そうすれば、 shouldRedirect isLoggedInをチェックすることで、ログインページから他のページにリダイレクトできます。

また、状態のリセットは、レデューサーでLOGGED_INアクションを処理するだけで実行できます。 そのアクションが発生した場合は、エラー状態をnullの値に安全にリセットできることがわかります。

これは意味がありますか？ ：D

ログインページしかない場合は理にかなっていますが、もう少し一般的なアプローチです。 たとえば、サインアップページやパスワードリセットページの場合です。 ログインしている場合でも、それらのページを表示できるはずです。

また、これらのフラグはすべて同じフローであるため、これらすべてのページで使用する必要があります。

今それがより明確になることを願っています:)

ええ、私の観点からすると、「shouldRedirect」は特定のアクションに関連付けるにはあまりにも一般的すぎます。 どういうわけかそのフラグを設定するのを忘れて、ページが実際にはリダイレクトされるべきではない別のページにリダイレクトされるというバグが発生する可能性があります。

しかし、確かに、あなたがあなたの状態をきれいにしたいならば、あなたはただ行動でそれをすることができます。 または、reactの外部で履歴の変更を聞いてから、状態クリアアクションをトリガーすることもできます。 コンポーネント全体にそのロジックを分散させる必要はありませんが、1つの場所に保持できるため、これが望ましい場合があります。

しかし、それは州の清算のための可能な解決策にすぎません。 リダイレクトをうまく解決する方法はまだわかりません。

問題はまた、これらのフラグを状態にすることは意味がありますか？ そうでない場合、このフローはどのように実装する必要がありますか？

@gaearon時間があれば、フィードバックもお聞かせください。 ありがとう！ ：+1：

私のアプリケーションでは、ミドルウェアでリダイレクトしており、フラグを使用していません。 しかし、私はreact-routerを使用していません。

// action

/**
 * Creates login action
 *
 * <strong i="6">@param</strong> {string} email
 * <strong i="7">@param</strong> {string} password
 *
 * <strong i="8">@returns</strong> {{types: *[], promise: *}}
 */
export function login(email, password) {
    return {
        types: [LOGIN_REQUEST, LOGIN_SUCCESS, LOGIN_FAILURE],
        promise: post('/login').send({ email: email, password: password }).promise()
    };
}

// auth middleware 
/**
 * Intercepts LOGIN action and redirects to login screen
 * Otherwise just sends action to next middleware
 *
 * <strong i="9">@returns</strong> {Function}
 */
function authMiddleware({getState, dispatch}) {
    return (next) => (action) => {
        if (typeof action === 'object' && action.hasOwnProperty('type')) {
            if (action.type === LOGIN_SUCCESS) {
                next(action); // send it to next so identity will be set

                // get current route
                const state = getState();
                let path = '/dashboard';

                if (typeof state['router'] === 'object' && typeof state['router']['route'] === 'object' && null !== state['router']['route']) {
                    if (state.router.route.name === 'login' && typeof state.router.route.query['to'] === 'string') {
                        path = state.router.route.query.to;
                    }
                }

                return next(actions.transitionTo(path));
            }
        }

        return next(action);
    };
}

それはリファクタリングされていません、それは私のルーターソリューションのテスト目的のためだけに意図されています:)。

これは、アプリケーションからのコピーアンドペーストであり、ユーザーデータの読み込みとログインの処理方法です。コードに可能な限りコメントを付け、質問に対してreactifluxを使用します。

const AppConnector = createConnector((props$, state$, dispatch$, context$) => {
  // true when the user is logged in - drawn from Store state
  const loggedIn$ = state$
    .map(s => s.apiKey !== null)
    .distinctUntilChanged()

  // this returns an observable of a path to redirect to
  // in my app, I have a url like `/login?nextPath=dashboard`, but if that
  // isn't set, just go home
  const redirectTo$ = routeState$
    .map(s => s.router.query.nextPath || '/home')

  const redirect$ = loggedIn$
    .withLatestFrom(
      context$,
      redirectTo$,
      (loggedIn, context, path) => () => context.router.transitionTo(loggedIn ? path : '/login') // when the loggedIn state changes, i.e. user has logged in or out, respond to that change
    )
    .do(go => go())

  // It's awesome to have this here, because it means that no matter 
  // where the user loads in to the app (all child views of this view), 
  // the app will realise it needs to load data, and loads the according data 
  const userData$ = state$
    .map(getUser)

  const userDataIsEmpty$ = userData$
    .map(user => user.id === null || typeof user.id === 'undefined')
    .filter(s => s === true)

  const loadUserData$ = Rx.Observable.combineLatest(loggedIn$, userDataIsEmpty$, (logged, userDataIsEmpty) => loggedIn && userDataIsEmpty)
    // only when user is logged in but has no user data
    .filter(s => s === true)
    // fetch data with an action creator
    .withLatestFrom(dispatch$, (userData, dispatch) => () => dispatch(UserActions.loadUserData()))
    .forEach(go => go())


  return Rx.Observable.combineLatest(props$, state$, context$, redirect$, (props, state, context) => ({...props, ...state, ...context}))
}, render)

@emmenkoの質問に答えるという点では、あなたの州にshouldRedirectを置くことは受け入れられないので、より機能的なアプローチで行う必要があると思います。 errorMessageをアプリケーション状態にすることは問題ありません。トップレベルのerrorMessageではなく、 state.auth.errorMessageなどのログイン状態にあることを確認してください。

あなたの州でshouldRedirectを使用することは受け入れられず、より機能的なアプローチで行う必要があると思います

同意します。 一度だけ役立つものは、状態IMOにあるべきではありません。

また、Slackによると、 isLoggedInはアプリケーションの状態で保存する必要はないと思います。これは、実際には計算されたプロパティであり、 const isUserLoggedIn = state => state.user.id !== nullのような単純なセレクターで計算できるためです。

セレクターの使用法の詳細については、 https：//github.com/faassen/reselectを参照してください

@frederickfogerty例をありがとう。

ただし、質問：通常、 stateにはloggedInフラグがあるため、これはログインには問題なく機能します。 しかし、サインアップ、パスワードリセットなどの他のページはどうですか？
これらのページはログインと同じように動作します。問題がない場合はリダイレクトし、そうでない場合はエラーメッセージを表示します。
では、これらのケースをどのように処理しますか？ 私はそれらの場合の正しい流れを見つけるのに苦労していて、州がどこに住むべきかわかりません。

一度だけ役立つものは、状態IMOにあるべきではありません。

@gaearon同意しますが、そのための正しいアプローチがまだわかりません。 あなたはまだどこかに状態を持っている必要があります...

これは私が状態に何も保存せずにそれをatmでやっている方法です。

// actions
function login () {
  return { type: 'LOGGED_IN' }  
}

function submitLogin (form, dispatch) {
  return api.doLogin(form)
  .then(() => {
    dispatch(login()) // can dispatch something at this point
    return Promise.resolve()
  })
}

// in the component (login, signup, ...)
onSubmit () {
  actions.submitLogin(form, dispatch) // this returns a promise
  .then(() => this.setState({ shouldRedirect: true }))
  .catch(error => this.setState({ shouldRedirect: false, errorMessage: error }))
}

isLoggedInは実際には計算されたプロパティであるため、アプリケーションの状態で保存する必要はないと思います。

うん、理にかなっている。

@gaearonこの一般的なワークフロー（リダイレクトまたはエラーの表示）の質問は、「redux」を使用するか、別の方法で実行するかということだと思います。 そして、この代替案は何でしょうか？

関連しており、ここに固定します...実際、私もこの問題に対処しており、現在、次の例をReduxに再実装しようとしています。 私は自由な時間にこれを行っているので、まだ何も表示されません：
https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/

それは純粋なフラックスです：
https://github.com/auth0/react-flux-jwt-authentication-sample

たぶんそれはベストプラクティスに役立ちますか？！

@emmenko

では、これらのケースをどのように処理しますか？

使用しているものがログインしている限り、 isLoggedIn （アプリの状態ではありませんがマイナー）は変更され、リダイレクトされます。 その状態の変化がどこから来たのかは関係ありません:)

私が採用した最善のアプローチは、このロジックをコネクタに追加することです。コネクタには、承認などの子に機能が必要です。たとえば、 AppProtectedコンポーネントがあり、そのコンポーネントの子であるすべてのものに承認が必要です。次に、このロジックをAppProtectedコンポーネントのコネクタに配置します。

これは私が状態に何も保存せずにそれをatmでやっている方法です。

UIとACの間で双方向のデータフローがあり、フラックスに逆行するというアプローチは、絶対に好きではありません。 あなたがそれをしなければならないことに縛られているなら、あなたは次のようなことをすることができます

componentWillReceiveProps(nextProps) {
  if (['/login', '/sign-up'].indexOf(this.props.router.path) !== -1 && this.props.isLoggedIn) {
    this.context.router.transitionTo(this.props.router.query.nextPath || '/home')
  }
}

• ユーザーのログインが成功すると、ユーザーは関連するページからリダイレクトされます。
• ユーザーのログインが失敗した場合、ユーザーはログインせず、同じページに留まります（何も起こりません）

これはあなたが言及したすべてのページで機能します

申し訳ありませんが、リダイレクト/エラーレンダリングをどのように処理するかはまだわかりません。

一歩下がって、 reset-passwordページがあるとしましょう。 また、（前述のように）ある種のワンショットフラグを格納することによって、どの状態にも触れてはならないことも前提としています。
クリックしてフォームを送信すると、どうなりますか？

これが私が知りたいことであり、流れはどうあるべきか、そしてそれはどこに住むべきかです。

PS：これまでのフィードバックに感謝します！

[navigates to reset-password page] -> 
[types in email and hits submit] -> 
[onSubmit fires bound AC] ->
on successful reset this continues with:
[RESET_PASSWORD_SUCCESS] -> 
[resetPassword reducer returns state {passwordReset: true}] ->
[resetPasswordComponent.componentWillReceiveProps will check if state.passwordReset is true, and then will transition to its route]
on a failed reset this continues with:
[RESET_PASSWORD_FAILURE] -> 
[resetPassword reducer returns state {passwordResetError}] -> 
[resetPasswordComponent.componentWillReceiveProps() will check if state.passwordReset is true, and since is it not, nothing will happen - in render(), the error will be displayed]

これは非常に結合されているため、ログインページとサインアップページほどエレガントではありません。

私は眠らなければなりません、私は明日これ以上の質問に答えます

したがって、フラグを再び状態で保存しています;）

PS：おやすみなさい！

質問は、「フォームの送信」を一般化するよりも少し深いと思います。実際の状態と、 storeに表示されるデータと表示されないデータについてです。

フラックスデータフローのViewの部分を純粋関数render(state): DOMと考えるのが好きですが、それは完全には真実ではありません。
2つの入力フィールドをレンダリングする単純なフォームコンポーネントを例として取り上げましょう。

class Form extends React.Component {

  onFieldChanged (event) {
    this.setState({[event.target.name]: event.target.value})
  }

  render () {
    return (
      <form onChange={::this.onFieldChanged}>
        <input type="text" name="name" />
        <input type="text" name="surname" />
        <input type="email" name="email" />
      </form>
    )
  }
}

このフィールドに入力している間に、いくつかの内部状態の変更が実行されたため、最後に次のようなものがあります。

{
  name: 'John'
  surname: 'Snow'
}

そのため、アプリケーションの状態にリンクされていない状態が発生し、誰もそれを気にしません。 次回このフォームを再訪すると、消去されて表示され、「JohnSnow」は永久に消えます。
フラックスデータフローに触れることなくDOMを変更したようです。

これが通知書の購読フォームであると仮定しましょう。 今、私たちは外の世界と相互作用する必要があり、私たちは私たちの特別な行動を使ってそれを行います。

import { subscribe } from 'actions'

class Form extends React.Component {

  onFieldChanged (event) {
    this.setState({[event.target.name]: event.target.value})
  }

  onSubmit (event) {
    event.preventDefault()
    const { name, surname, email } = this.state
    subscribe(name, surname, email)
  }

  render () {
    return (
      <form onChange={::this.onFieldChanged} onSubmit={::this.onSubmit}>
        <input type="text" name="name" />
        <input type="text" name="surname" />
        <input type="email" name="email" />
        <button type="submit">Subscribe</button>
      </form>
    )
  }
}

ユーザーが送信ボタンを押すと、UIからの応答が成功しなかった場合、次に何をするかを期待します。 したがって、ロード画面をレンダリングしたり、リダイレクトしたり、エラーメッセージを表示したりするために、リクエストの状態を追跡したいと思います。
最初のアイデアは、 loading 、 submitted 、 failedなどの内部アクションをディスパッチして、アプリケーションの状態に責任を持たせることです。 状態をレンダリングしたいので、詳細については考えません。

  render () {
    //provided by connector of whatever
    const { props: { isLoading, error } } = this
    return (
      <form onChange={::this.onFieldChanged} onSubmit={::this.onSubmit}
        disabled={isLoading}>
        <input type="text" name="name" />
        <input type="text" name="surname" />
        <input type="email" name="email" />
        <button type="submit">Subscribe</button>
        {error ? <p>{ error }</p> : null}
      </form>
    )
  }

しかし、ここに悪魔が現れます。これで、このページ状態が持続し、次のrender(state)呼び出しでフォームがダーティ状態で表示されるため、フォームをマウントするたびに呼び出すcleanupアクションを作成する必要があります。
そして、フォームごとに、 loading 、 submitted 、 failed 、 cleanupのアクションの同じ定型文をストア/レデューサーで追加します...停止して考えるまで実際にレンダリングしたい状態について。

submittedはアプリケーションの状態に属しますか、それともnameフィールド値のような単なるコンポーネントの状態です。 ユーザーは、この状態がキャッシュに保持されることを本当に気にかけているのでしょうか、それとも、再訪したときにクリーンなフォームを見たいのでしょうか。 答え：それは状況によって異なります。

ただし、純粋な送信フォームの場合、フォームの状態はアプリケーションの状態とは関係がないと想定できます。ログインページの場合はユーザーlogged inであるかどうかを知りたい、または望まない彼がパスワードを変更したか失敗したかについて何かを知るために：要求が成功した場合は、彼を別の場所にリダイレクトするだけです。

では、コンポーネント以外の場所でこの状態を必要としないという命題はどうでしょうか。 やるだけやってみよう。
より凝った実装を提供するために、2015年に非同期の世界に住んでいて、どこにでもPromisesがあると想定できるので、アクションでPromiseを返します。

function subscribe (name, surname, email) {
  return api.request('/subscribtions', 'create', { name, surname, email })
}

次のステップで、 Componentのアクションの追跡を開始できます。

onSubmit (event) {
  event.preventDefault()
  const { name, surname, email } = this.state
  subscribe(name, surname, email)
    .then(() => { this.setState({ submitted: true }) })
    .catch(error => { this.setState({ error }) })
}

componentWillUpdate (object nextProps, object nextState) {
  if(nextState.submitted)
    redirect('somewhere')
}

アプリケーションの状態を汚染することなくコンポーネントをレンダリングするために必要なものがすべて揃っているようで、それをクリーンアップする必要がなくなりました。
だから私たちはほとんどそこにいます。 これで、 Componentフローの一般化を開始できます。
まず、懸念事項に分割しましょう。アクションと状態更新の反応を追跡します。
（リポジトリの範囲内にとどまるために、 reduxの観点からそれを実行しましょう）

import React, { PropTypes } from 'react'
import { bindActionCreators } from 'redux'

// Keeps track of action
export default function connectSubmitForm (Form, submitAction) {
  return React.createClass({
    contextTypes: {
      //redux Store
      store: PropTypes.object.isRequired
    },

    getInitialState () {
      return {}
    },

    onSubmit (...args) {
      const { context: { store: { dispatch } } } = this
      const { submitAction: submit }
        = bindActionCreators({ submitAction }, dispatch)
      submit(...args)
        .then(() => this.setState({ submitted: true }))
        .catch(error => this.setState({ error }))
    },

    render () {
      const {
        onSubmit,
        props,
        state: { submitted, error }
      } = this
      return (<Form {...props} onSubmit={onSubmit} submitted={submitted}
        error={error} />)
    }
  })
}

と

// redirect to path if predicate returns true
export default function redirect (path, predicate) {
  return Component =>
    class Composed extends React.Component {

      componentWillMount () {
        if (predicate(props))
          redirectTo(path)
      }

      componentWillReceiveProps (nextProps) {
        if (predicate(nextProps))
          redirectTo(path)
      }

      render () {
        return <Component {...this.props} />
      }
    }
}

//redirect to path if submitted
export default function redirectSubmitted (path) {
  return redirect(path, ({ submitted }) => submitted)
}

これで、一方ではdecorator submittedとerrorの小道具にonSubmitコールバックを提供し、他方でdecoratorがどこかにリダイレクトされます。プロパティsubmitted === trueを取得します。 それらをフォームに添付して、取得したいものを見てみましょう。

@redirectSubmitted('/')
class Form extends React.Component {

  onFieldChanged (event) {
    this.setState({[event.target.name]: event.target.value})
  }

  onSubmit (event) {
    event.preventDefault()
    const { name, surname, email } = this.state
    this.props.onSubmit(name, surname, email)
  }

  render () {
    return (
      <form onChange={::this.onFieldChanged} onSubmit={::this.onSubmit}>
        <input type="text" name="name" />
        <input type="text" name="surname" />
        <input type="email" name="email" />
        <button type="submit">Subscribe</button>
        {this.props.error ? <p>{ this.props.error }</p>: null}
      </form>
    )
  }
}

export default submitForm(Form, subscribe)

そして、ここにあります： routingライブラリの依存関係のない純粋なレンダリングフォーム、 flux実装、アプリケーションstate 、それが作成された目的を実行します：送信とリダイレクト。

読んでいただきありがとうございます。お時間を割いて申し訳ありません。

けっこうだ！ 正直なところ、私はまだローカルコンポーネントの状態をReduxに保存することに興味があります：＃159。

@stremlenyeそれはかなり滑らかです。 共有していただきありがとうございます！

読むための@iclanzanthx :)
実は今、彼が前のコメントで言及した@gaearonの提案について考えています。 いくつかの重要なアイデアを得るために＃159ディスカッションを見てください。

締めくくり— RR 1.0がリリースされたら、「ReactRouterでの使用」レシピでこれについて説明します。
これはhttps://github.com/rackt/redux/issues/637で追跡できます。

@stremlenyeあなたのアプローチはかなり素晴らしいです！ デコレータを使用する代わりに、すべての_unathorized_コンポーネントがネストされ、認証ストアにユーザーが入るとリダイレクトする責任がある、react-routerの高次コンポーネントを使用することは理にかなっていますか？

<ReduxRouter>
    <Route component={ Auth }>
      <Route path="/" component={ Login } />
      <Route path="/reset-password" component={ ResetPassword } />
    </Route>
  </ReduxRouter>

このようなもので、 Authはユーザーがログインしているかどうかの検出のみを処理します。このように、 Loginコンポーネントからアクションをディスパッチすることで、ストアを操作できます。 それほど純粋ではありませんが、コードが少なく、頭を動かすのが簡単です:)

@tomazzamanありがとう:)
私が書いたReactアプリケーションのほとんどには、新しいRouteを実装しなくても、同じ目的で使用できるApplicationContainerのようなものが含まれていました。
RR-v1.0.0-rc1を使用している場合は、 onEnterフックを使用して同じ目標を達成できます。現在の状態が認証済みと一致するかどうかを確認するだけです。

私もこれに頭を悩ませてきましたが、 @ stremlenyeはそれがどのように行われるかを示す素晴らしい仕事をしたようです。 問題は、「すべてがアクション-レデューサー-update-component-with-store-stateループを通過する必要がある」（私も）で立ち往生する傾向があり、その後、あらゆる種類のストアを汚染する傾向があることです。アプリ内の非常に特定のシナリオでのみ使用される状態（1つの画面で、「パスワードのリセットを正常に実行しましたか」など）。これは、コンポーネント内で非同期呼び出しを実行し、コンポーネント自体を更新するだけで簡単に処理できます。グローバル状態を汚染する代わりにthis.setStateを使用し、後でそのコンポーネントをもう一度開く場合に備えて、これらすべての状態変数をリセットする必要があります。 すべての開始/成功/エラー処理コードで状態レデューサーを汚染することについても言及していません。

ここでも私のコードを適応させて、問題が解決するかどうかを確認します。

@ ir-fuel時間があれば、githubに到達するものの小さな例をプッシュできますか？

それを行うのは難しいでしょうが、私がしたことの小さな例をあげることができます。 ユーザーがパスワードのリセットを要求できるコンポーネントがあります。 実際のリセット操作は次のようになります。

  submitForgotPassword = (username) => {
    this.setState({isLoading:true})
    doForgotPassword(username).then((result) => {
      this.setState({passwordIsReset:true,isLoading:false})
    }).catch((result) => {
      this.setState({passwordIsReset:false,isLoading:false,errorMessage:result.error})
    })
  }

doForgotPasswordは、サーバーへのajax呼び出しを行う関数です。

したがって、ストア/レデューサーへのラウンドトリップはなく、1つのコンポーネント内でのみ気になるものでグローバル状態を汚染することはなく、純粋にそのコンポーネントの状態を一時的に表示するために使用され、レデューサー内の状態変数の束をリセットする必要はありません。

レンダリングは次のようになります

  render() {

    let divClassName = ''

    if(this.state.isLoading) {
      divClassName = 'disable-controls'
    }

    let child = null

    if(this.state.passwordIsReset)
      child = (<ForgotPasswordSuccess/>)
    else
      child = (<ForgotPasswordForm submit={this.submitForgotPassword} errorMessage={this.state.errorMessage}/>)

    return (
      <div className={divClassName}>
        {child}
      </div>
    )
  }

これが明確であることを願っています。

よさそうだ：+1：
（私の観点から）カバーする必要がある唯一のトリックは、ミドルウェアを調整して、解除されたアクションからpromiseを返すことです（おそらくアクションの戻り値をプロキシするだけです）。 これを行うことで、コンポーネントスコープ内のPromiseのものに接続する機会を維持しながら、必要に応じて通常のフローで状態を変更するアクションを許可します。

アプリの状態を、すでにログインしている状態と考えても問題ないと思います。 ユーザーがログインしていない場合、なぜアプリの状態が必要なのですか？ 確かに、Loginコンポーネント内に1つ持つことができます。

ログインページのアプリロジックは、アプリのトップ状態を所有するのにそれほど複雑であってはなりませんよね？

@SkateFreakログインフローはアプリの一部です。 ログインフローの状態（進行状況、エラー）、サインアップのフローの状態など、Reactも使用したほうがよいと思いませんでした（他のアプリコンポーネントですでに使用している場合は、Reduxを使用する可能性があります）。

@sompylasar私はアプリの状態に賛成です。ユーザーが私のアプリの外部にいる限り、reduxストアなしでよりシンプルなアプリを提供できると思います。 私のアプリに入るとすぐに私のreduxストアが起動します。

このアプローチはこの瞬間まで私には有効でしたが、将来のプロジェクトでログインフェーズのアプリの状態が必要であることを理解できるかもしれません。

ストアのルートレベルで、ストアを「app」部分と「user / login」部分に分割し、それぞれに独自のレデューサーを設定できます。 したがって、その場合、ログインレデューサーコードでアプリレデューサーを汚染することはありません。その逆も同様です。

差出人： SkateFreak < notifications @ github.comnotifications @ github.com>
返信先：rackt / redux < [email protected] [email protected] >
日付：2015年12月13日日曜日13:48
宛先：rackt / redux < [email protected] [email protected] >
Cc：Joris Mans < [email protected] [email protected] >
件名：Re：[redux]リダイレクトを使用したログイン/サインアップページのデータフローの処理に関するベストプラクティス（＃297）

@sompyl asarhttps：//github.com/sompylasar私はアプリの状態に賛成です。使用が私のアプリの外にある限り、reduxストアなしで彼にもっとシンプルなアプリを提供できると思います。 私のアプリに入るとすぐに私のreduxストアが起動します。

このアプローチはこの瞬間まで私には有効でしたが、将来のプロジェクトでログインフェーズのアプリの状態が必要であることを理解できるかもしれません。

このメールに直接返信するか、Gi tHubhttps：//github.com/rackt/redux/issues/297#issuecomment-164287194で表示してください。

間違っている場合は訂正してください。ただし、ルートとコンポーネント間でデータとアプリの状態を共有するフラックスストアの目的ではありませんか？ ユーザーがサインインしたときにすべてが問題にならないのに、なぜ状態を「減らし」、「アクション」を使用してトップ状態を維持する必要があるのですか？

非常に整理されたクリーンな方法ですが、利点はわかりません。 サインイン、サインアップ、およびForgotPasswordを含む<Sign />コンポーネントで、ログイン前の状態を管理します。

サインアップは、ユーザー名とパスワードを要求するよりも複雑なプロセスになる可能性があるためです。
それはすべてあなたの流れの複雑さに依存します。

差出人： SkateFreak < notifications @ github.comnotifications @ github.com>
返信先：rackt / redux < [email protected] [email protected] >
日付：2015年12月13日日曜日14:00
宛先：rackt / redux < [email protected] [email protected] >
Cc：Joris Mans < [email protected] [email protected] >
件名：Re：[redux]リダイレクトを使用したログイン/サインアップページのデータフローの処理に関するベストプラクティス（＃297）

間違っている場合は訂正してください。ただし、ルートとコンポーネント間でデータとアプリの状態を共有するフラックスストアの目的ではありませんか？ ユーザーがサインインしたときにすべてが問題にならないのに、なぜ状態を「減らし」、「アクション」を使用してトップ状態を維持する必要があるのですか？

非常に整理されたクリーンな方法ですが、利点はわかりません。 サインイン、サインアップ、およびForgotPasswordを含むコンポーネントでログイン前の状態を管理します。

このメールに直接返信するか、Gi tHubhttps：//github.com/rackt/redux/issues/297#issuecomment-164287893で表示してください。

同意します。
しかし、私はSignUpを状態のあるフォームとして見ています。これは、どんなに複雑なimoでも十分なはずです...

一方、サインアップについて私は何を知っていますか...
人々が狂っています

現在、私はいくつかの類似しているが異なる問題に遭遇しました。

私は非常に複雑なサインアップのようなフローに取り組んでおり、ユーザーが必要な情報を入力できるようにするための継続ページがいくつかあります。各ページはフォームです。 フローは次のようになります。

FormPage_A-> FormPage_B-> FormPage_C-> SuccessPage

問題は、FormPage_Cの前にAPIリクエストを行わないことです。 ブラウザのFormPage_A / Bにデータを保存し、それらすべてをFormPage_CのAPIに送信するだけです。

では、問題は、FormPage_AとFormPage_Bのフォームデータをアプリケーション状態にする必要があるかどうかです。

はいの場合、UIに影響を与えない一時データをアプリケーション状態に保存しているようです。 また、reduxのアプリケーション状態はメモリ内にあるため、ユーザーがFormPage_Bのページを更新するとどうなりますか？

いいえの場合、それを置くのに適切な場所でしたか？ それを保存するために、reduxフローからfake apiのような別のレイヤーを構築する必要がありますか？

@frederickfogerty @gaearon @ ir-fuel @stremlenye

次のステップへの小道具として、送信に関連するthis.stateのプロパティを渡すだけです。
したがって、 FormPage_A.stateはFormPage_B.propsなどで渡され、 FormPage_Cで送信されます。

または、これを管理する親コンポーネントがある場合は、その親コン​​トロールのstateプロパティに状態を保存し、最後の手順の後にすべてを送信します

ユーザーが最初からやり直したページをリロードすることにした場合は、必ず確認してください。

@kpaxqinこの場合、 Flowのような管理コンポーネントを宣言して、ステップのサブセットとその状態、およびそれぞれの一般的なback-forwardロジックを処理できると思います。
したがって、ステップを可能な限りステートレスにし、コンポーネントを囲む際にプロセス全体の状態を追跡することができます。
何かのようなもの：

<Flow onForward={…} onBackward={}>
  <Step1 />
  <Step2 />
  <Step3 />
  …
  <Finish onSubmit={this.props.submit(this.state.model) />
</Flow>

@ ir-fuel @stremlenye

あなたの提案をありがとう。
私たちは皆、それらの一時的なものをアプリケーション状態にしたくないようです。

しかし、ユーザーがフローの半分でページを更新すると

ユーザーが最初からやり直したページをリロードすることにした場合は、必ず確認してください。

良いユーザーエクスペリエンスではないようです。私たちはモバイルサイトであり（これが、巨大なフォームを小さなページに分割する理由の1つです）、モバイルで入力するのは苦痛です。ユーザーがすべてを失うと、ユーザーは怒るだろうと思います。更新ボタンを押した後のこと、多分彼らはそれをあきらめるでしょう。

おそらく、reduxフローからfake apiを構築することは許容できる選択だと思います。各ステップで、 fake apiに送信し、必要に応じて、APIと同じように取得します。それはAPIのように、それに接続する唯一のものはアクションクリエーターであり、ページとコンポーネントはクリーンであり、エラーの処理も簡単です（APIエラーの処理には共通のコードを使用してください）。

これらのデータを永続化する場合は、コンポーネント状態やアプリケーション状態にしないでください。副作用はアクションクリエーターで処理する必要があるため、私にとっては理にかなっています。

//fake api
const fakeApi = {
  getStepA: ()=>{
    /* get things from LS */
    return Promise
  },
  setStepA: ()=>{
    /* put things into LS */
    return Promise
  }
}

// action creator
submitA(dispatch, getState) { // thunk function
  fakeApi
    .setStepA()
    .then(dispatchSuccess)
    .then(transitionToStepB)
    .catch(dispatchError);
}

それは私には物事を明確にしますが、私たちのアプリにreduxフローの何かを追加するのは奇妙に見えます。

ユーザーがページをリロードすることは本当に気にしません。
一方、あなたはいくつかのフォームで複雑なサインアッププロセスを持っているとあなたは私たちに言います、そしてあなたはそれがモバイルサイトであると言います。 また、モバイルデバイスで多くのことを入力しなければならない場合、ユーザーを怒らせて諦めさせると思いませんか？ リロードをサポートしないよりもさらに悪いと思います。 とにかく、サインアッププロセスの途中でページのリロードをサポートしているサイトはあまりないと思います。

実際にはあまり起こらないことのために、物事をもっと複雑にしているだけだと思います。 サインアッププロセスを簡素化するか、Webサイト全体で複数のステップに分割して、ユーザーが最終的にアカウントをアクティブにする前にXページのフォームに入力しているという印象を与えないようにすることに重点を置きます。

また、サインアップ中のリロードを本当にサポートしたい場合は、これらすべてのステップを制御する親コンポーネントにその状態をlocalStorageに保存させるだけです。

@kpaxqin 「偽のAPI」アプローチを採用します。 なぜ偽物なのか、マルチステッププロセスに必要なのは単なる中間ストレージAPIです。 すべてのAPIが必ずしもサーバー上にあり、HTTPまたはその他のネットワークプロトコルを介してアクセスされる必要はありません。

@ ir-fuelに同意するのは、現在のステップだけでなく、すべてのマルチステッププロセス状態を保存する必要があるということです。

@ ir-fuelリロードは、明示的なユーザーの意図なしに発生する可能性があります。たとえば、ユーザーがノートブックや電話などの別のモバイルアプリに切り替えることができ、デバイスのメモリが不足しているためにブラウザの状態が失われる可能性があります。ユーザーが戻ってきたときにリロードします。

ここでも問題は、Webアプリケーションのいくつかの画面でのみ必要なものでグローバルアプリケーションの状態を汚染していることです。

@sompylasar @kpaxqin @ ir-fuelが正しいアプローチを提案したと思います。最終的に永続化する中間的なものが必要な場合は、クライアント側で永続化してください。実装がはるかに簡単で、サーバーが一貫性のないデータを永続化する必要はありません。 t任意のhttp要求（モバイルデバイスでも大きな問題です）を実行し、将来的にアプローチを変更するのは非常に簡単です。

そして、データをどこかに永続化することについて–プロセスが失敗した後、またはすでに完了した後にデータをどのようにクリーンアップするかを考えてください–それがトピックの最初のテーマでした。
使用できる別のオプション–URLにユーザーデータを保持します。 フォームがいくつかのテキストフィールドで構成されている場合は、適切なトレードオフソリューションになる可能性があります。

それは「クライアント側またはサーバー側に保存する」というよりも、「親コンポーネントクラスでこの「アドホック」を処理するのか」と「アクション/リデューサー/ステートダンス全体を実行するのか」の問題です。
一時的な状態の場合、アクション/リデューサーを実行するのは好きではありません。 これは、実際のアプリケーションの状態に対してのみ行います。

@ ir-fuel：+1：

@stremlenyeもう一度私の答えを読んでください。 永続APIレイヤーを作成するためにサーバー側APIを作成する必要はないことを明示的に言います。

@ ir-fuelアクション/リデューサーを実行しないと、状態遷移の予測可能性と再生可能性がキャンセルされます。

@ ir-fuelフォームの送信後、アプリの状態を簡単にクリアできるため、「汚染」されることはありません。

RE：クリア。 アクションを明確にし、UIにサインアップフローをリセットするためのボタンを配置します。 ルーター経由でも作成できます（最初のサインアップURLにアクセスしたときにそのアクションをディスパッチし、サインアップが開始されている場合は、URLを別のものに変更します）。

@sompylasar明示的なボタンを使用して状態をリセットするのに問題はありません。問題は未処理の障害の後に発生します。状態が破損する可能性のある方法を予測し、特定のケースごとに復元戦略を定義することは困難です。

@stremlenyeはい、ソフトウェアエンジニアリングは時々難しいです。 予測可能な状態と遷移は、これを軽減するのに役立ちます。

それだけでなく、あなたの状態がjsonオブジェクトの束以上であり（すべてが慣例であり、何も強制されていないため、私は嫌いです）、Immutable.jsのRecordの行で何かを使用すると、オブジェクトのプロパティを事前に宣言する必要があります。これには、そこに必要なすべての一時的なものが含まれます。

私にとって、Immutable.jsを使用せずにreduxで何かを構築することは、起こるのを待っている単なる事故です。

Signupレコードを作成し、サインアップ時にnull以外にすることしかできないことは知っていますが、Webアプリにこれらのケースがたくさんある可能性があるため、問題はより根本的なものです。自分。

@ ir-燃料

それだけでなく、状態がjsonオブジェクトの束以上であり（すべてが慣例であり、何も強制されていないため、私は嫌いです）、Immutable.jsのレコードの行で何かを使用する場合は、プロパティを宣言する必要があります事前にオブジェクトを追加します。これには、そこに必要な一時的なものがすべて含まれています。

私にとって、Immutable.jsを使用せずにreduxで何かを構築することは、起こるのを待っている単なる事故です。

今のところ、reduxでImmutable.jsを使用することに確信が持てません。複雑すぎて統合できないように見えました（パフォーマンスが劣っています）。 開発およびテスト中のディープフリーズ、および一連のテストは、ほとんどの場合をカバーするのに十分なはずです。 また、レデューサーや参照がある他の場所で状態が変化しないようにするための厳密な規則。

サインアップレコードを作成して、サインアップ時にnull以外にすることしかできないことを知っています

はい、それは私が念頭に置いていたものです。

しかし、問題はもっと根本的なものです。なぜなら、Webアプリにこれらのケースがたくさんある可能性があるからです。それが、私を悩ませています。

これを明示的なアプリケーション状態と呼びます。常に、多くのコンポーネントで構成されるアプリの状態を把握しています。 状態構造をより明確でなく、より動的にしたい場合は、 https：//github.com/tonyhb/redux-uiをフォローしてください。

それがJS開発の全体的な問題です。 「慣習に固執しましょう」。 そのため、複雑な環境では機能しないことに気づき始めます。なぜなら、人々は間違いを犯し、TypeScriptやImmutable.jsなどのソリューションが付属しているからです。

統合するのが複雑すぎるのはなぜですか？ 'Record'を使用する場合、プロパティにアクセスするためのドット表記を使用して、これらすべてのオブジェクトを通常のJSオブジェクトとして使用します。これには、オブジェクトの一部であるプロパティを事前に宣言するという利点があります。 。

私はすべてのredux開発をImmutable.jsで行っており、何の問題もありません。 偶然にオブジェクトを変更できないという事実は、reduxの大きな利点であり、オブジェクトのプロトタイプを定義する「型安全性」も便利です。

また、サインアップ中のリロードを本当にサポートしたい場合は、これらすべてのステップを制御する親コンポーネントにその状態をlocalStorageに保存させるだけです。

@ ir-燃料
私にとって、localStorageに物事を入れることは副作用のように見え、コンポーネントでそれを行うのは良い習慣ではないようです。

ここでも問題は、Webアプリケーションのいくつかの画面でのみ必要なものでグローバルアプリケーションの状態を汚染していることです。

たぶん私は偽のAPIを十分に明確に説明していません。それを構築する最も重要な理由は、それらのものをonly need in a few screensをreduxのアプリケーション状態にしたくないということです。 FormPage_A / Bでは、APIを呼び出してフォームデータを保存し、次のステップに進みます。

//action
submitFormA (formA) {
  fakeApi
    .saveFormA(formA)
    .then(()=>{ transitionTo(nextPage) })
    .catch()
}

およびFormPage_C（最終フォーム）：

submitFormC (formC) {
  fakeApi
    .getFormAnB()
    .then(mergeFormData(formC)) //mergeFormData is a curry function
    .then(realApi.submitSignUp)
    .catch()
}

これらの一時データはすべて偽のAPIに存在し、グローバルアプリケーションの状態は汚染されていません。 偽のAPIのデータをクリアしてフローを再開したい場合は、アクションを送信するだけです。

@sompylasar明示的なボタンを使用して状態をリセットするのに問題はありません。問題は未処理の障害の後に発生します。状態が破損する可能性のある方法を予測し、特定のケースごとに復元戦略を定義することは困難です。

@stremlenye私はそれに同意しますが、これらの特定の失敗事例はビジネス上の問題である可能性が高いと思います。州をどこに置いても常にここにあり、正しい方法で処理する必要がありますが、瞬間。 開発者ができる唯一のことは、追跡を容易にして、苦痛を減らして修正できるようにすることです。

また、状態を親コンポーネントに入れると、状況が複雑になる時期について推論するのが難しくなる可能性があります。 偽のAPIを使用して、その状態をアクションで変更すると、より予測可能になります。

しかし、私は、偽のAPIがほとんどの場合、複雑さが少なく、重すぎるように見えることに同意します。

上記のすべてのメッセージを確認しませんでした。 ここでは、私のアプローチを示します。componentWillReceivePropsで小道具の変更を検出します。

状態の形状が次のようになっているとします。{loginPending、loginError}、ログインを開始するときに、loginPending = trueを設定します。 成功または失敗した場合は、{loginPending：false、loginError： 'エラー'を設定します。 }。

次に、コンポーネントでログイン成功イベントが発生したかどうかを検出し、ページをリダイレクトできます。

componentWillReceiveProps(nextProps) {
  if (this.props.loginPending && !nextProps.loginPending && !nextProps.loginError) {
    // Login success, redirect the page here.
  }
}

美しくはありませんが、うまく機能します。

react-router-reduxを使用してリダイレクト時にフォームをクリアすることに関する私の謙虚な実装。 レデューサー：

const initialState = {
    login: initialLoginState,
    signup: initialSignupState,
    // ...
};


export default function(state = initialState, action) {
  switch (action.type) {
    case '@@router/LOCATION_CHANGE':
      return {
        ...state,
        login: initialLoginState,
        signup: initialSignupState
      };
      // ...

このアプローチは大丈夫だと思いますか？ できます。

私はこれで終わった。 あなたがどう思うか教えてください：

reduxアクションの登録：

import { checkStatus } from 'helpers/fetch_helpers';
import { AUTH } from 'config/constants.endpoints';
import { USER_LOGGED_IN, USER_LOGGED_OUT, USER_REGISTERED } from 'config/constants.actions';
import { replace } from 'react-router-redux';

// other actions...

const userRegistered = (user) => ({
  type: USER_REGISTERED,
  user
});

export const register = (formData, redirectTo = '/') => {
  const fetchParams = {
    method: 'post',
    body: formData
  };

  const handleData = (dispatch) => (response) => response.json().then( (data) => {
    dispatch(userRegistered(data));
    dispatch(replace(redirectTo));
  });

  return (dispatch) => fetch(AUTH, fetchParams)
    .then(checkStatus)
    .then(handleData(dispatch));
};

フォームコンテナの登録：

import React, { Component } from 'react';
import RegisterForm from './register_form';
import { bindActionCreators } from 'redux';
import { connect } from 'react-redux';
import * as userActions from 'store/actions/user';
import { parseFormErrors } from 'helpers/fetch_helpers';

class RegisterFormContainer extends Component {
  state = {
    errors: {}
  }

  async handleSubmit(e) {
    e.preventDefault();

    const form = e.currentTarget;
    const formData = new FormData(form);
    const { register } = this.props.actions;

    try {
      await register(formData);
    } catch (error) {
      const errors = await parseFormErrors(error);

      this.setState({ errors });
    }
  }

  render() {
    return (
      <RegisterForm handleSubmit={ ::this.handleSubmit } errors={ this.state.errors } />
    );
  }
}

const mapDispatchToProps = (dispatch, ownProps) => ({
  actions: bindActionCreators({ register: userActions.register }, dispatch)
});

export default connect(
  null,
  mapDispatchToProps
)(RegisterFormContainer);

とヘルパー：

export const checkStatus = (response) => {
  if (response.ok) {
    return response;
  } else {
    const error = new Error(response.statusText);

    error.response = response;
    throw error;
  }
};

export const parseFormErrors = (error) => error.response.json().then( (data) => {
  if (data.errors) {
    const joinedErrors = _.mapValues(data.errors, (errors) => errors.join(' ') );

    return { ...joinedErrors };
  } else {
    console.error('request failed:', error);

    return {};
  }
});

重要なこと-登録が成功した場合にのみアクションとしてReduxストアに送られます。それ以外の場合、エラーはコンテナコンポーネントの状態に渡されます。 ユーザーがエラーを受け取った後、別のページに移動し、次にフォームページに移動します。フォームは空でエラーはありません。 「USER_REGISTRATION_REQUEST」または「USER_REGISTRATION_FAILURE」アクションは、アプリケーションの状態ではなくコンポーネントの状態を記述しているため、ありません。

@sunstorymvp

コードをasync / awaitでシュガーしました。このシュガーは、リクエストの3つの状態（前、進行中、後）があるという事実を隠します。 これらの状態は、ビューコンポーネントで非表示になります。 リクエストの開始は無視され、リクエストエラーはビューで処理され、redux経由でディスパッチされないため、アプリの状態はここでは使用できなくなります。 何らかの理由で、この状態を含むコンポーネントがアンマウントされてから再マウントされると、登録要求の状態が失われ、その結果が処理されず、後続のエラーが発生する可能性があります（ユーザーがすでに登録しているなど）。

ユーザーがエラーを受け取った後、別のページに移動し、次にフォームページに移動します。フォームは空でエラーはありません。

これを実現するために、ストアのエラーをリセットするコンポーネントマウントにUSER_REGISTRATION_RESETのようなアクションをディスパッチできます。 このアクションは、保留中の登録リクエストがない場合にのみ処理する必要があります。そうでない場合、保留中のリクエストの結果はアプリによって処理されません。

フィードバックをありがとう。

あなたはasync / awaitでコードをシュガーしました、そしてこのシュガーはリクエストの3つの状態（前、進行中、後）があるという事実を隠します

これらの条件は、async / awaitを使用するかどうかに関係なく存在します。

これらの状態は、ビューコンポーネントに非表示になります

意図したとおり、それはコンポーネントの状態です。なぜこれをアプリの状態にする必要があるのでしょうか。

リクエストの開始は無視されます

進行中...

リクエストエラーはビューで処理され、redux経由でディスパッチされません

意図した通り

何らかの理由で、この状態を含むコンポーネントがアンマウントされてから再マウントされると、登録要求の状態が失われ、その結果が処理されなくなります。

それは真実ではありません。 コンポーネントの状態や存在に関係なく、リクエストが成功すると、ユーザーは登録されてリダイレクトされます。 registerアクションクリエーター（handleData）を見てください。

それを達成するために、あなたはアクションをディスパッチすることができます...

そこが肝心だ。 別のアクション？ なぜそんなに定型文なのか？ 送信ボタンを無効または有効にし、フォームエラーまたはライブ検証を表示し、リクエストが開いているときにスピナーを表示します。これらのアクションは、デフォルトの状態を復元する新しいアクションにつながります。なぜこれをアプリの状態にする必要があるのですか？

それは真実ではありません。 コンポーネントの状態や存在に関係なく、リクエストが成功すると、ユーザーは登録されてリダイレクトされます。 登録アクション作成者（handleData）を見てください。

はい。ただし、リクエストの状態はアプリケーションの状態で追跡されないため、2つの後続のregisterリクエストの可能性が残ります。

送信ボタンを無効または有効にし、フォームエラーまたはライブ検証を表示し、リクエストが開いているときにスピナーを表示します。これらのアクションは、デフォルトの状態を復元する新しいアクションにつながります。なぜこれをアプリの状態にする必要があるのですか？

予測可能性と再生可能性のために、これがReduxの目的です。 アクションと初期状態だけで、アクションをディスパッチするだけでアプリを特定の状態にすることができます。 コンポーネントに何らかの状態が含まれ始めると、アプリの状態が崩壊し始め、アプリの状態を表す単一の状態ツリーはなくなります。

しかし、それについて過度に独断的にならないでください。 シナリオに応じて、Redux状態にする理由はたくさんあり、ローカルコンポーネント状態のままにする理由もたくさんあります。 http://redux.js.org/docs/FAQ.html#organizing-state-only-redux-stateおよびhttps://news.ycombinator.com/item?id=11890229を参照してください。

わかりました、今それは私にとって明らかです：それは依存します。 ありがとう！

componentWillReceivePropsを使用し、コンポーネントにauthオブジェクトがあります。 これがまったく役立つかどうかはわかりません。

// using reduxform
class LoginForm extends Component {
  static propTypes = {
    // this holds info on the current user.
    auth: PropTypes.shape({
      userId: PropTypes.number,
      token: PropTypes.string
    }),
     // react-router-redux.
    history: PropTypes.object.isRequired,
    submitting: PropTypes.bool.isRequired,
    fields: PropTypes.object.isRequired
  };
  componentWillReceiveProps(newProps) {
    const { auth } = newProps;
    auth && auth.token && this.props.history.go('#/');
  }
  render() {
    return (/**...*/) // form logic here.
  }
}

このようにすることに何か問題がありますか？

そのようなアプローチhttp://codereview.stackexchange.com/questions/138296/implementing-redirect-in-redux-middlewareはどうですか？
リダイレクトURLをアクションに渡し、ミドルウェアのreact-router-redux pushを使用して$ nextメソッドを追加で呼び出します。