Redux: सर्वश्रेष्ठ async सर्वरसाइड लोडिंग तकनीक?

धन्यवाद!

आदर्श रूप से, लोडिंग दुकानों में ही होनी चाहिए

Redux लागू करता है कि स्टोर पूरी तरह से सिंक्रोनस हैं। आप जो वर्णन करते हैं वह इसके बजाय एक्शन क्रिएटर में होना चाहिए।

मैं _थिंक_ यह डिफ़ॉल्ट थंक मिडलवेयर के साथ भी संभव हो सकता है। आपका एक्शन क्रिएटर ऐसा दिखेगा:

export function doSomethingAsync() {
  return (dispatch) => {
    dispatch({ type: SOMETHING_STARTED });

    return requestSomething().then(
      (result) =>  dispatch({ type: SOMETHING_COMPLETED, result }),
      (error) =>  dispatch({ type: SOMETHING_FAILED, error })
    );
  };
}

और स्टोर में वास्तविक (दानेदार) कार्यों को संभालना।

बॉयलरप्लेट को हटाने के लिए कस्टम मिडलवेयर लिखना भी संभव है।

प्रतिभावान! मुझे लगा कि मैं कुछ स्पष्ट देख रहा था। मुझे _doing_ और _storing_ का वह अलगाव पसंद है।

मैं इस पुस्तकालय को बढ़ते हुए देखने के लिए उत्सुक हूं, हालांकि यह पहले से ही काफी हद तक पूर्ण है। चीयर्स, @gaearon!

आप इस तरह एक कस्टम मिडलवेयर भी लिख सकते हैं

export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    next({ ...rest, readyState: 'request' );
    return promise.then(
      (result) => next({ ...rest, result, readyState: 'success' }),
      (error) => next({ ...rest, error, readyState: 'failure' })
    );
  };
}

और डिफ़ॉल्ट के बजाय इसका इस्तेमाल करें।

यह आपको async एक्शन क्रिएटर जैसे लिखने देगा

function doSomethingAsync(userId) {
  return {
    type: SOMETHING,
    promise: requestSomething(userId),
    userId
  };
}

और उन्हें में बदल दें

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, readyState: 'success' }
{ type: SOMETHING, userId: 2, readyState: 'failure' }

ओह, यह भी अच्छा है, और जब मैंने मूल प्रश्न पूछा तो मेरे मन में जो कुछ भी था। मैं यह नहीं बता सकता कि स्टोर के अंदर readyState जांच करने के लिए if s जोड़ने के बदले में कार्रवाई स्थिरांक की संख्या को कम करने में मुझे ट्रेडऑफ़ पसंद है या नहीं। मुझे लगता है मैं addtional होने पसंद कर सकते हैं _SUCCESS और _FAILURE प्रत्येक कार्य के संस्करणों सिर्फ डालने से बचने के लिए एक if एक अंदर case ।

हालांकि धन्यवाद।

हाँ, यह पूरी तरह से आपके स्वाद पर निर्भर है। आपके पास एक समान संस्करण हो सकता है जो types: { request: ..., success: ..., failure: ... } को क्रियाओं में बदल देता है। यह पुस्तकालय में सेंकने के बजाय इसे एक मिडलवेयर बनाने की बात है: इन चीजों के लिए हर किसी का अपना स्वाद होता है।

// Middleware
export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, types, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    const [REQUEST, SUCCESS, FAILURE] = types;
    next({ ...rest, type: REQUEST });
    return promise.then(
      (result) => next({ ...rest, result, type: SUCCESS }),
      (error) => next({ ...rest, error, type: FAILURE })
    );
  };
}

// Usage
function doSomethingAsync(userId) {
  return {
    types: [SOMETHING_REQUEST, SOMETHING_SUCCESS, SOMETHING_FAILURE],
    promise: requestSomething(userId),
    userId
  };
}

अरे यार, मुझे वह समाधान पसंद है। आपके द्वारा प्रस्तावित पहले समाधान की तरह then() और dispatch() अतिरिक्त कॉल करने से कहीं अधिक अच्छा है। मिडलवेयर के लिए हुर्रे!

मुझे बताएं कि कैसे (और क्या ;-) यह काम करता है!
हमने वास्तव में कस्टम मिडलवेयर का ज्यादा परीक्षण नहीं किया है।

आपने एक } छोड़ा (वह -1 अंक है), लेकिन यह एक आकर्षण की तरह काम करता है! पहली बार।

:+1:

@erikras मैं

यह सिर्फ छद्म कोड है, इसलिए इसे कहीं भी चिपकाने न जाएं, लेकिन मैं प्रतिक्रिया-राउटर का उपयोग कर रहा हूं (जिसका एपीआई रेडक्स के रूप में तेजी से बदल रहा है) कुछ इस तरह:

app.get('/my-app', (req, res) => {
  Router.run(routes, req.path, (error, initialState) => {
    Promise.all(initialState.components
      .filter(component => component.fetchData) // only components with a static fetchData()
      .map(component => {
        // have each component dispatch load actions that return promises
        return component.fetchData(redux.dispatch);
      })) // Promise.all combines all the promises into one
      .then(() => {
        // now fetchData() has been run on every component in my route, and the
        // promises resolved, so we know the redux state is populated
        res.send(generatePage(redux));
      });
  });
});

क्या इससे कुछ साफ होता है?

@ सबसे

स्लैक में अपनी समस्या का हवाला देते हुए:

मेरे पास रूट हैंडलर है

 static async routerWillRun({dispatch}) {
   return await dispatch(UserActions.fooBar());
 }

जहां UserActions.fooBar() है:

export function fooBar() {
 return dispatch => {
   doAsync().then(() => dispatch({type: FOO_BAR}));
 };
}

फिर सर्वर में प्रस्तुत करना मैं उपज कर रहा हूँ:

 yield myHandler.routerWillRun({dispatch: redux.dispatch});

लेकिन यह काम नहीं करता।

मुझे लगता है कि यहां समस्या यह है कि आप वास्तव में fooBar की नेस्टेड विधि से कुछ भी वापस नहीं कर रहे हैं।

या तो ब्रेसिज़ हटा दें:

export function fooBar() {
  return dispatch =>
    doAsync().then(() => dispatch({type: FOO_BAR}));
}

या एक स्पष्ट return कथन जोड़ें:

export function fooBar() {
  return dispatch => {
    return doAsync().then(() => dispatch({type: FOO_BAR}));
  };
}

किसी भी तरह से, जैसा कि ऊपर सुझाव दिया गया है, कस्टम वादा मिडलवेयर का उपयोग करना आसान हो सकता है।

@erikras आपकी आखिरी टिप्पणी के बारे में जहां आप initialState.components (Router.run के कॉलबैक में) के रूप में आपके पास fetchData विधि को कॉल कर रहे हैं, जिस ऑब्जेक्ट को आप घटक संदर्भ प्राप्त करते हैं, केवल रूट हैंडलर से मेल खाते हैं। उन घटकों तक पहुंचने के बारे में आपके क्या विचार हैं जो मेल खाने वाले रूट हैंडलर नहीं हो सकते हैं, यानी एक चाइल्ड कंपोनेंट, लेकिन डेटा लाने की आवश्यकता है?

मैं जिस बारे में बात कर रहा हूं उसका एक उदाहरण यहां दिया गया है

import React from 'react';
import Router from 'react-router';
import {Route, RouteHandler, DefaultRoute} from 'react-router';

//imagine Bar needs some data
const Bar = React.createClass({
  render(){
    return(
      <div>bar</div>);
  }
});

const Foo = React.createClass({
  render(){
    return (
      <div>
        foo
        <Bar/>
      </div>);
  }
});


const App = React.createClass({
  render(){
    return (
      <div>
        <RouteHandler />
      </div>
    );
  }
});

const routes = (
  <Route path="/" handler={App} name="App">
    <DefaultRoute handler={Foo} name="Foo"/>
  </Route>
);

Router.run(routes,'/',function(Root,state){
  console.log(state);
});

आउटपुट:

{ path: '/',
  action: null,
  pathname: '/',
  routes: 
   [ { name: 'App',
       path: '/',
       paramNames: [],
       ignoreScrollBehavior: false,
       isDefault: false,
       isNotFound: false,
       onEnter: undefined,
       onLeave: undefined,
       handler: [Object],
       defaultRoute: [Object],
       childRoutes: [Object] },
     { name: 'Foo',
       path: '/',
       paramNames: [],
       ignoreScrollBehavior: false,
       isDefault: true,
       isNotFound: false,
       onEnter: undefined,
       onLeave: undefined,
       handler: [Object] } ],
  params: {},
  query: {} }

आपके पास रूट्स में बार तक पहुंच नहीं होगी

@erikras शानदार! ठीक इसी तरह का रास्ता मैं नीचे जाना चाहता हूं। साझा करने के लिए धन्यवाद।

@iest मुझे आशा है कि पन जानबूझकर था, मिलान मार्गों के माध्यम से पुनरावृत्ति करके "एक मार्ग नीचे जाएं"। :-)

@mattybow यह सच है। यदि आपको _really_ ऐसे घटक की आवश्यकता है जो कुछ लोड करने के लिए आपके मार्गों में नहीं है, तो एकमात्र विकल्प React.renderToString() एक बार (परिणाम को छोड़कर) चलाने के लिए है, componentWillMount() में अपनी सभी लोडिंग करें, और किसी भी तरह जैसे ही आप जाते हैं वादों को बचाएं। react-router समर्थित सर्वर साइड रेंडरिंग से पहले मैं अपने घरेलू रूटिंग समाधान के साथ यही कर रहा था। मैं सुझाव दूंगा कि लोडिंग करने के लिए गैर-मार्ग घटकों की आवश्यकता एक डिज़ाइन समस्या का लक्षण हो सकती है। अधिकांश उपयोग के मामलों में एक मार्ग जानता है कि उसके घटकों को किस डेटा की आवश्यकता होगी।

@erikras
क्या आपके पास समाधान पर एक संपूर्ण उदाहरण देखने के लिए आपके पास कोई सार्वजनिक रेपो है?

@transedward मेरी इच्छा है कि मैंने किया, लेकिन मेरी सामग्री अब तक जिस तरीके से मैंने यहां विस्तृत की है उसका उपयोग करना अभी भी बहुत अपरिपक्व है। माफ़ करना।

उन्नत आइसोमोर्फिक उदाहरण पर +1
मुझे प्यार है कि यह कहाँ जा रहा है!

@transedward यहाँ एक नमूना परियोजना है जिसमें सभी ब्लीडिंग एज टेक के साथ मैंने एक साथ काम किया है। https://github.com/erikras/react-redux-universal-hot-example/

@erikras यह कमाल है! क्या आप कृपया इसे इस रीडमे और रिएक्ट हॉट लोडर के दस्तावेज़ "स्टार्टर किट" अनुभाग में जोड़ने के लिए पीआर सबमिट कर सकते हैं?

धन्यवाद! पीआर प्रस्तुत किए।

@erikras ग्रेट - धन्यवाद!

बस एक नोट - इस बातचीत में कुछ विचारों के आधार पर- मैंने वादों को संभालने के लिए एक मिडलवेयर बनाया: https://github.com/pburtchaell/redux-promise-middleware।

@pburtchaell @acdlite द्वारा इस पुस्तकालय के रूप में अच्छी तरह से नहीं है। https://github.com/acdlite/redux-promise

इस पर दो विचार:

1. वादे जो कार्यों में परिवर्तित हो जाते हैं उन्हें कार्रवाई के साथ पारित किया जा सकता है और Redux Store में रखा जा सकता है।

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

1. चयनकर्ताओं को अनुपलब्ध डेटा के लिए कार्रवाई कॉल करने देने के बारे में क्या?

मान लीजिए कि आप संदेश 3 प्रस्तुत करना चाहते हैं, तो आपका संदेश कंटेनर <Message id={3}> प्रस्तुत करेगा और संदेश चयनकर्ता जांच करेगा कि क्या state.msgs[3] मौजूद है और यदि नहीं, तो संदेश लोड करने का वादा भेजें।

तो दोनों को मिलाएं और घटक अपने आवश्यक डेटा को स्वतः चयन करेंगे और आपको पता चल जाएगा कि वे कब किए गए हैं।

मुझे पूरा यकीन है कि "स्टोर या क्रियाओं में कुछ भी अपरिवर्तनीय न डालें"। यह उन अपरिवर्तनीयों में से एक है जो मेरे लिए वास्तव में अच्छा काम कर रहा है (और उदाहरण के लिए समय यात्रा की अनुमति दी गई है) और इसे बदलने पर विचार करने के लिए _very_ सम्मोहक कारण होने चाहिए।

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

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

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

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

मैं वास्तव में @wmertens के अंतिम बिंदु के उत्तर की प्रतीक्षा कर रहा हूं।
एकाधिक समवर्ती कॉलों से बचना (यदि कुछ लंबित है तो कुछ भी न करें) एक बार-बार उपयोग-मामला है, यह सुनिश्चित नहीं है कि इसका उत्तर देने का सबसे अच्छा तरीका क्या है (क्योंकि आप किसी एक्शन क्रिएटर से स्टोर की स्थिति तक नहीं पहुंच सकते हैं)।

क्या एक्शन क्रिएटर उपयोगकर्ता (घटक) को राज्य में हर बार जांच करनी चाहिए कि क्या वह कार्रवाई भेज सकता है या नहीं? आपको इसे हर बार करना होगा .. शायद आपको अपना खुद का @connect एनोटेशन पेश करना होगा जो इसे लपेटता है?

क्योंकि आप एक्शन क्रिएटर से स्टोर की स्थिति तक नहीं पहुंच सकते हैं

क्यों? यदि आप थंक मिडलवेयर का उपयोग करते हैं तो आप इसे ठीक कर सकते हैं।

function doSomething() {
  return { type: 'SOMETHING' };
}

function maybeDoSomething() {
  return function (dispatch, getState) {
    if (getState().isFetching) {
      return;
    }

    dispatch(doSomething());
  };
}

store.dispatch(maybeDoSomething());

जो इसे हल करता है!
मैंने एक समय के लिए सोचा (बिना किसी कारण के) कि एक्शन क्रिएटर में राज्य तक पहुंचना एक बुरा अभ्यास था ^ ^ चूंकि एक्शन क्रिएटर कॉलर राज्य तक पहुंच सकता है, मुझे नहीं पता कि एक्शन क्रिएटर को क्यों नहीं करना चाहिए, इसलिए हाँ कूल हम यह कर सकते हैं :)

धन्यवाद @gaearon

@gaearon , http://gaearon.github.io/redux/docs/api/applyMiddleware.html ऊपर दिए गए आपके उत्तर के लिए बेहतर:

आप इस तरह एक कस्टम मिडलवेयर भी लिख सकते हैं

export default function promiseMiddleware() {
  return (next) => (action) => {
    const { promise, ...rest } = action;
    if (!promise) {
      return next(action);
    }

    next({ ...rest, readyState: 'request' );
    return promise.then(
      (result) => next({ ...rest, result, readyState: 'success' }),
      (error) => next({ ...rest, error, readyState: 'failure' })
    );
  };
}

और डिफ़ॉल्ट के बजाय इसका इस्तेमाल करें।
यह आपको async एक्शन क्रिएटर जैसे लिखने देगा

function doSomethingAsync(userId) {
  return {
    type: SOMETHING,
    promise: requestSomething(userId),
    userId
  };
}

और उन्हें में बदल दें

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, readyState: 'success' }
{ type: SOMETHING, userId: 2, readyState: 'failure' }

भी,

मुझे लगता है कि आखिरी भाग के लिए, आपका मतलब था:

{ type: SOMETHING, userId: 2, readyState: 'request' }
{ type: SOMETHING, userId: 2, result, readyState: 'success' }
{ type: SOMETHING, userId: 2, error, readyState: 'failure' }

मैं अनुमान लगा रहा हूं कि यह इस बात पर निर्भर करता है कि कोई success या failure वादे के कॉलबैक के लिए अलग-अलग कार्रवाइयां बनाना चाहता है, बजाय ऑटो-जेनरेटेड का उपयोग करने के।

आपके थंक उदाहरण में:

function makeASandwichWithSecretSauce(forPerson) {

  // Invert control!
  // Return a function that accepts `dispatch` so we can dispatch later.
  // Thunk middleware knows how to turn thunk async actions into actions.

  return function (dispatch) {
    return fetchSecretSauce().then(
      sauce => dispatch(makeASandwich(forPerson, sauce)),
      error => dispatch(apologize('The Sandwich Shop', forPerson, error))
    );
  };
}

तो गुप्त सॉस लाने में विफलता के लिए सामान्य त्रुटि कॉलबैक होना जरूरी नहीं होगा, क्योंकि सॉस लाने के लिए अलग-अलग परिस्थितियां हो सकती हैं।

इस प्रकार मैं थंक मॉडल को थोड़ा अधिक लचीला देख सकता हूं।

संभवतः लॉगिंग या शायद "एसिंक इन प्रोग्रेस बिजी इंडिकेटर" की टॉगलिंग जैसी कोई चीज मिडलवेयर के अधिक उपयुक्त उदाहरण हैं?

@justin808

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

मैंने दूसरे राज्य से ट्रिगर किए गए कार्यों (लोडिंग, सफल, असफल) की स्थिति को अलग करने के लिए एक एक्शनस्टोर बनाया है। लेकिन मुझे नहीं पता कि यह Redux/Flux के आधार के विरुद्ध है या नहीं। मैंने इसके बारे में स्टैक ओवरफ्लो में पोस्ट किया है।

@gabrielgiussi मुझे लगता है कि https://github.com/acdlite/redux-promise राज्य में वादों को पूरा किए बिना आप जो चाहते हैं उसे भी प्राप्त कर सकते हैं। राज्य को हर समय धारावाहिक माना जाता है।

@wmertens सलाह के लिए धन्यवाद। मैं रेपो को देख लूंगा लेकिन मेरा राज्य क्रमबद्ध क्यों नहीं होगा? या आप इसे केवल इसलिए कहते हैं क्योंकि मैं नोट करता हूँ?

@gabrielgiussi मैंने बहुत करीब से नहीं देखा लेकिन ऐसा लग रहा था कि आप थे
स्टोर में वादे या कार्य करना। किसी भी मामले में, वह परियोजना
मुझे भी अच्छा काम करना चाहिए।

सोम, 10 अगस्त, 2015, पर 19:15 gabrielgiussi [email protected] लिखा है:

@wmertens https://github.com/wmertens सलाह के लिए धन्यवाद। मे लूँगा
रेपो पर एक नज़र डालें लेकिन मेरा राज्य क्रमबद्ध क्यों नहीं होगा? या आप
यह केवल इसलिए कहो क्योंकि मैं नोट करता हूँ?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/gaearon/redux/issues/99#issuecomment -129531103।

वाउट।
(मोबाइल पर टाइप किया, संक्षिप्तता का बहाना)

असल में, स्टोर में मैंने कस्टम एक्शन ऑब्जेक्ट्स रखे हैं, वे सिर्फ अपरिवर्तनीय हैं। साधारण विशेषताओं (आईडी, राज्य, पेलोड) के साथ रिकॉर्ड करें और एक एक्शन ट्रिगर जो एक वादा बनाता है और देता है, इसलिए मैं स्टोर में वादे नहीं डाल रहा हूं। लेकिन मैं शायद कहीं और कुछ तोड़ रहा हूँ, जेई। धन्यवाद @wmertens।

@gabrielgiussi

और एक क्रिया ट्रिगर जो एक वादा बनाता और लौटाता है

राज्य में कार्यों या कुछ और जो क्रमबद्ध नहीं है, न डालें।

माफ़ करना। मैंने कहने की कोशिश की

और एक फ़ंक्शन ट्रिगर जो एक वादा बनाता है और देता है

मैं वास्तव में स्टोर में जो डाल रहा हूं वह एक एक्शन ऑब्जेक्ट है (नाम सबसे अच्छा नहीं था):

export default class Action extends Immutable.Record({state: 'idle', api: null, type: null, payload: null, id: null}){
load(){
  return this.set('state','loading');
}

succeed(){
  return this.set('state','succeeded');
}

fail(){
  return this.set('state','failed');
}

ended(){
  return this.get('state') != 'loading' && this.get('state') != 'idle';
}

endedWithSuccess(){
  return this.get('state') == 'succeeded';
}

endedWithFailure(){
  return this.get('state') == 'failed';
}

trigger() {
  return (dispatch) => {
    dispatch({type: this.get('type') + '_START', action: this});
    let payload = this.get('payload');
    this.get('api').call({dispatch,payload}).then((result) => {
      dispatch({type: this.get('type') + '_SUCCESS',id: this.get('id'), result: result.result});
    }).catch((result) => {
        dispatch({type: this.get('type') + '_FAIL',id: this.get('id'), result: result.result});
      });
  }
}
}

मैंने इस समस्या को हल करने के लिए एक पुस्तकालय बनाया है (देखें #539) यह लंबित कार्यों के लिए मिडलवेयर रिटर्न वादे और उन सभी वादों के हल होने की प्रतीक्षा करके काम करता है।

@gaearon इस कोड को आपने https://github.com/rackt/redux/issues/99#issuecomment -112212639 लिखा है,

क्या यह ऐसा कुछ है जिसमें रेडक्स लाइब्रेरी शामिल है या यह कुछ ऐसा है जिसे मुझे मैन्युअल रूप से बनाना है? क्षमा करें यदि यह एक नया प्रश्न है, तो बस रिएक्ट/फ्लक्स (रेडक्स) में आ रहा है। अभी इस ट्यूटोरियल को शुरू किया है https://github.com/happypoulp/redux-tutorial

@ बैंडरसन5144

यह शामिल नहीं है। यह सिर्फ आपको एक विचार देने के लिए है कि आप क्या कर सकते हैं-लेकिन आप इसे अलग तरीके से करने के लिए स्वतंत्र हैं।
कुछ ऐसा ही https://github.com/pburtchaell/redux-promise-middleware के रूप में प्रकाशित हुआ था

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

• आप एक नए उपयोगकर्ता के लिए संग्रह स्थिति रीसेट करें
• उपयोगकर्ता को स्टोर और एचटीएमएल देने से पहले आप कुछ एसिंक क्रियाओं को पूरा करने की प्रतीक्षा करते हैं
• किसी अन्य उपयोगकर्ता के लिए पहले से चल रही async क्रिया पूर्ण हो जाती है और आपका स्टोर प्रदूषित हो जाता है

आप लोगों ने इसे कैसे हल किया/कोई विचार है कि कैसे करें? इसके बजाय प्रत्येक उपयोगकर्ता के लिए बस एक नया स्टोर काम करेगा?

क्या आप सर्वर प्रतिपादन के बारे में बात कर रहे हैं? हर अनुरोध पर एक नया स्टोर बनाएं। हमारे पास डॉक्स में सर्वर रेंडरिंग के लिए एक गाइड है।

धन्यवाद मैं वह करूँगा

समझने की कोशिश के बाद...

• https://github.com/ForbesLindesay/redux-wait
• https://github.com/erikras/react-redux-universal-hot-example/

क्या यह बहुत भोला है? (ऐसा कोई और नहीं करता है - मुझे लगता है)

// server.js
app.use(function (req, res) {
    match({…}, function (error, redirectLocation, renderProps) {
        …

        if (renderProps) {
            const store = configureStore();

            const promises = renderProps.components.map(function (component, index) {
                if (typeof component.fetchData !== 'function') {
                    return false;
                }

                return component.fetchData(store.dispatch);
            });

            Promise.all(promises).then(function () {
                res.status(200).send(getMarkup(store, renderProps));
            });
        }
    })
});

// home.js
export class Home extends Component {
    static fetchData() {
        return Promise.all([
            dispatch(asyncAction);
        ]);
    },

    componentDidMount() {
        const { dispatch } = this.props;

        Home.fetchData(dispatch);
    }
}

export default connect()(Home);

// action.js
export function asyncAction() {
    return (dispatch, getState) => {
        dispatch(request);

        return fetch(…)
            .then(response => response.json())
            .then(data => dispatch(requestSuccess(data)))
        ;
    }
}

मैं @mattybow के प्रश्न https://github.com/rackt/redux/issues/99#issuecomment -112980776 (डेटा लाने का प्रबंधन करने वाले नेस्टेड घटक) के समाधान का पता लगाने की कोशिश कर रहा था, लेकिन ऐसी कोई सफलता नहीं थी (नहीं थी) सुनिश्चित करें कि componentWillMount से वादों को कैसे एकत्र किया जाए)।

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

इसे पूरा करने के लिए आपके समाधान काफी अच्छे लगते हैं। क्या यह आपके लिए कारगर रहा? धन्यवाद

संपादित करें: मैं सही हूं कि "घटकडिडमाउंट" क्लाइंट पर फिर से ट्रिगर नहीं होता है जब इसे सर्वर पर प्रस्तुत किया जाता है?

@ ms88privat मुझे अभी तक समाधान पर अधिक प्रतिक्रिया नहीं मिली है, न ही इसकी सीमाओं का परीक्षण किया है।

हालांकि, ऊपर दिए गए समाधान के लिए प्रत्येक पृष्ठ को अपने सभी बच्चों के घटकों के डेटा को जानना आवश्यक है। मैंने नेस्टेड घटकों को डेटा प्रबंधन के बारे में चिंता करने में गहराई से नहीं खोला है (नेस्टेड वादों को इकट्ठा करने के कारण)।

ऐसा लगता है कि आप वही कर रहे हैं जो आप उम्मीद करेंगे, इसलिए यह मेरे लिए अभी के लिए काफी अच्छा है।

componentDidMount फिर से चालू हो जाएगा (देखें https://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount)। आप इस या किसी अन्य जीवनचक्र पद्धति का उपयोग कर सकते हैं जो आपकी आवश्यकताओं के अनुरूप हो।

यदि स्टोर पहले से ही भरा हुआ है (या जो भी व्यावसायिक तर्क आप फिट देखते हैं) मैं fetch कोड को निष्पादित करने से रोककर इसे प्राप्त करता हूं।

मैं किस बारे में बात कर रहा हूं, इसका अंदाजा लगाने के लिए https://github.com/reactjs/redux/blob/master/examples/async/actions/index.js#L47 की जांच

@ केमोइश

अगर स्टोर पहले से ही भरा हुआ है तो मैं लाने के कोड को निष्पादित करने से रोककर इसे प्राप्त करता हूं

ठीक है, मुझे वह मिल गया। धन्यवाद।

हालांकि, ऊपर दिए गए समाधान के लिए प्रत्येक पृष्ठ को अपने सभी बच्चों के घटकों के डेटा को जानना आवश्यक है।

हो सकता है कि मैंने आपके समाधान को गलत तरीके से पढ़ा हो, लेकिन क्या सर्वर-साइड रेंडरिंग की परवाह किए बिना यह एक आवश्यक आवश्यकता नहीं है? (उदाहरण के लिए इसे उसी स्थिति को प्रस्तुत करना चाहिए, अगर मैं वर्तमान मार्ग पर रीफ्रेश करता हूं, भले ही वह एक एसपीए हो)

यह होगा, लेकिन आप चाहते हैं कि एक नेस्टेड घटक किसी भी कारण से अपने स्वयं के डेटा लाने का प्रबंधन करे।

उदाहरण के लिए, एक घटक जिसे कई पृष्ठों पर दोहराया जाता है, लेकिन प्रत्येक पृष्ठ में अधिक डेटा प्राप्त करने की आवश्यकता नहीं होती है।

@chemoish मुझे यकीन नहीं है कि हम एक ही पृष्ठ पर हैं। मैं यह समझाने की कोशिश करता हूं कि मेरा दृष्टिकोण क्या है।

उदाहरण के लिए मुझे तीन नेस्टेड घटक मिले:

• घटक 1 (स्थिर डेटाFetch1)
  
  
  
  • घटक 2 (स्थिर डेटाFetch2)
  
  
  • घटक3 (स्थिर डेटाFetch3)
  
  

उनमें से प्रत्येक के पास "घटकडिडमाउंट" विधियां हैं, वहां स्वयं के डेटा फ़ेचिंग घोषणाएं हैं (इसके स्थिर डेटा फ़ेचिंग विधि के माध्यम से कार्रवाई भेजना)।

यदि मेरे पास सेवर-साइड रेंडरिंग नहीं है और मैं वर्तमान URL को रीफ्रेश करता हूं, तो मेरे घटक सभी आवश्यक डेटा को बाद में लोड करने के लिए आवश्यक सभी क्रियाओं को माउंट और ट्रिगर करेंगे।

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

क्या आपके पास अपने प्रदान किए गए उदाहरण से आपके match function संदर्भ है? धन्यवाद।

@ ms88privat renderProps.components राउटर घटकों की एक सरणी है, यह उससे अधिक गहराई तक नहीं जाती है। @chemoish का मतलब था कि उनके कार्यान्वयन के साथ आप गहरे घटकों पर डेटा लाने की ज़रूरतों का वर्णन नहीं कर सकते हैं।

@DominicTobias thx, क्या आपके पास इस समस्या का समाधान है? क्या सभी नेस्टेड घटकों को प्राप्त करने की संभावना है?

शायद यह मदद कर सकता है? https://github.com/gaearon/react-side-effect
नेस्टेड तत्वों से सभी मेटा टैग एकत्र करने के लिए प्रयुक्त: https://github.com/nfl/react-helmet

इस चर्चा को फिर से उछालने के लिए खेद है, लेकिन मैंने हाल ही में एसिंक क्रिया के साथ राज्य को भरने की एक ही समस्या में भाग लिया है।

मैं देख सकता हूं कि @erikras ने अपने बॉयलरप्लेट प्रोजेक्ट को redux-async-connect में स्थानांतरित कर दिया। मुझे आश्चर्य है, अगर किसी को दूसरा समाधान मिला?

@vtambourine मैं https://github.com/markdalgleish/reial देख रहा हूं जो काफी मददगार है

हाँ, मैंने इसके माध्यम से देखा है। लेकिन मुझे नहीं मिला, कैसे सुनिश्चित करें कि डेटा
n . पर पुनः आरंभीकरण कोड के बाद दूसरी बार हुक लाना नहीं चलेगा
ग्राहक।
т, १८ मई २०१६ को। 22:54 बजे, शॉन मैथेसन नोटिफिकेशन @github.com
लिखा था:

@vtambourine https://github.com/vtambourine मैं देख रहा हूं
https://github.com/markdalgleish/reial जो काफी मददगार है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/99#issuecomment -198517067

यह भी उत्सुक है कि क्या किसी को इस चुनौती के लिए एक स्थिर समाधान मिल गया है। मुझे @erikras का बॉयलरप्लेट पसंद है, लेकिन जैसा कि @vtambourine ने उल्लेख किया है, यह redux-async-connect में चला गया है, जो ऐसा लगता है कि यह एक स्थिर दीर्घकालिक समाधान नहीं हो सकता है: #81 क्या redux-async-connect मृत है? .

@vtambourine एक कांटा है जो https://github.com/makeomatic/redux-connect पर उपलब्ध है और अच्छी तरह से बनाए रखा है। इसमें कुछ बदलावों के साथ समान एपीआई है, यदि आप रुचि रखते हैं तो इसे देखें

@gaearon द्वारा उल्लिखित मिडलवेयर के साथ

https://github.com/peter-mouland/react-lego-2016#redux -with-promise-middleware

इस दृष्टिकोण के साथ यूनिट टेस्ट एक्शन क्रिएटर कैसे करें?