Redux: एसिंक क्रियाओं को कैसे श्रृंखलाबद्ध करें?

नमस्ते! यह एक इश्यू ट्रैकर है न कि सपोर्ट फोरम। हम अगली बार StackOverflow पर पूछने की सराहना करेंगे क्योंकि SO के विपरीत, यहाँ उत्तर खो जाते हैं।

उस ने कहा, यदि आप Redux Thunk मिडलवेयर के साथ अपना स्टोर बनाते हैं, तो आप इस तरह async एक्शन क्रिएटर लिख सकते हैं:

// If you use Redux Thunk...
import { createStore, applyMiddleware } from 'redux'
import thunk from 'redux-thunk'
const store = createStore(reducer, applyMiddleware(thunk))

// You can define asynchronous action creators that return functions.
// We call such action creators "thunks":

export function getUser(id) {
  // Redux Thunk will inject dispatch here:
  return dispatch => {
    // Reducers may handle this to set a flag like isFetching
    dispatch({ type: 'GET_USER_REQUEST', id })

    // Perform the actual API call
    return fetchUser().then(
      response => {
        // Reducers may handle this to show the data and reset isFetching
        dispatch({ type: 'GET_USER_SUCCESS', id,  response })
      },
      error => {
        // Reducers may handle this to reset isFetching
        dispatch({ type: 'GET_USER_FAILURE', id,  error })
        // Rethrow so returned Promise is rejected
        throw error
      }
    )
  }
}

// Thunks can be dispatched, if Redux Thunk is applied,
// just like normal action creators:
store.dispatch(getUser(42));

// The return value of dispatch() when you dispatch a thunk *is*
// the return value of the inner function. This is why it's useful
// to return a Promise (even though it is not strictly necessary):
store.dispatch(getUser(42)).then(() =>
  console.log('Fetched user and updated UI!')
)

// Here is another thunk action creator.
// It works exactly the same way.
export function getPost(id) {
  return dispatch => {
    dispatch({ type: 'GET_POST_REQUEST', id })
    return fetchPost().then(
      response => dispatch({ type: 'GET_POST_SUCCESS', id,  response }),
      error => {
        dispatch({ type: 'GET_POST_FAILURE', id,  error })
        throw error
      }
    )
  }
}

// Now we can combine them
export function getUserAndTheirFirstPost(userId) {
  // Again, Redux Thunk will inject dispatch here.
  // It also injects a second argument called getState() that lets us read the current state.
  return (dispatch, getState) => {
    // Remember I told you dispatch() can now handle thunks?
    return dispatch(getUser(userId)).then(() => {
      // Assuming this is where the fetched user got stored
      const fetchedUser = getState().usersById[userId]
      // Assuming it has a "postIDs" field:
      const firstPostID = fetchedUser.postIDs[0]
      // And we can dispatch() another thunk now!
      return dispatch(getPost(firstPostID))
    })
  }
}

// And we can now wait for the combined thunk:
store.dispatch(getUserAndTheirFirstPost(43)).then(() => {
  console.log('fetched a user and their first post')
})

// We can do this anywhere we have access to dispatch().
// For example, we can use this.props.dispatch, or put action
// creators right into the props by passing them to connect, like this:
// export default connect(mapStateToProps, { getUserAndTheirFirstPost })

हमें इसे अक्सर पूछे जाने वाले प्रश्न में डाल देना चाहिए।

मैंने इस समस्या को इस प्रकार हल किया। क्रियाओं को संशोधित किए बिना। मैं घटक वादा में डाल दिया।

  clickShowUserEvent(data) {
   Promise.resolve(data.userAuth(data.login, data.password)) // dispatch
    .then(function (response) {
      data.showEvents(); //dispatch
      return response;
    })
    .then(function(response){console.log("@RESPONSE",response);data.show(data)})
  }

यह सही फैसला है?

यह भी काम करता है, किस पैटर्न का उपयोग करना है यह आप पर निर्भर है।

@ ar53n एक प्रतिक्रिया घटक में एक वादे के साथ पैटर्न में कई खामियां हैं:

• कोई त्रुटि प्रबंधन नहीं है ( उपरोक्त उदाहरण में), यानी catch भाग। आपको अनहेल्ड रिजेक्शन मिल सकता है।
• यह अबाधित है, उदाहरण के लिए जब घटक अनमाउंट होता है या कुछ क्रिया होती है जो ऐप स्थिति को बदल देती है।
• इसकी स्थिति निहित है। हालांकि साइड-इफेक्ट्स एक अलग चर्चा है, कम से कम ऐप स्टेट में उस चल रही प्रक्रिया का पता लगाना उपयोगी होगा।

@sompylasar धन्यवाद जॉन आपकी टिप्पणियों के लिए धन्यवाद। मैं सिर्फ सरल क्रियाओं को संशोधित नहीं करना चाहता। हमारे पास 2 सरल क्रियाएं हैं Authentication और GetEvents यह 2 async अनुरोध है और इसमें catch भी शामिल है। घटक पर क्लिक करने पर बस यह क्रिया कॉल
जैसे

export function userAuth(login, password) {
  return (dispatch, getState) => {
    console.log('STATE', getState())
    let newState = dispatch(requestUserAuth(login, password))
    return fetch(AUTH_URL + newState.queryParams, MY_INIT)
      .then(response => response.json())
      .then(function (json) { dispatch(receiveUserAuth(json)); return json})
      .catch(error => dispatch(errorUserAuth(error)))
  }
}

और हमारे पास यह है

अगर मैं गलत हूँ तो मुझे सुधारो, धन्यवाद

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

@ ar53n आप redux-dataloader पर भी एक नज़र डाल सकते हैं।
यह जटिल श्रृंखला async क्रियाओं के लिए डिज़ाइन किया गया है।
आशा है ये मदद करेगा!

इसे बंद करना क्योंकि यहां कुछ संभावित समाधान पोस्ट किए गए हैं। आप आजकल redux-saga में भी देखना चाह सकते हैं!

@gaearon क्या आपका उदाहरण ब्रेक टाइम ट्रैवलिंग है ना?

मेरा मतलब है कि उदाहरण के लिए आपका AJAX कॉल पहली बार विफल हुआ और फिर आप सर्वर की तरफ ठीक हो गए और इसे फिर से करना चाहते हैं

@gaearon मैंने आपके समाधान की कोशिश की लेकिन जब मैं किसी भी घटक से store.dispatch(...) पर कॉल करने का प्रयास करता हूं (मेरे मामले में LoginComponent से अधिकृत अनुरोध करने के लिए) मुझे यह त्रुटि मिली:

undefined is not an object (evaluating '_AppNavigator.AppNavigator.router')

लगता है कुछ गड़बड़ है। मैंने एक्शन क्रिएटर को इस तरह सेट किया है:

// actions.tsx
export const ActionCreators = {
    authenticate: (username: string, password: string) => {
        return (dispatch) => {
            return auth.login(username, password).then(
                response => {
                    dispatch(navActionCreators.login(res))
                    return response
                },
                error => {
                    throw error
                }
            )
        }
    }
}

// LoginScreen.tsx (login method)
store.dispatch(authActions.authenticate(this.state.username, this.state.password))
  .then((res) => {
     this.setState({isLoading: false})
   })
   .catch((error: Error) => {
     this.setState({
       isLoading: false,
       error: error ? error.message : 'Si è verificato un\' errore.'
     })
   })

मैं क्या खो रहा हूँ?

@ बीएम-सॉफ्टवेयर: उस प्रश्न को इसके बजाय स्टैक ओवरफ़्लो पर पूछा जाना चाहिए।

@ ar53n और @ sompylasar मुझे कुछ समय हो गया है, लेकिन मैं अभी इस पैटर्न से जूझ रहा हूं। @ ar53n आपके उदाहरण में, यदि fetch अंदर userAuth विफल हो जाता है, तो उस श्रृंखला में क्या होता है जहां userAuth कहा जाता है?

ऐसा लगता है कि .catch(error => dispatch(errorUserAuth(error))) गलती करने वाले UserAuth क्रिया को प्रेषित करेगा, जो कि बहुत अच्छा है। Redux में यह आमतौर पर हम त्रुटियों को "हैंडल" करते हैं। लेकिन उस श्रृंखला में जिसका आपने पहले उल्लेख किया था:

clickShowUserEvent(data) {
   Promise.resolve(data.userAuth(data.login, data.password)) // dispatch
    .then(function (response) {
      data.showEvents(); //dispatch
      return response;
    })
    .then(function(response){console.log("@RESPONSE",response);data.show(data)})
  }

data.showEvents() को _always_ कहा जा रहा है, भले ही उपयोगकर्ता प्रमाणन विफल हो। मुझे नहीं लगता कि ज्यादातर लोग यही उम्मीद करते हैं या चाहते हैं, लेकिन चूंकि Redux एरर-हैंडलिंग आमतौर पर डिस्पैचिंग और री-थ्रो नहीं करके की जाती है, यह त्रुटियों को निगल जाती है ताकि प्रॉमिस चेनिंग उम्मीद के मुताबिक काम न करे।

साथ ही, अगर आप री-थ्रो करते हैं, तो आपको _आपके ऐप में हर एक एक्शन क्रिएटर कॉल, हर जगह_ पर .catch() के लिए अटका हुआ है। उपरोक्त @gaearon से उदाहरण, जहां वह सभी त्रुटियों को फिर से फेंकता है, अंत में यह करता है:

// And we can now wait for the combined thunk:
store.dispatch(getUserAndTheirFirstPost(43)).then(() => {
  console.log('fetched a user and their first post')
})

अगर getUserAndTheirFirstPost के अंदर बड़ी संयुक्त श्रृंखला में _anything_ विफल हो जाता है, तो "अनहेल्ड वादा अस्वीकृति" त्रुटि होगी।

मुझे लगता है कि एकमात्र उत्तर फिर से फेंकना है और फिर .catch() हर जगह, या संभवतः प्रतिक्रिया 16 त्रुटि सीमाओं का उपयोग करना है।

@jasonrhodes

clickShowUserEvent(data) {
   Promise.resolve(data.userAuth(data.login, data.password)) // dispatch
    .then(function (response) {
      data.showEvents(); //dispatch

data.showEvents() को _always_ कहा जा रहा है, भले ही उपयोगकर्ता प्रमाणन विफल हो जाए।

नहीं, यदि data.userAuth(data.login, data.password) एक वादा लौटाता है जो अंततः अस्वीकार कर दिया जाता है तो इसे नहीं कहा जाएगा। वादा पूरा होने पर .then के लिए पहला तर्क कहा जाता है (इसे onFulfilled कहा जाता है), दूसरा जब वादा खारिज कर दिया जाता है (इसे onRejected कहा जाता है) - कल्पना देखें .

दूसरे नोट पर, रिएक्ट 16 त्रुटि सीमाएं वादों के साथ मदद नहीं करेंगी, वे केवल यह सुनिश्चित करने के लिए सिंक्रोनस फेंके गए अपवादों को पकड़ती हैं कि रिएक्ट आंतरिक स्थिति टूटी नहीं है।

@jasonrhodes इसके अलावा, वादा दुनिया के एक अच्छे नागरिक बनें, या तो कॉलर को वादा वापस करें (इसे तब त्रुटियों को संभालना होगा) या इसे .catch संलग्न करें (और त्रुटियों को संभालें जहां वादा बनाया गया है)।

आपका उदाहरण कोई नहीं करता है:

clickShowUserEvent(data) {
   Promise.resolve(data.userAuth(data.login, data.password)) // dispatch
    .then(function (response) {
      data.showEvents(); //dispatch
      return response;
    })
    .then(function(response){console.log("@RESPONSE",response);data.show(data)})
  }

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

फिर से देखें, data.showEvents() को _always_ कॉल किया जाएगा, भले ही userAuth फ़ंक्शन के अंदर fetch कॉल विफल हो जाए। क्यों? क्योंकि .catch() के अंदर userAuth फ़ंक्शन है जो Redux तरीके से त्रुटि को संभालता है: एक त्रुटि कार्रवाई भेजकर।

यह मेरी पोस्ट का बिंदु है: जब आप एसिंक क्रियाओं से त्रुटियों को पकड़ते हैं ताकि आप त्रुटि क्रियाओं को भेज सकें, तो क्या आप निगलते हैं और आगे के वादे को सही ढंग से काम करने से रोकते हैं? या क्या आप उस एक्शन क्रिएटर के प्रत्येक कॉलर को .catch() पर फिर से फेंक देते हैं और मजबूर करते हैं, चाहे "अनहेल्ड प्रॉमिस रिजेक्शन" से बचने के लिए क्या किया जाए?

साथ ही, अपने अनुभव में मैंने पाया है कि किसी व्यक्ति को किसी युक्ति से जोड़ने से पहले यह समझना एक अच्छा विचार है कि कोई व्यक्ति क्या जानता है। उत्तर देने के लिए धन्यवाद, मुझे पता है कि यह एक पुरानी बातचीत है जिसे मैंने खोदा है, लेकिन यह एक महत्वपूर्ण है क्योंकि आप देख सकते हैं कि इसे याद करना कितना आसान है!

@jasonrhodes

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

समझ गया, मैं क्षमा चाहता हूँ, मुझे पूरा प्रसंग याद नहीं आया।

क्योंकि .catch() के अंदर userAuth फ़ंक्शन है जो Redux तरीके से त्रुटि को संभालता है: एक त्रुटि कार्रवाई भेजकर।

समझ गया, या तो यह इरादा के अनुसार काम करता है, या यदि आप उस वादे को वापस करते हैं (और कॉल साइटों पर त्रुटियों को संभालते हैं), या आपको .catch के भीतर त्रुटि को फिर से फेंकना चाहिए, तो आपको वहां .catch नहीं डालना चाहिए। .catch हैंडलर डाउनस्ट्रीम वादे को अस्वीकार करने के लिए।

वैसे भी, थंक्स स्वयं चेनिंग के लिए उपयुक्त नहीं हैं। आपको एक थंक के अंदर श्रृंखलाबद्ध करना चाहिए, या अधिक जटिल एसिंक्रोनस वर्कफ़्लो के लिए सागा का उपयोग करना चाहिए।

मैं कुछ समय के लिए वादे की जंजीर को तोड़ने की उस समस्या में फंस गया हूं। आमतौर पर, मेरे एक्शन क्रिएटर्स .then() में एक SUCCESS एक्शन या उसी http रिक्वेस्ट के .catch() में एक FAILURE एक्शन का उत्सर्जन करते हैं, जो थंक से लौटाया जाता है।

जब भी मेरा एक्शन क्रिएटर कैच ब्लॉक में गया और मैंने this.props.myActionCreator().then(() => ) किया, तो अनुरोध में समस्या होने पर भी उसके अंदर का कोड निष्पादित होगा।

उस पर ध्यान देने के लिए, मैंने हमेशा ऐप स्थिति में एक त्रुटि चर की जांच करना सुनिश्चित किया है जो उस क्रिया निर्माता के लिए FAILURE मामले में सेट है। लेकिन जब आप कई एक्शन क्रिएटर्स को बुलाते हैं, तो चीजें गड़बड़ हो जाती हैं, खासकर वे जो दूसरे पर निर्भर होते हैं। मुझे कई एरर वेरिएबल्स के लिए if स्टेटमेंट चेक करना था।

मुझे एक्शन क्रिएटर रिटर्न वैल्यू के लिए कैच ब्लॉक में त्रुटि को फिर से फेंककर वादा श्रृंखला को नहीं तोड़ने का तथ्य पसंद है। हालांकि, इसके लिए हमें प्रतिक्रिया घटक से .catch() का उपयोग करना होगा, जहां क्रिया निर्माता को बुलाया जाता है। मेरे पास उस कैच ब्लॉक में कुछ भी नहीं लिखा होगा, क्योंकि त्रुटि चर पहले से ही एक reducer में FAILURE कार्रवाई के संचालन द्वारा निर्धारित किया गया है।

तो क्या आप लोग, @jasonrhodes , @sompylasar , मुझे री-थ्रो दृष्टिकोण का उपयोग करने और एक रिएक्ट घटक में एक्शन क्रिएटर कॉल की वादा श्रृंखला पर एक खाली .catch () ब्लॉक रखने की सलाह देंगे?

@nbkhope ईमानदार होने के लिए यह Redux के साथ मेरी सबसे बड़ी समस्या रही है और आज तक मुझे एक अच्छा जवाब नहीं मिला है। अधिक सहायक न होने के लिए क्षमा करें!

दोस्तों, आप इस लेख में कुछ थंक विकल्प पा सकते हैं https://decembersoft.com/posts/what-is-the-right-way-to-do-asynchronous-operations-in-redux/

@gaearon

आपके पहले उत्तर के संबंध में, अगर मैं वादों के बजाय async और प्रतीक्षा का उपयोग कर रहा हूं तो मुझे इसे कैसे परिवर्तित करना चाहिए? निम्नलिखित की तरह कुछ:

export const funcA = () => {
    return async (dispatch) => {
        const data = await doSomething(...)
        dispatch({ action: DID_SOMETHING, payload: data })
    }
}

export const funcB = () => {
    return async (dispatch) => {
        const data = await doSomethingElse(...)
        dispatch({ action: DID_SOMETHING_ELSE, payload: data })
    }
}

export const funcC = () => {
    return async (dispatch) => {
        const data = await doSomethingMore(...)
        dispatch({ action: DID_SOMETHING_MORE, payload: data })
    }
}

// how to chain funcA, funcB and funcC
const myFunc = () => {
    // execute funcA
    // when complete execute funcB
    // when complete execute funcC
}

@yingdongzhang आप उन्हें निम्नानुसार श्रृंखलाबद्ध कर सकते हैं:

const myFunc = () => {
  return async (dispatch) => {
    try {
      await dispatch(funcA())
      await dispatch(funcB())
      await dispatch(funcC())
    } catch (error) {
      //error handling
    }
  }
}

@Boomxx धन्यवाद उम्मीद के मुताबिक काम करता है।

मैं सोच रहा हूं कि मैं fetch all posts of the user कैसे करूं।

@ km16 : यह एक बग ट्रैकर है, सपोर्ट सिस्टम नहीं। उपयोग संबंधी प्रश्नों के लिए, कृपया स्टैक ओवरफ़्लो या रिएक्टिफ्लक्स का उपयोग करें जहां आपकी सहायता के लिए बहुत अधिक लोग तैयार हैं - आपको संभवतः एक बेहतर उत्तर तेजी से मिलेगा। धन्यवाद!