Redux: रीडायरेक्ट के साथ लॉगिन/साइनअप पृष्ठों के लिए डेटा प्रवाह को संभालने का सर्वोत्तम अभ्यास

वहां shouldRedirect होने के बजाय, सत्र रेड्यूसर होने के बारे में, जो सिर्फ isLoggedIn ट्रैक करता है? इस तरह आप $#$ shouldRedirect $#$ के बजाय isLoggedIn चेक करके अपने लॉगिन पेज से किसी अन्य पेज पर रीडायरेक्ट कर सकते हैं।

साथ ही, आपके रिड्यूसर में केवल LOGGED_IN कार्रवाई को संसाधित करके राज्य को रीसेट किया जा सकता है। यदि वह क्रिया होती है तो आप जानते हैं कि आप त्रुटि स्थिति को null मान पर सुरक्षित रूप से रीसेट कर सकते हैं।

इसका कोई मतलब भी है क्या? :डी

यह समझ में आता है कि केवल लॉगिन पृष्ठ है, लेकिन यह थोड़ा अधिक सामान्य दृष्टिकोण है। उदाहरण के लिए साइनअप पेज या पासवर्ड रीसेट पेज के लिए। भले ही आप लॉग इन हों, फिर भी आप उन पेजों को देख पाएंगे।

और उन झंडों का उपयोग उन सभी पृष्ठों द्वारा किया जाना चाहिए, क्योंकि उन सभी का प्रवाह समान है।

आशा है कि यह अब और स्पष्ट है :)

हाँ, मेरे दृष्टिकोण से "चाहिए रीडायरेक्ट" एक निश्चित क्रिया से जुड़े होने के लिए बहुत सामान्य है। यह बग खोल सकता है जहां आप किसी भी तरह उस ध्वज को सेट करना भूल जाते हैं और फिर एक पृष्ठ दूसरे पृष्ठ पर रीडायरेक्ट करता है जिस पर उसे वास्तव में रीडायरेक्ट नहीं करना चाहिए।

लेकिन निश्चित रूप से, यदि आप अपने राज्य को साफ करना चाहते हैं, तो आप केवल एक क्रिया के साथ ऐसा कर सकते हैं। या आप प्रतिक्रिया के बाहर इतिहास परिवर्तन सुन सकते हैं और फिर राज्य-समाशोधन कार्रवाई को ट्रिगर कर सकते हैं। यह बेहतर हो सकता है क्योंकि आपको उस तर्क को अपने घटकों में बिखेरने की ज़रूरत नहीं है, लेकिन आप इसे एक ही स्थान पर रख सकते हैं।

लेकिन यह केवल राज्य समाशोधन के लिए एक संभावित समाधान है। मुझे अभी तक यकीन नहीं है कि पुनर्निर्देशन को एक अच्छे तरीके से कैसे हल किया जाए।

सवाल यह भी है कि क्या उन झंडों को राज्य में रखने का कोई मतलब है? यदि नहीं, तो इस प्रवाह को कैसे लागू किया जाना चाहिए?

@gaearon अगर आपके पास कुछ समय है तो मुझे आपकी प्रतिक्रिया भी सुनना अच्छा लगेगा। धन्यवाद! :+1:

मेरे आवेदन में मैं मिडलवेयर में रीडायरेक्ट कर रहा हूं और मैं किसी भी झंडे का उपयोग नहीं करता हूं। लेकिन मैं प्रतिक्रिया-राउटर का उपयोग नहीं कर रहा हूँ।

// 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);
    };
}

इसे दोबारा नहीं किया गया है, यह केवल मेरे राउटर समाधान के परीक्षण उद्देश्यों के लिए है :)।

यह मेरे एप्लिकेशन से एक कॉपी और पेस्ट है और मैं उपयोगकर्ता डेटा लोड करने और लॉग इन करने का तरीका कैसे संभालता हूं। मैं जितना संभव हो सके कोड पर टिप्पणी करने का प्रयास करूंगा, और मैं प्रश्नों के लिए रिएक्टफ्लक्स पर रहूंगा।

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 #$ ।

मुझे लगता है कि आपके राज्य में चाहिए रीडायरेक्ट स्वीकार्य नहीं है, और इसे और अधिक कार्यात्मक दृष्टिकोण में किया जाना चाहिए

मैं सहमत हूं। चीजें जो केवल एक बार उपयोगी होती हैं वे आईएमओ राज्य में नहीं होनी चाहिए।

साथ ही, स्लैक के अनुसार, मुझे नहीं लगता कि आपको एप्लिकेशन स्थिति में isLoggedIn स्टोर करना चाहिए, क्योंकि यह वास्तव में एक गणना की गई संपत्ति है, जिसे const isUserLoggedIn = state => state.user.id !== null जैसे साधारण चयनकर्ता के साथ गणना की जा सकती है।

अधिक चयनकर्ता उपयोग के लिए https://github.com/faassen/reselect देखें

उदाहरण के लिए @frederickfogerty धन्यवाद।

प्रश्न हालांकि: यह लॉगिन के लिए ठीक काम करता है क्योंकि आपके पास आमतौर पर $#$ state $#$ में loggedIn ध्वज होता है। लेकिन अन्य पृष्ठों जैसे साइनअप, पासवर्ड-रीसेट, आदि के बारे में क्या?
वे पृष्ठ लॉगिन के समान व्यवहार करते हैं: ठीक होने पर रीडायरेक्ट करें, अन्यथा त्रुटि संदेश दिखाएं।
तो आप उन मामलों को कैसे हैंडल करते हैं? मैं उन मामलों के लिए सही प्रवाह खोजने के लिए संघर्ष कर रहा हूं, और मुझे यकीन नहीं है कि राज्य को कहाँ रहना चाहिए।

चीजें जो केवल एक बार उपयोगी होती हैं वे आईएमओ राज्य में नहीं होनी चाहिए।

@gaearon मैं सहमत हूं, लेकिन मुझे अभी भी यकीन नहीं है कि इसके लिए सही दृष्टिकोण क्या है। आपको अभी भी कहीं एक राज्य की आवश्यकता है ...

इस तरह मैं राज्य में कुछ भी स्टोर किए बिना इसे एटीएम कर रहा हूं।

// 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 में निम्नलिखित उदाहरण को फिर से लागू करने का प्रयास कर रहा हूं। अभी तक कुछ भी दिखाने योग्य नहीं है क्योंकि मैं इसे अपने खाली समय में कर रहा हूं:
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 घटक के कनेक्टर में डाल दें।

इस तरह मैं राज्य में कुछ भी स्टोर किए बिना इसे एटीएम कर रहा हूं।

मुझे निश्चित रूप से वह दृष्टिकोण पसंद नहीं है, जिसमें यूआई और एसी के बीच दो तरह से डेटा प्रवाह होता है, जो प्रवाह के खिलाफ जाता है। यदि आप इसे अनिवार्य रूप से करने के लिए बाध्य हैं, तो आप कुछ ऐसा कर सकते हैं

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 पृष्ठ है। हम यह भी मानते हैं कि हमें किसी भी तरह के एक-शॉट झंडे (जैसा कि पहले उल्लेख किया गया है) को संग्रहीत करके किसी भी राज्य को नहीं छूना चाहिए।
जब मैं फॉर्म जमा करने के लिए क्लिक करता हूं, तो क्या होना चाहिए?

यही मैं जानना चाहता हूं कि प्रवाह कैसा होना चाहिए और कहां रहना चाहिए।

पीएस: अब तक आपकी प्रतिक्रिया के लिए धन्यवाद!

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

तो हमें कुछ राज्य मिला जो आवेदन राज्य से जुड़ा नहीं है और कोई भी इसकी परवाह नहीं करता है। जब हम अगली बार इस फॉर्म पर दोबारा गौर करेंगे तो यह मिटा हुआ दिखाया जाएगा और 'जॉन स्नो' हमेशा के लिए चला जाएगा।
ऐसा लगता है कि हमने फ्लक्स डेटा प्रवाह को छुए बिना 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>
    )
  }
}

जब उपयोगकर्ता सबमिट बटन दबाता है तो वह यूआई से किसी भी प्रतिक्रिया की अपेक्षा करता है कि यह सफल नहीं था और आगे क्या करना है। इसलिए हम लोडिंग स्क्रीन, रीडायरेक्ट या त्रुटि संदेश दिखाने के लिए अनुरोध स्थिति को ट्रैक करना चाहते हैं।
पहला विचार कुछ आंतरिक क्रियाओं को भेजना है जैसे 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 वह बहुत चालाक है। साझा करने के लिए धन्यवाद!

पढ़ने के लिए @iclanzan thx :)
दरअसल अब मैं @gaearon प्रस्ताव के बारे में सोच रहा हूं जिसका उन्होंने पिछली टिप्पणी में उल्लेख किया था। कुछ महत्वपूर्ण विचार प्राप्त करने के लिए #159 चर्चा पर एक नज़र डालें।

समापन - जब आरआर 1.0 सामने आएगा, तो हम इसे "यूसेज विद रिएक्ट राउटर" रेसिपी में शामिल करेंगे।
इसे https://github.com/rackt/redux/issues/637 में ट्रैक किया जा सकता है।

@stremlenye आपका दृष्टिकोण बहुत बढ़िया है! क्या यह समझ में आता है - एक डेकोरेटर का उपयोग करने के बजाय - एक प्रतिक्रिया-राउटर उच्च क्रम घटक का उपयोग करें जिसमें सभी _unathorized_ नेस्टेड होंगे और एक बार जब स्टोर में उपयोगकर्ता होगा तो यह रीडायरेक्ट करने के लिए ज़िम्मेदार होगा?

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

कुछ इस तरह, जहां Auth केवल यह पता लगाने का ख्याल रखता है कि उपयोगकर्ता लॉग इन है या नहीं। इस तरह, मुझे अभी भी Login घटक से कार्रवाइयां भेजकर अपने स्टोर में हेरफेर करना पड़ता है। इतना शुद्ध नहीं, लेकिन कम कोड और मेरे सिर को पाने में आसान :)

@tomazzaman धन्यवाद :)
मेरे द्वारा लिखे गए अधिकांश रिएक्ट एप्लिकेशन में ApplicationContainer जैसे कुछ शामिल हैं जिनका उपयोग नए Route कार्यान्वयन के बिना उसी उद्देश्य के लिए किया जा सकता है।
यदि आप RR-v1.0.0-rc1 का उपयोग कर रहे हैं तो आप onEnter हुक के साथ समान लक्ष्यों तक पहुंच सकते हैं: बस जांचें कि वर्तमान स्थिति प्रमाणित से मेल खाती है या नहीं।

मैं इसके चारों ओर अपना सिर भी लपेट रहा हूं, और ऐसा लगता है कि @stremlenye ने बहुत अच्छा काम किया है कि यह कैसे किया जा सकता है। समस्या यह है कि एक "सब कुछ कार्रवाई के माध्यम से जाने की जरूरत है - रेड्यूसर - अपडेट-घटक-साथ-स्टोर-स्टेट लूप" (मुझे भी) में फंस जाता है और फिर हम सभी प्रकार के साथ स्टोर को प्रदूषित करते हैं राज्य जो केवल ऐप में बहुत विशिष्ट परिदृश्यों में उपयोग किया जाता है (1 स्क्रीन पर, सामान जैसे "क्या मैंने सफलतापूर्वक रीसेट पासवर्ड निष्पादित किया"), जबकि इसे आसानी से घटक के अंदर एसिंक कॉल करके और घटक को अपडेट करके आसानी से संभाला जा सकता है वैश्विक स्थिति को प्रदूषित करने के बजाय this.setState का उपयोग करना + यदि हम उस घटक को दूसरी बार बाद में खोलना चाहते हैं तो उन सभी राज्य संस्करणों को रीसेट करना होगा। सभी शुरुआत/सफलता/त्रुटि प्रबंधन कोड के साथ राज्य रेड्यूसर को प्रदूषित करने का भी जिक्र नहीं है।

यह देखने के लिए कि क्या यह चीजों को साफ करता है, मेरे कोड को यहां भी अनुकूलित करने का प्रयास करेगा।

@ आईआर-ईंधन अगर आपके पास समय होगा तो क्या आप जीथब को प्राप्त करने के एक छोटे से उदाहरण को आगे बढ़ा सकते हैं?

वैसे ऐसा करना कठिन होगा, लेकिन मैंने जो किया उसका मैं एक छोटा सा उदाहरण दे सकता हूं। मेरे पास एक घटक है जहां कोई उपयोगकर्ता अपना पासवर्ड रीसेट करने के लिए कह सकता है। वास्तविक रीसेट ऑपरेशन अब इस तरह होता है:

  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 एक ऐसा फ़ंक्शन है जो मेरे सर्वर पर अजाक्स कॉल करता है।

तो स्टोर/रेड्यूसर के लिए कोई राउंडट्रिप नहीं, वैश्विक स्थिति को प्रदूषित करने वाले सामानों के साथ आप केवल एक घटक के अंदर की देखभाल करते हैं और पूरी तरह से उस घटक में राज्य को अस्थायी रूप से दिखाने के लिए उपयोग किया जाता है, और आपके रेड्यूसर के अंदर राज्य वार्स का एक गुच्छा रीसेट करने की आवश्यकता नहीं होती है।

और रेंडर कुछ इस तरह दिखता है

  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 लॉगिन प्रवाह एक ऐप का एक हिस्सा है। क्या आपने एक लॉगिन फ्लो स्टेट (प्रगति, त्रुटि), साइनअप फ्लो स्टेट आदि के बारे में नहीं सोचा था, जिसके लिए आप रिएक्ट का बेहतर उपयोग करेंगे (संभवतः Redux के साथ, यदि आप इसे पहले से ही अन्य ऐप घटकों के लिए उपयोग कर रहे हैं)।

@sompylasar मैं एक ऐप स्थिति के पक्ष में हूं, मुझे लगता है कि जब तक उपयोगकर्ता मेरे ऐप के बाहर है, मैं उसे एक रेडक्स स्टोर के बिना एक सरल ऐप की सेवा कर सकता हूं। जैसे ही आप मेरा ऐप दर्ज करेंगे मेरा रेडक्स स्टोर चालू हो जाएगा।

इस दृष्टिकोण ने मेरे लिए इस क्षण तक काम किया, लेकिन शायद मैं अपनी भविष्य की परियोजनाओं में लॉगिन-चरण ऐप स्थिति की आवश्यकता को समझूंगा

आप अपने स्टोर के मूल स्तर पर अपने स्टोर को 'ऐप' भाग और 'उपयोगकर्ता/लॉगिन' भाग में विभाजित कर सकते हैं, प्रत्येक अपने स्वयं के रेड्यूसर के साथ। तो उस स्थिति में आप अपने ऐप रेड्यूसर को लॉगिन रेड्यूसर कोड और इसके विपरीत कभी भी प्रदूषित नहीं करेंगे।

से: स्केटफ्रीक < सूचनाएं @github.com सूचनाएं @github.com>
उत्तर-प्रति: रैकेट/रेडक्स <उत्तर@ reply.github.com [email protected] >
दिनांक: रविवार 13 दिसंबर 2015 13:48
प्रति: रैक्ट/रेडक्स < [email protected] [email protected] >
सीसी: जोरिस मैन्स < [email protected] [email protected] >
विषय: पुन: [रेडक्स] रीडायरेक्ट के साथ लॉगिन/साइनअप पृष्ठों के लिए डेटा प्रवाह को संभालने पर सर्वोत्तम अभ्यास (#297)

@sompyl asarhttps://github.com/sompylasar मैं एक ऐप स्थिति के पक्ष में हूं, मुझे लगता है कि जब तक उपयोग मेरे ऐप के बाहर है, मैं उसे एक रेडक्स स्टोर के बिना एक सरल ऐप की सेवा कर सकता हूं। जैसे ही आप मेरा ऐप दर्ज करेंगे मेरा रेडक्स स्टोर चालू हो जाएगा।

इस दृष्टिकोण ने मेरे लिए इस क्षण तक काम किया, लेकिन शायद मैं अपनी भविष्य की परियोजनाओं में लॉगिन-चरण ऐप स्थिति की आवश्यकता को समझूंगा

इस ईमेल का सीधे उत्तर दें या इसे Gi tHubhttps: //github.com/rackt/redux/issues/297#issuecomment -164287194 पर देखें।

अगर मैं गलत हूं तो मुझे सही करें, लेकिन मार्गों और घटकों के बीच डेटा और ऐप-स्टेट साझा करने के लिए फ्लक्स स्टोर का उद्देश्य नहीं है? मुझे अपने राज्य को "कम" करने और शीर्ष-स्थिति बनाए रखने के लिए अपने "कार्यों" का उपयोग करने की आवश्यकता क्यों है यदि उपयोगकर्ता साइन इन करते समय इससे कोई फर्क नहीं पड़ता?

मैं फायदे नहीं देखता, हालांकि यह चीजों को करने का एक बहुत ही व्यवस्थित और साफ तरीका है। मैं अपने <Sign /> घटक पर अपनी पूर्व-लॉगिन स्थिति का प्रबंधन करता हूं, जिसमें साइनइन, साइनअप और फॉरगॉटपासवर्ड शामिल है।

क्योंकि साइनअप एक उपयोगकर्ता नाम और पासवर्ड मांगने की तुलना में अधिक जटिल प्रक्रिया हो सकती है।
यह सब आपके प्रवाह की जटिलता पर निर्भर करता है।

से: स्केटफ्रीक < सूचनाएं @github.com सूचनाएं @github.com>
उत्तर-प्रति: रैकेट/रेडक्स <उत्तर@ reply.github.com [email protected] >
दिनांक: रविवार 13 दिसंबर 2015 14:00
प्रति: रैक्ट/रेडक्स < [email protected] [email protected] >
सीसी: जोरिस मैन्स < [email protected] [email protected] >
विषय: पुन: [रेडक्स] रीडायरेक्ट के साथ लॉगिन/साइनअप पृष्ठों के लिए डेटा प्रवाह को संभालने पर सर्वोत्तम अभ्यास (#297)

अगर मैं गलत हूं तो मुझे सही करें, लेकिन मार्गों और घटकों के बीच डेटा और ऐप-स्टेट साझा करने के लिए फ्लक्स स्टोर का उद्देश्य नहीं है? मुझे अपने राज्य को "कम" करने और शीर्ष-स्थिति बनाए रखने के लिए अपने "कार्यों" का उपयोग करने की आवश्यकता क्यों है यदि उपयोगकर्ता साइन इन करते समय इससे कोई फर्क नहीं पड़ता?

मैं फायदे नहीं देखता, हालांकि यह चीजों को करने का एक बहुत ही व्यवस्थित और साफ तरीका है। मैं अपने घटक पर अपनी पूर्व-लॉगिन स्थिति का प्रबंधन करता हूं, जिसमें साइनइन, साइनअप और भूल गए पासवर्ड शामिल हैं।

इस ईमेल का सीधे उत्तर दें या इसे Gi tHubhttps: //github.com/rackt/redux/issues/297#issuecomment -164287893 पर देखें।

मैं सहमत हूं।
लेकिन मैं साइनअप को एक रूप के रूप में देखता हूं, एक राज्य के साथ - जो पर्याप्त होना चाहिए चाहे कितना भी जटिल हो ...

दूसरी ओर, मुझे साइन अप के बारे में क्या पता...
लोग पागल हैं

वर्तमान में मैं कुछ समान लेकिन अलग समस्या से मिला हूं।

मैं एक सुपर कॉम्प्लेक्स साइन अप की तरह प्रवाह पर काम कर रहा हूं, और हमारे पास कुछ जारी पृष्ठ हैं जो उपयोगकर्ता इनपुट को आवश्यक जानकारी देते हैं, प्रत्येक पृष्ठ एक फॉर्म है। प्रवाह की तरह दिखता है:

फॉर्मपेज_ए -> फॉर्मपेज_बी -> फॉर्मपेज_सी -> सक्सेसपेज

समस्या यह है कि हम FormPage_C से पहले कोई API अनुरोध नहीं करते हैं। हम केवल FormPage_A/B पर ब्राउज़र में डेटा सहेजते हैं और उन सभी को FormPage_C में API को भेजते हैं।

तो, सवाल यह है कि क्या हमें फॉर्मपेज_ए और फॉर्मपेज_बी के फॉर्म डेटा को एप्लिकेशन स्टेट में रखना चाहिए?

यदि हां, तो ऐसा लगता है कि हम कुछ अस्थायी डेटा सहेज रहे हैं जिसका UI पर एप्लिकेशन स्थिति में कोई प्रभाव नहीं पड़ता है। और चूंकि रेडक्स की एप्लिकेशन स्थिति मेमोरी में रहती है, क्या होगा जब उपयोगकर्ता फॉर्मपेज_बी में पेज रीफ्रेश करता है?

यदि नहीं, तो क्या इसे लगाने का सही स्थान है? क्या हमें इसे बचाने के लिए रेडक्स फ्लो से fake api जैसी दूसरी परत बनानी चाहिए?

@frederickfogerty @gaearon @ir- food @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-ईंधन @stremlenye

आपके सुझावों के लिए धन्यवाद।
ऐसा लगता है कि हम सभी उन अस्थायी चीजों को लागू स्थिति में नहीं रखना चाहते हैं।

लेकिन जब उपयोगकर्ता आधे प्रवाह में पृष्ठ को ताज़ा करता है

बस यह सुनिश्चित करें कि यदि उपयोगकर्ता उस पृष्ठ को फिर से लोड करने का निर्णय लेता है जिसे आप फिर से शुरू करते हैं।

यह एक अच्छा उपयोगकर्ता अनुभव नहीं लगता है, हम एक मोबाइल साइट हैं (यही कारण है कि हम बड़े रूप को छोटे पृष्ठों में विभाजित करते हैं), मोबाइल पर चीजों को इनपुट करना दर्दनाक है, और मेरा मानना ​​​​है कि उपयोगकर्ता पागल हो जाएगा यदि वे सभी खो देते हैं रीफ्रेश बटन हिट करने के बाद चीजें, शायद वे इसे छोड़ देंगे।

मुझे लगता है कि शायद रेडक्स प्रवाह से fake api का निर्माण एक स्वीकार्य विकल्प है, प्रत्येक चरण पर चीजों को fake 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);
}

यह मेरे लिए चीजों को स्पष्ट करता है लेकिन हमारे ऐप में हमारे रेडक्स प्रवाह के कुछ जोड़ने के लिए यह अजीब लग रहा है।

मैं वास्तव में आपके पृष्ठ को पुनः लोड करने वाले उपयोगकर्ता की परवाह नहीं करता।
दूसरी तरफ, आप हमें बताते हैं कि आपके पास कई रूपों के साथ एक जटिल साइन अप प्रक्रिया है, और फिर आप कहते हैं कि यह एक मोबाइल साइट है। क्या आपको नहीं लगता कि यह उपयोगकर्ताओं को पागल कर देगा और अगर उन्हें मोबाइल डिवाइस पर बहुत सी चीजें भरनी हैं तो क्या उन्होंने हार मान ली है? मुझे लगता है कि यह पुनः लोड का समर्थन न करने से भी बदतर है। मुझे नहीं लगता कि कई साइटें साइनअप प्रक्रिया के बीच में पेज रीलोडिंग का समर्थन करती हैं।

मुझे लगता है कि यह सिर्फ चीजों को और अधिक जटिल बना रहा है जो वास्तव में बहुत कुछ नहीं होता है। मैं साइन अप प्रक्रिया को सरल बनाने की कोशिश पर अधिक ध्यान केंद्रित करूंगा, या इसे आपकी वेबसाइट पर कई चरणों में विभाजित करूंगा ताकि उपयोगकर्ता को यह आभास न हो कि वह अंततः अपने खाते को सक्रिय करने से पहले फॉर्म के एक्स पेज भर रहा है।

और यदि आप वास्तव में मध्य-साइनअप पुनः लोड का समर्थन करना चाहते हैं, तो बस इन सभी चरणों को नियंत्रित करने वाले मूल घटक को अपनी स्थिति localStorage में संग्रहीत करें।

@kpaxqin मैं "नकली एपीआई" दृष्टिकोण के साथ जाऊंगा। नकली बीटीडब्ल्यू क्यों, यह सिर्फ इंटरमीडिएट स्टोरेज एपीआई है जिसे आपको अपनी बहु-चरणीय प्रक्रिया के लिए चाहिए। जरूरी नहीं कि प्रत्येक एपीआई सर्वर पर हो और HTTP या अन्य नेटवर्किंग प्रोटोकॉल के माध्यम से एक्सेस किया गया हो।

मैं @ ir-ईंधन से सहमत हूं कि सभी बहु-चरण प्रक्रिया स्थिति को संग्रहीत किया जाना चाहिए, न कि केवल वर्तमान चरण।

@ ir-फ्यूल रीलोड स्पष्ट उपयोगकर्ता इरादे के बिना हो सकता है, उदाहरण के लिए, एक उपयोगकर्ता किसी अन्य मोबाइल ऐप पर स्विच कर सकता है, जैसे नोटबुक, या फोन कॉल, और डिवाइस पर अपर्याप्त मेमोरी के कारण ब्राउज़र अपनी स्थिति खो सकता है, इसलिए यह उपयोगकर्ता के वापस आने पर पुनः लोड हो जाएगा।

समस्या फिर से यह है कि आप वैश्विक एप्लिकेशन स्थिति को किसी ऐसी चीज से प्रदूषित कर रहे हैं जिसकी आपको केवल अपने वेबएप में कुछ स्क्रीन की आवश्यकता है।

@sompylasar @kpaxqin मुझे लगता है कि @ आईआर-ईंधन ने सही दृष्टिकोण का सुझाव दिया - यदि आपको अंततः जारी रखने के लिए कुछ मध्यवर्ती की आवश्यकता है, तो इसे क्लाइंट साइड पर जारी रखें: कार्यान्वित करने में बहुत आसान है, वास्तव में सर्वर को लगातार असंगत डेटा में शामिल नहीं करता है, ' किसी भी http अनुरोध को निष्पादित न करें (मोबाइल उपकरणों पर भी एक बड़ी समस्या क्या है) और भविष्य में दृष्टिकोण को बदलना बेहद आसान है।

और किसी भी डेटा को कहीं भी रखने के बारे में - सोचें कि प्रक्रिया विफल होने या पहले ही हो जाने के बाद आप इसे कैसे साफ करेंगे - यह एक विषय का प्रारंभिक विषय था।
एक अन्य विकल्प जिसका आप उपयोग कर सकते हैं - यूआरएल में उपयोगकर्ता डेटा जारी रखें। यदि आपके प्रपत्रों में कुछ टेक्स्ट फ़ील्ड शामिल हैं जो एक अच्छा ट्रेडऑफ़ समाधान हो सकता है।

यह इतना अधिक नहीं है "इसे क्लाइंट या सर्वर साइड स्टोर करें", यह "क्या मैं अपने मूल घटक वर्ग में इस 'तदर्थ' को संभालता हूं" बनाम "क्या मैं पूरी क्रिया/रेड्यूसर/राज्य नृत्य करता हूं"।
अगर यह अस्थायी स्थिति के लिए है तो मुझे एक्शन/रेड्यूसर से गुजरना पसंद नहीं है। मैं इसे केवल वास्तविक एप्लिकेशन स्थिति के लिए करता हूं।

@ आईआर-ईंधन: +1:

@stremlenye कृपया मेरा उत्तर दोबारा पढ़ें। मैं स्पष्ट रूप से कहता हूं कि आपको दृढ़ता API परत बनाने के लिए सर्वर-साइड API बनाने की आवश्यकता नहीं है।

@ ir-ईंधन क्रियाओं से नहीं गुजर रहा है/रेड्यूसर राज्य के संक्रमणों की भविष्यवाणी और पुन: प्रयोज्यता को रद्द कर देता है।

@ आईआर-ईंधन फॉर्म जमा होने के बाद आप आसानी से अपनी ऐप स्थिति साफ़ कर सकते हैं, इसलिए यह "प्रदूषित" नहीं होता है।

आरई: समाशोधन। साइन-अप प्रवाह को रीसेट करने के लिए एक क्रिया स्पष्ट करें और अपने UI में एक बटन रखें। आप इसे राउटर के माध्यम से भी बना सकते हैं (प्रारंभिक साइनअप यूआरएल पर जाकर उस क्रिया को भेज दें, और अगर साइनअप शुरू हो गया है, तो यूआरएल को किसी और चीज़ में बदल दें)।

@sompylasar आपके राज्य को एक स्पष्ट बटन के साथ रीसेट करने में कोई समस्या नहीं है - अनहेल्ड विफलताओं के बाद समस्याएं होती हैं: यह भविष्यवाणी करना कठिन है कि राज्य किस तरह से दूषित हो सकता है और प्रत्येक विशेष मामले के लिए एक पुनर्स्थापना रणनीति को परिभाषित कर सकता है।

@stremlenye हाँ, सॉफ्टवेयर इंजीनियरिंग कभी-कभी कठिन होती है। अनुमानित राज्य और संक्रमण इसे कम करने में मदद करते हैं।

इतना ही नहीं, लेकिन यदि आपका राज्य जेसन ऑब्जेक्ट्स के समूह से अधिक है (जो मुझे नफरत है क्योंकि सब कुछ सम्मेलन द्वारा है और कुछ भी लागू नहीं किया गया है) और आप अपरिवर्तनीय.जेएस की पंक्ति में कुछ उपयोग करते हैं Record तो आप अपनी वस्तुओं के गुणों को सामने घोषित करने की आवश्यकता है और इसमें वे सभी अस्थायी सामान शामिल हैं जिन्हें आप कभी भी वहां चाहते हैं।

मेरे लिए Immutable.js का उपयोग किए बिना redux के साथ कुछ बनाना बस एक दुर्घटना होने की प्रतीक्षा कर रहा है।

मुझे पता है कि आप Signup रिकॉर्ड बना सकते हैं और साइन अप करते समय इसे केवल शून्य नहीं होना चाहिए, लेकिन समस्या अधिक मौलिक है, क्योंकि आपके वेबएप में ऐसे बहुत से मामले हो सकते हैं, और यही परेशान करता है मुझे।

@ir-ईंधन

इतना ही नहीं, लेकिन यदि आपका राज्य जेसन ऑब्जेक्ट्स के समूह से अधिक है (जो मुझे नफरत है क्योंकि सब कुछ सम्मेलन द्वारा है और कुछ भी लागू नहीं किया गया है) और आप अपरिवर्तनीय.जेएस रिकॉर्ड की पंक्ति में कुछ उपयोग करते हैं तो आपको गुणों की घोषणा करने की आवश्यकता है आपकी वस्तुओं के सामने और इसमें वे सभी अस्थायी सामान शामिल हैं जो आप कभी भी वहां चाहते हैं।

मेरे लिए Immutable.js का उपयोग किए बिना redux के साथ कुछ बनाना बस एक दुर्घटना होने की प्रतीक्षा कर रहा है।

अभी के लिए, मैं Redux के साथ Immutable.js का उपयोग करने पर आश्वस्त नहीं हूं, यह एकीकृत करने के लिए बहुत जटिल प्रतीत होता है (और प्रदर्शन करने वाला नहीं)। विकास और परीक्षण के दौरान एक डीप-फ्रीज, और अधिकांश मामलों को कवर करने के लिए परीक्षणों का एक सेट पर्याप्त होना चाहिए। और रेड्यूसर या अन्य जगहों पर जहां आपके पास संदर्भ है, राज्य को बदलने से बचने के लिए एक सख्त सम्मेलन।

मुझे पता है कि आप साइनअप रिकॉर्ड बना सकते हैं और साइन अप करते समय इसे केवल शून्य नहीं होना चाहिए

हाँ, मेरे मन में यही था।

लेकिन समस्या अधिक मौलिक है, क्योंकि आपके वेबपैप में आपके बहुत से मामले हो सकते हैं, और यही मुझे परेशान करता है।

इसे ही हम स्पष्ट एप्लिकेशन स्थिति कहते हैं -- हर पल में हम ऐप की स्थिति को जानते हैं जिसमें कई घटक होते हैं। यदि आप राज्य की संरचना को कम स्पष्ट और अधिक गतिशील बनाना चाहते हैं, तो https://github.com/tonyhb/redux-ui का अनुसरण करें

जेएस विकास के साथ यही पूरी समस्या है। "चलो सम्मेलनों से चिपके रहें"। और यही कारण है कि लोगों को यह एहसास होने लगता है कि यह जटिल वातावरण में काम नहीं करता है, क्योंकि लोग गलतियाँ करते हैं, और टाइपस्क्रिप्ट और इम्यूटेबल.जेएस जैसे समाधान लेकर आते हैं।

एकीकृत करने के लिए यह बहुत जटिल क्यों होगा? यदि आप 'रिकॉर्ड' का उपयोग करते हैं तो आप उन सभी वस्तुओं का उपयोग करते हैं (जब तक आप उन्हें पढ़ रहे हैं) सामान्य जेएस ऑब्जेक्ट्स के रूप में, गुणों तक पहुंचने के लिए डॉट नोटेशन के साथ, एक लाभ के रूप में आप सामने घोषित करते हैं कि कौन से गुण आपकी वस्तु का हिस्सा हैं .

मैं अपने सभी redux विकास Immutable.js के साथ कर रहा हूं, बिना किसी समस्या के। तथ्य यह है कि किसी वस्तु को गलती से संशोधित नहीं किया जा सकता है, रेडक्स में एक बड़ा फायदा है और आपके ऑब्जेक्ट प्रोटोटाइप को परिभाषित करने की 'प्रकार की सुरक्षा' भी सुविधाजनक है।

और यदि आप वास्तव में मध्य-साइनअप पुनः लोड का समर्थन करना चाहते हैं, तो बस मूल घटक है जो इन सभी चरणों को नियंत्रित करता है, इसकी स्थिति को स्थानीय स्टोरेज में संग्रहीत करता है।

@ir-ईंधन
मेरे लिए चीजों को स्थानीय स्टोरेज में रखना साइड इफेक्ट की तरह दिखता है और ऐसा लगता है कि यह घटक में करने के लिए एक अच्छा अभ्यास नहीं है।

समस्या फिर से यह है कि आप वैश्विक एप्लिकेशन स्थिति को किसी ऐसी चीज से प्रदूषित कर रहे हैं जिसकी आपको केवल अपने वेबएप में कुछ स्क्रीन की आवश्यकता है।

हो सकता है कि मैंने नकली एपीआई का स्पष्ट रूप से वर्णन नहीं किया है, इसे बनाने का सबसे महत्वपूर्ण कारण यह है कि मैं उन चीजों को only need in a few screens को redux की एप्लिकेशन स्थिति में नहीं रखना चाहता। फॉर्मपेज_ए/बी में वे फॉर्म डेटा स्टोर करने के लिए सिर्फ एपीआई को कॉल करते हैं और फिर अगले चरण पर जाते हैं:

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

और फॉर्मपेज_सी (अंतिम फॉर्म) में:

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

वे सभी अस्थायी डेटा नकली एपीआई में रहते हैं और वैश्विक अनुप्रयोग स्थिति प्रदूषित नहीं हुई है। यदि हम प्रवाह को पुनः आरंभ करने के लिए नकली एपीआई में डेटा साफ़ करना चाहते हैं, तो बस इसे करने के लिए कार्रवाई भेजें।

@sompylasar आपके राज्य को एक स्पष्ट बटन के साथ रीसेट करने में कोई समस्या नहीं है - अनहेल्ड विफलताओं के बाद समस्याएं होती हैं: यह भविष्यवाणी करना कठिन है कि राज्य किस तरह से दूषित हो सकता है और प्रत्येक विशेष मामले के लिए एक पुनर्स्थापना रणनीति को परिभाषित कर सकता है।

@stremlenye मैं इससे सहमत हूं, लेकिन मुझे लगता है कि उन विशेष विफलता के मामलों में व्यावसायिक चीजें होने की अधिक संभावना है, वे हमेशा यहां होते हैं चाहे हम राज्य को कहीं भी रखें, और उन्हें सही तरीके से संभाला जाना चाहिए, लेकिन पर्याप्त रूप से स्पष्ट रूप से वर्णित नहीं किया गया है क्षण। केवल एक चीज जो देवता कर सकते हैं, वह है इसे ट्रैक करना आसान बनाना ताकि हम इसे कम दर्द के साथ ठीक कर सकें।

और राज्य को मूल घटक में रखने से चीजें जटिल होने पर तर्क करना कठिन हो सकता है। नकली एपीआई के साथ हम उस स्थिति को क्रियाओं के साथ बदलते हैं और यह अधिक अनुमानित लगता है।

लेकिन मैं मानता हूं कि कम जटिलता वाले ज्यादातर मामलों में नकली एपीआई बहुत भारी लगती है।

उपरोक्त सभी संदेशों से नहीं गुजरा। यहां मैं सिर्फ अपना दृष्टिकोण देता हूं: कंपोनेंटविल रिसीवप्रॉप्स में प्रोप परिवर्तनों का पता लगाएं।

कहें कि राज्य का आकार है: {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
      };
      // ...

क्या आपको लगता है कि यह तरीका ठीक है? यह काम करता है।

मैं इसके साथ समाप्त हो गया हूं। बताएं कि आप इस बारे में क्या सोचते हैं:

रेडक्स कार्रवाई पंजीकृत करें:

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 के साथ शक्कर किया है, और यह चीनी इस तथ्य को छुपाती है कि अनुरोध के तीन राज्य हैं (पहले, प्रगति पर, बाद में)। ये स्टेट्स व्यू कंपोनेंट में छुप जाते हैं। अनुरोध प्रारंभ को अनदेखा कर दिया जाता है, और अनुरोध त्रुटि दृश्य में नियंत्रित हो जाती है और रेडक्स के माध्यम से प्रेषित नहीं होती है, इसलिए ऐप स्थिति यहां व्यवसाय से बाहर है। यदि किसी कारण से इस स्थिति वाले घटक को अनमाउंट किया जाता है और फिर रिमाउंट किया जाता है, तो रजिस्टर अनुरोध की स्थिति खो जाएगी और इसके परिणाम को हैंडल नहीं किया जाएगा, और इससे बाद की त्रुटियां हो सकती हैं (उदाहरण के लिए उपयोगकर्ता पहले से ही पंजीकृत है)।

उपयोगकर्ता को एक त्रुटि मिल रही है, फिर दूसरे पृष्ठ पर नेविगेट करता है, फिर फिर से फॉर्म पेज पर जाता है - फॉर्म खाली है और कोई त्रुटि नहीं है।

इसे प्राप्त करने के लिए, आप घटक माउंट पर USER_REGISTRATION_RESET जैसी कार्रवाई भेज सकते हैं जो स्टोर में त्रुटि को रीसेट कर देगा। इस कार्रवाई को केवल तभी नियंत्रित किया जाना चाहिए जब कोई लंबित पंजीकरण अनुरोध न हो, अन्यथा लंबित अनुरोध परिणाम ऐप द्वारा नियंत्रित नहीं किया जाता है।

प्रतिक्रिया के लिए धन्यवाद।

आपने अपने कोड को async/प्रतीक्षा के साथ शर्करा दिया है, और यह चीनी इस तथ्य को छुपाती है कि अनुरोध के तीन राज्य हैं (पहले, प्रगति पर, बाद में)

इस बात पर ध्यान दिए बिना कि मैं एसिंक/प्रतीक्षा का उपयोग करता हूं या नहीं, ये स्थितियां मौजूद हैं।

व्यू कंपोनेंट में छुप जाते हैं ये स्टेट्स

जैसा कि इरादा है, वह घटक स्थिति है .. यह ऐप स्थिति में क्यों होना चाहिए?

अनुरोध प्रारंभ को अनदेखा किया जाता है

चालू...

और अनुरोध त्रुटि दृश्य में नियंत्रित हो जाती है और redux के माध्यम से प्रेषित नहीं होती है

जैसा सोचा वैसा

यदि किसी कारण से वह घटक जिसमें यह राज्य शामिल है, अनमाउंट और फिर रिमाउंट करता है, तो रजिस्टर अनुरोध की स्थिति खो जाएगी और उसका परिणाम हैंडल नहीं किया जाएगा

यह सच नहीं है। यदि घटक राज्य या अस्तित्व की परवाह किए बिना अनुरोध सफल होगा, तो उपयोगकर्ता पंजीकृत और पुनर्निर्देशित किया जाएगा। register एक्शन क्रिएटर (हैंडलडेटा) देखें।

इसे प्राप्त करने के लिए, आप एक क्रिया भेज सकते हैं ...

मुद्दा यह है। एक और कार्रवाई? इतना बॉयलरप्लेट क्यों? सबमिट बटन को अक्षम या सक्षम करें, फॉर्म त्रुटियां दिखाएं या लाइव सत्यापन, अनुरोध खुला होने पर स्पिनर दिखाएं .. और इन क्रियाओं से नई क्रियाएं होती हैं जो डिफ़ॉल्ट स्थिति को पुनर्स्थापित करती हैं .. यह ऐप स्थिति में क्यों होना चाहिए?

यह सच नहीं है। यदि घटक राज्य या अस्तित्व की परवाह किए बिना अनुरोध सफल होगा, तो उपयोगकर्ता पंजीकृत और पुनर्निर्देशित किया जाएगा। रजिस्टर एक्शन क्रिएटर (हैंडलडाटा) देखें।

हां, लेकिन यह दो बाद के 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 के साथ कार्रवाई के लिए रीडायरेक्ट यूआरएल पास करना और अतिरिक्त कॉलिंग next विधि।