Redux: 리디렉션이 있는 로그인/가입 페이지의 데이터 흐름 처리에 대한 모범 사례

shouldRedirect 대신 isLoggedIn 만 추적하는 세션 감속기를 사용하는 것은 어떻습니까? 이렇게 하면 shouldRedirect isLoggedIn 를 선택하여 로그인 페이지에서 다른 페이지로 리디렉션할 수 있습니다.

또한 상태 재설정은 감속기에서 LOGGED_IN 작업을 처리하여 수행할 수 있습니다. 해당 작업이 발생하면 오류 상태를 null 값으로 안전하게 재설정할 수 있습니다.

이게 말이 되요? :디

로그인 페이지만 있으면 이해가 되지만 좀 더 일반적인 접근 방식입니다. 예를 들어 가입 페이지 또는 비밀번호 재설정 페이지입니다. 로그인한 경우에도 해당 페이지를 계속 볼 수 있습니다.

그리고 해당 플래그는 모두 동일한 흐름을 가지므로 모든 페이지에서 사용해야 합니다.

이제 더 명확해지기를 바랍니다. :)

예, 내 관점에서 "shouldRedirect"는 특정 작업과 연결하기에는 너무 일반적입니다. 어떻게든 해당 플래그를 설정하는 것을 잊은 다음 페이지가 실제로 리디렉션되어서는 안 되는 다른 페이지로 리디렉션되는 버그가 발생할 수 있습니다.

하지만 확실히, 상태를 정리하고 싶다면 액션으로 할 수 있습니다. 또는 반응 외부의 기록 변경을 수신한 다음 상태 지우기 작업을 트리거할 수 있습니다. 구성 요소 전체에 해당 논리를 분산할 필요가 없지만 한 곳에서 유지할 수 있기 때문에 바람직할 수 있습니다.

그러나 그것은 국가 청산을 위한 가능한 해결책일 뿐입니다. 좋은 방법으로 리디렉션을 해결하는 방법을 아직 잘 모르겠습니다.

문제는 다음과 같습니다. 해당 플래그를 해당 주에 보유하는 것이 의미가 있습니까? 그렇지 않다면 이 흐름을 어떻게 구현해야 합니까?

@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 와 같은 간단한 선택기로 계산할 수 있는 계산된 속성에 더 가깝기 때문에 isLoggedIn 를 애플리케이션 상태에 저장해서는 안 된다고 생각합니다.

선택기 사용에 대한 자세한 내용은 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/

순수한 Flux입니다.
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]

이것은 매우 결합되어 있기 때문에 로그인 및 가입 페이지만큼 우아하지 않습니다.

나 자야겠어, 내일 질문 더 대답할게

그래서 우리는 플래그를 상태에 다시 저장하고 있습니다 ;)

추신: 좋은 밤!

질문이 '양식 제출'을 일반화하는 것보다 조금 더 깊다고 생각합니다. 실제로 상태가 무엇이며 어떤 데이터가 store 에 나타나야 하고 어떤 데이터가 표시되지 않아야 하는지에 대한 것입니다.

나는 플럭스 데이터 흐름의 View 부분을 순수 함수 render(state): DOM 생각하고 싶지만 완전히 사실은 아닙니다.
두 개의 입력 필드를 렌더링하는 간단한 양식 구성 요소의 예를 들어보겠습니다.

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'
}

그래서 우리는 애플리케이션 상태와 연결되지 않은 상태를 얻었고 아무도 그것에 대해 신경 쓰지 않았습니다. 다음에 이 양식을 다시 방문하면 지워진 것으로 표시되고 'John Snow'는 영원히 사라질 것입니다.
플럭스 데이터 흐름을 건드리지 않고 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 작업과 store/reducers… 우리가 실제로 렌더링하려는 상태에 대해.

submitted 는 애플리케이션 상태에 속합니까 아니면 name 필드 값과 같은 구성 요소 상태일 뿐입니다. 사용자가 이 상태를 캐시에 유지하는 데 정말로 관심이 있습니까? 아니면 다시 방문할 때 깨끗한 형식을 보고 싶어합니까? 답: 의존합니다.

그러나 순수한 제출 양식의 경우 양식 상태가 응용 프로그램 상태와 아무 관련이 없다고 가정할 수 있습니다 logged in 그가 비밀번호를 변경했거나 실패했는지에 대한 정보를 얻으려면 요청이 성공하면 그를 다른 곳으로 리디렉션하십시오.

그렇다면 Component 이외의 다른 곳에서는 이 상태가 필요하지 않다는 제안은 어떻습니까? 시도해 보겠습니다.
더 멋진 구현을 제공하기 위해 우리는 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 흐름을 일반화할 수 있습니다.
우선 작업 및 상태 업데이트 반응을 추적하는 문제로 분할할 수 있습니다.
(repo 범위에 머물기 위해 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 onSubmit submitted 및 error 소품을 제공하는 decorator와 다음과 같은 경우 어딘가로 리디렉션되는 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 꽤 매끄럽습니다. 공유해 주셔서 감사합니다!

@iclanzan thx 읽기용 :)
사실 지금은 이전 댓글에서 언급한 @gaearon 제안에 대해 생각하고 있습니다. 몇 가지 중요한 아이디어를 얻으려면 #159 토론을 살펴보십시오.

마무리 - RR 1.0이 나오면 "Usage with React Router" 레시피에서 다룰 것입니다.
이는 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 hook 으로 동일한 목표에 도달할 수 있습니다. 현재 상태가 인증됨과 일치하는지 확인하기만 하면 됩니다.

나는 이것에 대해서도 머리를 싸매고 있었고 @stremlenye 가 어떻게 할 수 있는지 보여주는 훌륭한 일을 한 것 같습니다. 문제는 "모든 것은 조치를 거쳐야 하는 작업 - 감속기 - 업데이트 구성 요소와 저장소 상태 루프"(저도 마찬가지입니다)에 갇히는 경향이 있고 모든 종류의 앱의 매우 특정한 시나리오에서만 사용되는 상태(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 호출을 수행하는 함수입니다.

따라서 스토어/리듀서로의 왕복이 없고, 하나의 구성 요소 내부에서만 관심이 있는 항목으로 전역 상태를 오염시키지 않으며 순전히 해당 구성 요소의 상태를 일시적으로 표시하는 데 사용되며, 감속기 내부의 여러 상태 변수를 재설정할 필요가 없습니다.

렌더링은 다음과 같습니다.

  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 항목에 연결할 기회를 유지해야 하는 경우 일반 흐름에서 상태를 수정하는 작업을 허용합니다.

앱 상태를 이미 로그인한 상태로 생각하는 것이 좋습니다. 로그인한 사용자가 없으면 앱 상태가 필요한 이유는 무엇입니까? 물론 로그인 구성 요소 내부에 하나를 가질 수 있습니다.

로그인 페이지의 앱 로직은 앱 상단 상태를 소유하기 위해 그렇게 복잡하지 않아야 합니다. 맞나요?

@SkateFreak 로그인 흐름은 앱의 일부입니다. React를 사용하는 것이 더 좋은 로그인 흐름 상태(진행률, 오류), 가입 흐름 상태 등을 생각하지 않았습니까(다른 앱 구성 요소에 이미 Redux를 사용 중인 경우 Redux와 함께 사용).

@sompylasar 저는 앱 상태에 찬성합니다. 사용자가 내 앱 외부에 있는 한 redux 스토어 없이 더 간단한 앱을 제공할 수 있다고 생각합니다. 내 앱을 입력하자마자 내 redux 스토어가 시작됩니다.

이 접근 방식은 지금 이 순간까지 저에게 효과가 있었지만 아마도 향후 프로젝트에서 로그인 단계 앱 상태의 필요성을 이해할 것입니다.

스토어의 루트 수준에서 스토어를 'app' 부분과 'user/login' 부분으로 분할할 수 있으며, 각각은 자체 리듀서를 사용합니다. 따라서 이 경우 로그인 감속기 코드로 앱 감속기를 오염시키지 않으며 그 반대의 경우도 마찬가지입니다.

보낸 사람: SkateFreak < 알림 @github.com 알림 @github.com >
답장: rackt/redux < [email protected] [email protected] >
날짜: 2015년 12월 13일 일요일 13:48
받는 사람: rackt/redux < [email protected] [email protected] >
참조: 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에서 확인하세요.

잘못된 경우 나를 수정하지만 경로와 구성 요소 간에 데이터와 앱 상태를 공유하는 플럭스 저장소의 목적이 아닌가요? 사용자가 로그인할 때 모든 것이 중요하지 않다면 왜 내 상태를 "축소"하고 최상위 상태를 유지하기 위해 "작업"을 사용해야 합니까?

나는 그것이 일을하는 매우 조직적이고 깨끗한 방법이지만 이점을 보지 못합니다. SignIn, SignUp 및 ForgotPassword가 포함된 <Sign /> 구성 요소에서 사전 로그인 상태를 관리합니다.

가입은 사용자 이름과 비밀번호를 묻는 것보다 더 복잡한 프로세스일 수 있기 때문입니다.
그것은 모두 흐름의 복잡성에 달려 있습니다.

보낸 사람: SkateFreak < 알림 @github.com 알림 @github.com >
답장: rackt/redux < [email protected] [email protected] >
날짜: 2015년 12월 13일 일요일 14:00
받는 사람: rackt/redux < [email protected] [email protected] >
참조: Joris Mans < [email protected] [email protected] >
제목: Re: [redux] 리디렉션이 있는 로그인/가입 페이지의 데이터 흐름 처리에 대한 모범 사례(#297)

잘못된 경우 나를 수정하지만 경로와 구성 요소 간에 데이터와 앱 상태를 공유하는 플럭스 저장소의 목적이 아닌가요? 사용자가 로그인할 때 모든 것이 중요하지 않다면 왜 내 상태를 "축소"하고 최상위 상태를 유지하기 위해 "작업"을 사용해야 합니까?

나는 그것이 일을하는 매우 조직적이고 깨끗한 방법이지만 이점을 보지 못합니다. SignIn, SignUp 및 ForgotPassword가 포함된 구성 요소에서 사전 로그인 상태를 관리합니다.

이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/rackt/redux/issues/297#issuecomment -164287893에서 확인하세요.

동의한다.
하지만 SignUp을 상태가 있는 양식으로 봅니다. 아무리 복잡해도 충분해야 합니다...

반면에 가입에 대해 무엇을 알고 있습니까?
사람들이 미쳤다

현재 나는 비슷하지만 다른 문제를 만났습니다.

저는 매우 복잡한 가입과 같은 흐름을 작업 중이며 사용자가 필수 정보를 입력할 수 있도록 하는 몇 가지 계속 페이지가 있습니다. 각 페이지는 양식입니다. 흐름은 다음과 같습니다.

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

제안해 주셔서 감사합니다.
우리 모두는 이러한 일시적인 것들을 애플리케이션 상태로 만들고 싶지 않은 것 같습니다.

그러나 사용자가 흐름의 절반에서 페이지를 새로 고칠 때

사용자가 페이지를 다시 로드하기로 결정하면 처음부터 다시 시작해야 합니다.

그것은 좋은 사용자 경험이 아닌 것 같습니다. 우리는 모바일 사이트입니다(큰 양식을 작은 페이지로 나누는 이유 중 하나입니다). 모바일에서 입력하는 것이 고통스럽고 모든 것을 잃으면 사용자가 화를 낼 것이라고 믿습니다. 새로 고침 버튼을 누른 후에는 그냥 포기할 수도 있습니다.

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 흐름의 무언가를 추가하는 것이 이상해 보입니다.

나는 사용자가 귀하의 페이지를 새로고침하는 것에 대해 정말로 신경쓰지 않을 것입니다.
다른 한편으로는 여러 양식이 있는 복잡한 가입 절차가 있다고 말하면서 모바일 사이트라고 말합니다. 또한 사용자를 화나게 만들고 모바일 장치에서 너무 많은 항목을 작성해야 하는 경우 포기하게 만들 것이라고 생각하지 않습니까? 리로드를 지원하지 않는 것보다 더 나쁘다고 생각합니다. 어쨌든 많은 사이트가 가입 과정 중에 페이지 새로고침을 지원하지 않는다고 생각합니다.

나는 그것이 실제로 많이 일어나지 않는 일을 훨씬 더 복잡하게 만들고 있다고 생각합니다. 저는 가입 절차를 단순화하거나 웹사이트에서 여러 단계로 분할하여 사용자가 마침내 계정을 활성화하기 전에 X 페이지의 양식을 작성하고 있다는 인상을 주지 않도록 하는 데 더 집중할 것입니다.

그리고 실제로 가입 중간 재로드를 지원하려면 이러한 모든 단계를 제어하는 ​​상위 구성 요소가 상태를 localStorage 에 저장하도록 하세요.

@kpaxqin "가짜 API" 접근 방식을 사용합니다. 왜 가짜 BTW인지, 다단계 프로세스에 필요한 중간 저장소 API일 뿐입니다. 모든 API가 반드시 서버에 있어야 하는 것은 아니며 HTTP 또는 기타 네트워킹 프로토콜을 통해 액세스해야 합니다.

@ir-fuel에 동의하는 것은 현재 단계뿐만 아니라 모든 다단계 프로세스 상태가 저장되어야 한다는 것입니다.

@ir-fuel Reload는 명시적인 사용자 의도 없이 발생할 수 있습니다. 예를 들어 사용자가 노트북이나 전화 통화와 같은 다른 모바일 앱으로 전환할 수 있으며 기기의 메모리 부족으로 인해 브라우저가 상태를 잃을 수 있으므로 사용자가 돌아올 때 다시 로드됩니다.

문제는 웹 애플리케이션의 몇 화면에서만 필요한 것으로 글로벌 애플리케이션 상태를 오염시키고 있다는 것입니다.

@sompylasar @kpaxqin 저는 @ir-fuel이 올바른 접근 방식을 제안했다고 생각합니다. 결국 지속되어야 하는 중간이 필요한 경우 클라이언트 측에서 유지하십시오. 구현하기가 훨씬 쉽고 서버가 일관되지 않은 데이터를 유지하는 데 실제로 관여하지 않습니다. t 모든 http 요청(모바일 장치의 주요 문제이기도 함)을 수행하고 향후 접근 방식을 매우 쉽게 변경할 수 있습니다.

그리고 데이터를 어딘가에 유지하는 것(프로세스가 실패했거나 이미 완료된 후 어떻게 정리할 것인지 생각하십시오)이 주제의 초기 주제였습니다.
사용할 수 있는 또 다른 옵션은 URL에 사용자 데이터를 유지하는 것입니다. 양식이 좋은 절충안이 될 수 있는 몇 개의 텍스트 필드로 구성된 경우.

그것은 "클라이언트 또는 서버 측에 저장"하는 것이 아니라 "부모 구성 요소 클래스에서 이 '임시'를 처리합니까?" 대 "전체 작업/리듀서/상태 댄스를 수행합니까?"의 문제입니다.
임시 상태인 경우 액션/리듀서를 통과하는 것을 좋아하지 않습니다. 나는 실제 애플리케이션 상태에 대해서만 이 작업을 수행합니다.

@ir-연료 :+1:

@tremlenye 내 답변을 다시 읽으십시오. 지속성 API 계층을 만들기 위해 서버 측 API를 만들 필요가 없다고 명시적으로 말합니다.

@ir-fuel action/reducer를 거치지 않으면 상태 전환의 예측 가능성과 재생 가능성이 취소됩니다.

@ir-fuel 양식이 제출된 후 앱 상태를 쉽게 지울 수 있으므로 "오염"되지 않습니다.

RE: 클리어. 작업을 취소하고 UI에 버튼을 사용하여 가입 흐름을 재설정합니다. 라우터를 통해서도 만들 수 있습니다(초기 가입 URL을 방문할 때 해당 작업을 전달하고 가입이 시작된 경우 URL을 다른 것으로 변경).

@sompylasar 명시적 버튼으로 상태를 재설정하는 데 문제가 없습니다. 처리되지 않은 오류 후에 문제가 발생합니다. 상태가 손상될 수 있는 방법을 예측하고 각각의 특정 경우에 대한 복원 전략을 정의하기 어렵습니다.

@stremlenye 예, 소프트웨어 엔지니어링은 때때로 어렵습니다. 예측 가능한 상태와 전환은 이를 완화하는 데 도움이 됩니다.

뿐만 아니라 상태가 json 객체의 무리 이상이고(모든 것이 관례에 따라 적용되고 아무 것도 적용되지 않기 때문에 싫어합니다) Immutable.js의 Record 라인에서 무언가를 사용하면 객체의 속성을 미리 선언해야 하며 여기에는 원하는 모든 임시 항목이 포함됩니다.

저에게 Immutable.js를 사용하지 않고 redux로 무언가를 구축하는 것은 단지 사고가 일어나기를 기다리고 있는 것입니다.

Signup 레코드를 만들고 등록할 때만 null이 아닌 상태로 만들 수 있다는 것을 알고 있습니다. 나.

@ir-연료

뿐만 아니라 상태가 json 객체의 무리 이상이고(모든 것이 관례에 따라 적용되고 아무 것도 적용되지 않기 때문에 싫어합니다) Immutable.js의 레코드 라인에서 무언가를 사용하는 경우 속성을 선언해야 합니다. 당신이 원하는 모든 임시 물건이 포함되어 있습니다.

저에게 Immutable.js를 사용하지 않고 redux로 무언가를 구축하는 것은 단지 사고가 일어나기를 기다리고 있는 것입니다.

현재로서는 Redux와 함께 Immutable.js를 사용하는 것에 대해 확신이 서지 않습니다. 통합하기에는 너무 복잡해 보였고 성능도 좋지 않았습니다. 개발 및 테스트 중 딥 프리즈(deep-freeze)와 테스트 세트는 대부분의 경우를 처리하기에 충분해야 합니다. 그리고 리듀서나 참조가 있는 다른 장소에서 상태 변경을 피하기 위한 엄격한 규칙입니다.

가입 기록을 만들 수 있고 가입할 때만 null이 아닌 것으로 알고 있습니다.

네, 그렇게 생각했습니다.

하지만 문제는 더 근본적입니다. 웹 앱에 이러한 경우가 많이 있을 수 있고 그게 저를 괴롭히기 때문입니다.

이것이 우리가 명시적 애플리케이션 상태라고 부르는 것입니다. 매 순간 많은 구성요소로 구성된 앱의 상태를 알고 있습니다. 상태 구조를 덜 명시적이고 더 동적으로 만들고 싶다면 https://github.com/tonyhb/redux-ui 를 따르십시오.

이것이 JS 개발의 전체 문제입니다. "관례를 지키자". 이것이 사람들이 복잡한 환경에서 작동하지 않는다는 것을 깨닫기 시작하는 이유입니다. 사람들은 실수를 하고 TypeScript 및 Immutable.js와 같은 솔루션을 제공하기 때문입니다.

통합하는 것이 왜 너무 복잡할까요? '기록'을 사용하는 경우 해당 모든 객체(읽기만 하는 한)를 일반 JS 객체로 사용하고 속성에 액세스하기 위해 점 표기법을 사용하여 어떤 속성이 객체의 일부인지 미리 선언할 수 있다는 이점이 있습니다. .

Immutable.js를 사용하여 모든 redux 개발을 아무런 문제 없이 수행하고 있습니다. 단순히 우연히 객체를 수정할 수 없다는 사실은 redux의 큰 장점이며 객체 프로토타입을 정의하는 '유형 안전성'도 편리합니다.

그리고 정말로 가입 중간 재로드를 지원하려면 이러한 모든 단계를 제어하는 ​​상위 구성 요소가 해당 상태를 localStorage에 저장하도록 하세요.

@ir-연료
나에게 localStorage에 물건을 넣는 것은 부작용처럼 보이며 구성 요소에서 수행하는 것은 좋은 방법이 아닌 것 같습니다.

문제는 웹 애플리케이션의 몇 화면에서만 필요한 것으로 글로벌 애플리케이션 상태를 오염시키고 있다는 것입니다.

아마도 내가 가짜 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 명시적 버튼으로 상태를 재설정하는 데 문제가 없습니다. 처리되지 않은 오류 후에 문제가 발생합니다. 상태가 손상될 수 있는 방법을 예측하고 각각의 특정 경우에 대한 복원 전략을 정의하기 어렵습니다.

@tremlenye 저도 그 점에 동의합니다. 하지만 이러한 특정 실패 사례는 비즈니스 문제일 가능성이 더 높다고 생각합니다. 상태를 어디에 두든 상관없이 항상 여기에 있으며 적절한 방식으로 처리되어야 하지만 충분히 명확하게 설명되지는 않았습니다. 순간. 개발자가 할 수 있는 유일한 일은 추적을 쉽게 만들어 우리가 덜 고통스럽게 고칠 수 있도록 하는 것입니다.

그리고 부모 구성 요소에 상태를 넣으면 상황이 복잡해질 때 추론하기가 더 어려워질 수 있습니다. 가짜 API를 사용하면 해당 상태를 작업으로 변경하고 더 예측 가능하게 보입니다.

그러나 나는 가짜 API가 덜 복잡하고 대부분의 경우에 너무 무거워 보인다는 데 동의합니다.

위의 모든 메시지를 거치지 않았습니다. 여기서는 componentWillReceiveProps에서 소품 변경을 감지하는 방법을 제시합니다.

상태 형태가 { loginPending, loginError }라고 가정하고 로그인을 시작할 때 loginPending = true로 설정합니다. 성공 또는 실패 시 { loginPending: false, loginError: 'some error.'를 설정합니다. }.

그런 다음 구성 요소에서 로그인 성공 이벤트가 있는지 감지하고 페이지를 리디렉션할 수 있습니다.

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 로 코드를 수정했으며 이 설탕은 요청의 세 가지 상태(before, in progress, after)가 있다는 사실을 숨깁니다. 이러한 상태는 보기 구성 요소에서 숨겨집니다. 요청 시작은 무시되고 요청 오류는 보기에서 처리되고 redux를 통해 전달되지 않으므로 여기에서 앱 상태는 비즈니스가 아닙니다. 어떤 이유로 이 상태를 포함하는 구성 요소가 마운트 해제되었다가 다시 마운트되면 등록 요청 상태가 손실되고 그 결과가 처리되지 않아 후속 오류가 발생할 수 있습니다(예: 사용자가 이미 등록됨).

사용자에게 오류가 발생한 다음 다른 페이지로 이동한 다음 다시 양식 페이지로 이동합니다. 양식이 비어 있고 오류가 없습니다.

이를 달성하기 위해 저장소에서 오류를 재설정하는 USER_REGISTRATION_RESET 와 같은 작업을 구성 요소 마운트에 전달할 수 있습니다. 이 작업은 보류 중인 등록 요청이 없는 경우에만 처리되어야 합니다. 그렇지 않으면 보류 중인 요청 결과가 앱에서 처리되지 않습니다.

피드백에 감사드립니다.

async / await를 사용하여 코드에 추가했으며 이 설탕은 요청의 세 가지 상태(before, in progress, after)가 있다는 사실을 숨깁니다.

이러한 조건은 내가 async/await를 사용하는지 여부에 관계없이 존재합니다.

이러한 상태는 보기 구성 요소에서 숨겨집니다.

의도한 대로 구성 요소 상태입니다. 왜 이것이 앱 상태여야 합니까?

요청 시작이 무시됩니다.

진행 중...

요청 오류는 보기에서 처리되고 redux를 통해 전달되지 않습니다.

의도 한대로

어떤 이유로 이 상태를 포함하는 구성 요소가 마운트 해제되었다가 다시 마운트되면 등록 요청 상태가 손실되고 그 결과가 처리되지 않습니다.

그것은 사실이 아닙니다. 구성 요소 상태 또는 존재 여부에 관계없이 요청이 성공하면 사용자가 등록되고 리디렉션됩니다. register 액션 생성기(handleData)를 보십시오.

이를 달성하기 위해 작업을 전달할 수 있습니다 ...

그것이 핵심이야. 또 다른 행동? 왜 그렇게 많은 상용구? 제출 버튼을 비활성화 또는 활성화하고, 양식 오류 또는 실시간 유효성 검사를 표시하고, 요청이 열려 있는 동안 스피너를 표시합니다. 이러한 작업은 기본 상태를 복원하는 새로운 작업으로 이어집니다. 왜 이것이 앱 상태여야 합니까?

그것은 사실이 아닙니다. 구성 요소 상태 또는 존재 여부에 관계없이 요청이 성공하면 사용자가 등록되고 리디렉션됩니다. 레지스터 액션 생성자(handleData)를 살펴보세요.

예, 하지만 요청 상태가 애플리케이션 상태에서 추적되지 않기 때문에 두 개의 후속 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?
미들웨어의 react-router-redux push 를 사용하여 리디렉션 URL을 작업으로 전달하고 next 메서드를 추가로 호출합니다.