Redux: एपीआई कॉल को सही जगह पर रखने की कोशिश की जा रही है

यह लगभग सही है, लेकिन समस्या यह है कि आप केवल शुद्ध एक्शन रचनाकारों को कॉल नहीं कर सकते हैं और चीजों को होने की उम्मीद कर सकते हैं_। यह मत भूलो कि आपके एक्शन क्रिएटर केवल ऐसे कार्य हैं जो _what_ को निर्दिष्ट करने की आवश्यकता है।

// CounterActions
export function increment() {
  return { type: INCREMENT }
}


// Some other file
import { increment } from './CounterActions';
store.dispatch(increment()); <--- This will work assuming you have a reference to the Store
increment(); <---- THIS DOESN'T DO ANYTHING! You're just calling your function and ignoring result.


// SomeComponent
import { increment } from './CounterActions';

@connect(state => state.counter) // will inject store's dispatch into props
class SomeComponent {
  render() {
    return <OtherComponent {...bindActionCreators(CounterActions, this.props.dispatch)} />
  }
}


// OtherComponent
class OtherComponent {
  handleClick() {
    // this is correct:
    this.props.increment(); // <---- it was bound to dispatch in SomeComponent

    // THIS DOESN'T DO ANYTHING:
    CounterActions.increment(); // <---- it's just your functions as is! it's not bound to the Store.
  }
}

अब, चलो अपने उदाहरण के लिए मिलता है। पहली बात जो मैं स्पष्ट करना चाहता हूं, वह यह है कि अगर आपको केवल एक ही क्रिया को सिंक्रोनाइज़ करना है और साइड इफेक्ट नहीं है तो आपको async dispatch => {} फॉर्म की आवश्यकता नहीं है ( loginError और loginRequest )।

यह:

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return dispatch => {
    dispatch({ error, type: LOGGED_FAILED });
  };
}

export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    // router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return dispatch => {
    dispatch({ user, type: LOGIN_ATTEMPT });
  };
}

के रूप में सरलीकृत किया जा सकता है

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return { error, type: LOGGED_FAILED };
}

// You'll have a side effect here so (dispatch) => {} form is a good idea
export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    // router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return { user, type: LOGIN_ATTEMPT };
}

दूसरे, आपके reducers को _pure फ़ंक्शन माना जाता है जिसमें साइड इफेक्ट्स नहीं होते हैं। अपने API को reducer से कॉल करने का प्रयास न करें।

यह:

const initialState = new Immutable.Map({
  email: '',
  password: '',
  isLoggingIn: false,
  isLoggedIn: false,
  error: null
}).asMutable(); // <---------------------- why asMutable?

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      console.log(action.user);
      LoginApiCall.login(action.user); // <------------------------ no side effects in reducers! :-(
      return state;
    case LOGGED_FAILED:
      console.log('failed from reducer');
      return state;
    case LOGGED_SUCCESSFULLY:
      console.log('success', action);
      console.log('success from reducer');
      break;
    default:
      return state;
  }

शायद और अधिक की तरह दिखना चाहिए

const initialState = new Immutable.Map({
  email: '',
  password: '',
  isLoggingIn: false,
  isLoggedIn: false,
  error: null
});

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      return state.merge({
        isLoggingIn: true,
        isLoggedIn: false,
        email: action.email,
        password: action.password // Note you shouldn't store user's password in real apps
      });
    case LOGGED_FAILED:
      return state.merge({
        error: action.error,
        isLoggingIn: false,
        isLoggedIn: false
      });
    case LOGGED_SUCCESSFULLY:
      return state.merge({
        error: null,
        isLoggingIn: false,
        isLoggedIn: true
      });
      break;
    default:
      return state;
  }

अंत में, आप लॉग इन एपीआई कॉल को कहां रखते हैं?

यह ठीक वही है जो dispatch => {} एक्शन क्रिएटर के लिए है। दुष्प्रभाव!

यह सिर्फ एक और एक्शन क्रिएटर है। इसे अन्य क्रियाओं के साथ रखें:

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return { error, type: LOGGED_FAILED };
}

export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return { user, type: LOGIN_ATTEMPT };
}

export function login(userData) {
  return dispatch =>
    fetch('http://localhost/login', {
      method: 'post',
      headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        email: userData.email,
        password: userData.password,
      }),
    })
    .then(response => {
      if (response.status >= 200 && response.status < 300) {
        console.log(response);
        dispatch(loginSuccess(response));
      } else {
        const error = new Error(response.statusText);
        error.response = response;
        dispatch(loginError(error));
        throw error;
      }
    })
    .catch(error => { console.log('request failed', error); });
}

अपने घटकों में, बस कॉल करें

this.props.login(); // assuming it was bound with bindActionCreators before

// --or--

this.props.dispatch(login()); // assuming you only have dispatch from Connector

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

मैंने ऊपर वर्णित तकनीक ( dispatch => {} हस्ताक्षर के साथ एक्शन क्रिएटर्स) को अभी Redux में शामिल किया है, लेकिन 1.0 में केवल एक अलग पैकेज के रूप में उपलब्ध होगा जिसे Redux -thunk कहा जाता है। जब आप इस पर होते हैं, तो आप Redux-वादा-मिडलवेयर या Redux- वादा की जाँच कर सकते हैं।

@ शैयरॉन : क्लैप: यह एक अद्भुत व्याख्या थी! ;) यह निश्चित रूप से डॉक्स में बनाना चाहिए।

@ बेयरन का जबरदस्त स्पष्टीकरण! : ट्रॉफी:

@gaearon क्या होगा यदि आपको यह निर्धारित करने के लिए कुछ तर्क करने की आवश्यकता है कि एपीआई कॉल किसे कहा जाए? क्या यह डोमेन लॉजिक नहीं है जो एक जगह (रिड्यूसर) में होना चाहिए? एक्शन क्रिएटर्स में रखते हुए मुझे लगता है कि सत्य के एकल स्रोत को तोड़ने जैसा है। इसके अलावा, ज्यादातर आपको एप्लिकेशन स्टेट से कुछ मूल्य द्वारा एपीआई कॉल को पैरामीशन करने की आवश्यकता होती है। आप सबसे अधिक संभावना यह भी चाहते हैं कि किसी तरह तर्क का परीक्षण किया जाए। हमने बड़े पैमाने के प्रोजेक्ट में Reducers (परमाणु प्रवाह) में API कॉल करना बहुत सहायक और परीक्षण योग्य पाया ।

हमने बड़े पैमाने पर परियोजना में Reducers (परमाणु प्रवाह) में API कॉल करना बहुत सहायक और परीक्षण योग्य पाया।

यह रिकॉर्ड / रिप्ले को तोड़ता है। साइड इफेक्ट्स वाले कार्य परिभाषा द्वारा शुद्ध कार्यों की तुलना में कठिन हैं। आप Redux का उपयोग इस तरह कर सकते हैं लेकिन यह पूरी तरह से इसके डिजाइन के खिलाफ है। :-)

एक्शन क्रिएटर्स में रखते हुए मुझे लगता है कि सत्य के एकल स्रोत को तोड़ने जैसा है।

"सत्य का एकल स्रोत" का अर्थ है कि डेटा एक ही स्थान पर रहता है, और इसकी कोई स्वतंत्र प्रतियां नहीं हैं। इसका मतलब यह नहीं है कि "सभी डोमेन तर्क एक ही स्थान पर होने चाहिए"।

क्या होगा यदि आपको यह निर्धारित करने के लिए कुछ तर्क करने की आवश्यकता है कि एपीआई कॉल किसे कहा जाए? क्या यह डोमेन लॉजिक नहीं है जो एक जगह (रिड्यूसर) में होना चाहिए?

Reducers निर्दिष्ट करते हैं कि क्रियाओं द्वारा राज्य कैसे रूपांतरित होता है। उन्हें इस बात की चिंता नहीं करनी चाहिए कि ये क्रियाएँ कहाँ से उत्पन्न होती हैं। वे घटकों, एक्शन क्रिएटर्स, रिकॉर्डेड क्रमबद्ध सत्र आदि से आ सकते हैं। यह क्रियाओं का उपयोग करने की अवधारणा की सुंदरता है।

कोई भी एपीआई कॉल (या तर्क जो यह निर्धारित करता है कि एपीआई कहा जाता है) reducers से पहले होता है। यही कारण है कि Redux मिडलवेयर को सपोर्ट करता है। ऊपर वर्णित थन मिडलवेयर आपको स्टेटस का उपयोग करने और यहां तक ​​कि राज्य से पढ़ने की सुविधा देता है:

// Simple pure action creator
function loginFailure(error) {
  return { type: LOGIN_FAILURE, error };
}

// Another simple pure action creator
function loginSuccess(userId) {
  return { type: LOGIN_SUCCESS, userId };
}

// Another simple pure action creator
function logout() {
  return { type: LOGOUT };  
}


// Side effect: uses thunk middleware
function login() {
  return dispatch => {
    MyAwesomeAPI.performLogin().then(
      json => dispatch(loginSuccess(json.userId)),
      error => dispatch(loginFailure(error))
    )
  };
}


// Side effect *and* reads state
function toggleLoginState() {
  return (dispatch, getState) => {
    const { isLoggedIn } = getState().loginState;
    if (isLoggedIn) {
      dispatch(login());
    } else {
      dispatch(logout());
    }
  };
}

// Component
this.props.toggleLoginState(); // Doesn't care how it happens

साइड इफेक्ट करने और एक दूसरे के पूरक के लिए एक्शन क्रिएटर्स और मिडलवेयर _design_ हैं।
Reducers सिर्फ राज्य मशीनें हैं और इनका async से कोई लेना-देना नहीं है।

Reducers निर्दिष्ट करते हैं कि क्रियाओं द्वारा राज्य कैसे रूपांतरित होता है।

यह वास्तव में बहुत मान्य बिंदु है, धन्यवाद।

जब तक इसका कोई संस्करण डॉक्स में नहीं होता, तब तक मैं पोस्टपार्टी के लिए फिर से खोल देता हूं।

: +1:

मैं तर्क दूंगा कि रिड्यूसर राज्य मशीन होते हैं, इसलिए सामान्य रूप से एक्शन क्रिएटर होते हैं (लेकिन स्पष्ट रूप से)।

कहते हैं कि उपयोगकर्ता ने दो बार "सबमिट" बटन क्लिक किया। पहली बार जब आप सर्वर (एक्शन क्रिएटर) में HTTP रिक्वेस्ट भेजेंगे और स्टेट को "सबमिट करने" (रिड्यूसर में) में बदल देंगे। दूसरी बार जब आप ऐसा नहीं करना चाहते।

वर्तमान मॉडल में आपके एक्शन क्रिएटर को यह चुनना होगा कि वर्तमान स्थिति के आधार पर कौन सी क्रियाएं प्रेषण की जानी चाहिए। यदि यह वर्तमान में "सबमिट" नहीं है - तो HTTP अनुरोध भेजें और एक कार्रवाई भेजें, अन्यथा - बस कुछ भी न करें या यहां तक ​​कि अलग-अलग कार्रवाई (जैसे चेतावनी) को भेजें।

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

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

https://github.com/Day8/re-frame विभिन्न दृष्टिकोणों का एक उदाहरण है जहां उनके पास एकल ईवेंट हैंडलर है जो एकमात्र FSM के रूप में कार्य करता है।

लेकिन फिर रेड्यूसर के दुष्प्रभाव होते हैं। तो यह दिलचस्प है कि वे ऐसे मामलों में "रीप्ले" सुविधा से कैसे निपटते हैं - उनसे https://github.com/Day8/re-frame/issues/86 में पूछा गया

सामान्य तौर पर, मुझे लगता है कि यह एक वास्तविक समस्या है और यह आश्चर्य की बात नहीं है कि यह बार-बार प्रकट होता है। यह देखना दिलचस्प है कि आखिरकार क्या समाधान निकलेंगे।

हमें री-फ्रेम और साइड इफेक्ट्स के बारे में पोस्ट करते रहें!

मेरी पुस्तक में किसी भी सभ्य Redux वेब ऐप में 3 राज्य प्रकार हैं।

1) घटक देखें (इस पर प्रतिक्रिया करें)। इसे टाला जाना चाहिए लेकिन कभी-कभी मैं सिर्फ कुछ व्यवहार को लागू करना चाहता हूं जो कि Redux के स्वतंत्र रूप से एक घटक का पुन: उपयोग करके पुन: उपयोग किया जा सकता है।

2) ऐप साझा स्थिति, यानी Redux.state। यह बताता है कि उपयोगकर्ता को एक ऐप पेश करने के लिए एक दृश्य परत का उपयोग किया जाता है और देखने वाले घटक इसे एक दूसरे के बीच "संवाद" करने के लिए उपयोग करते हैं। और इस राज्य का उपयोग एक्शन क्रिएटर्स, मिडलवेर्स के बीच "संवाद" करने के लिए किया जा सकता है, क्योंकि वे निर्णय इस राज्य पर निर्भर कर सकते हैं। इसलिए "साझा" महत्वपूर्ण है। हालांकि यह एक पूर्ण एप्लिकेशन स्थिति नहीं है। या मुझे लगता है कि इस प्रकार की स्थिति (कार्यों के संदर्भ में) के रूप में सब कुछ लागू करना अव्यावहारिक है।

3) राज्य जो अन्य साइड-इफ़ेक्टिंग कॉम्प्लेक्स मॉड्यूल / लिबास / सेवाओं द्वारा आयोजित किया जाता है। मैं लिखता हूँ इन परिदृश्यों को संभालने के लिए vladar वर्णन कर रहा है। या प्रतिक्रिया-राउटर एक और उदाहरण है। आप इसे एक ब्लैक-बॉक्स के रूप में मान सकते हैं, जिसका अपना राज्य है या आप प्रतिक्रिया-राउटर राज्य के हिस्से को ऐप साझा राज्य (Redux.state) में साझा करने का निर्णय ले सकते हैं। अगर मैं एक जटिल HTTP मॉड्यूल लिखूंगा जो बड़ी चतुराई से मेरे सभी अनुरोधों और उसके समय को संभाल लेगा, तो मैं आमतौर पर Redux.state में अनुरोध के समय के विवरण में दिलचस्पी नहीं रखता। मैं केवल ActionCreators / Middlewares के इस मॉड्यूल का उपयोग करूँगा, संभवतः Redux.state के साथ मिलकर नया Redux.state प्राप्त कर सकता है।

अगर मैं अपने अनुरोध के समय को दर्शाने वाले घटक लिखना चाहूंगा तो मुझे Redux.state को यह स्थिति प्राप्त करनी होगी।

@vladar क्या इसका मतलब है कि एसी / मेगावाट अंतर्निहित राज्य मशीन हैं? ऐसा इसलिए है क्योंकि वे स्वयं राज्य नहीं रखते हैं, लेकिन वे अभी भी कहीं और आयोजित राज्य पर निर्भर हैं और वे नियंत्रण तर्क को परिभाषित कर सकते हैं कि यह राज्य समय में कैसे विकसित होते हैं? कुछ मामलों के लिए, मुझे लगता है कि वे अभी भी क्लोजर के रूप में लागू किए जा सकते हैं और अपने राज्य का आयोजन कर सकते हैं, स्पष्ट राज्य मशीनें बन सकती हैं?

वैकल्पिक रूप से मैं Redux.state को "सार्वजनिक राज्य" कह सकता हूं, जबकि अन्य राज्य निजी हैं। मेरे ऐप को कैसे डिज़ाइन किया जाए, यह तय करने के लिए एक अधिनियम है कि एक निजी राज्य के रूप में क्या रखा जाए और एक सार्वजनिक राज्य के रूप में क्या रखा जाए। यह मुझे एनकैप्सुलेशन के लिए अच्छे अवसर की तरह लगता है, इसलिए मैं इसे अलग-अलग स्थानों में विभाजित करने के लिए समस्याग्रस्त नहीं देखता हूं क्योंकि यह एक नरक नहीं बनता है कि वे एक-दूसरे को कैसे प्रभावित करते हैं।

@vladar

लेकिन फिर रेड्यूसर के दुष्प्रभाव होते हैं। तो यह दिलचस्प है कि वे ऐसे मामलों में "रीप्ले" सुविधा से कैसे निपटते हैं

आसान रीप्ले हासिल करने के लिए कोड को निर्धारक होना पड़ता है। यह वही है जो Redux शुद्ध reducers की आवश्यकता होती है। एक प्रभाव में Redux.state एप्लिकेशन को गैर-नियतात्मक (async) और निर्धारक भागों में विभाजित करता है। आप Redux.state के ऊपर bahavior को फिर से देख सकते हैं मान लें कि आप दृश्य घटकों में पागल काम नहीं करते हैं। नियतात्मक कोड को प्राप्त करने के लिए पहला महत्वपूर्ण लक्ष्य है, async कोड को दूर ले जाना और इसे क्रिया लॉग के माध्यम से सिंक्रोनस कोड में अनुवाद करना। यह वह है जो फ्लक्स वास्तुकला सामान्य रूप से करता है। लेकिन सामान्य तौर पर यह पर्याप्त नहीं है और अन्य साइड-इफ़ेक्टिंग या म्यूटिंग कोड अभी भी नियतात्मक प्रसंस्करण को तोड़ सकते हैं।

साइड-इफ़ेक्टेड रिड्यूसर्स के साथ रीप्ले-क्षमता को प्राप्त करना या तो अव्यवहारिक रूप से कठिन है, यहां तक ​​कि असंभव है या यह संभवत: थोड़े व्यावहारिक प्रभाव के साथ कई कोने के मामलों में आंशिक रूप से काम करेगा।

आसान समय-सारिणी को प्राप्त करने के लिए हम Redux में किए गए कार्यों को दोहराने के बजाय ऐप स्टेट के स्नैपशॉट संग्रहीत करते हैं (जो हमेशा कठिन होता है)।

आसान समय-सारिणी को प्राप्त करने के लिए हम Redux में किए गए कार्यों को दोहराने के बजाय ऐप स्टेट के स्नैपशॉट संग्रहीत करते हैं (जो हमेशा कठिन होता है)।

Redux DevTools स्नैपशॉट और एक्शन दोनों को स्टोर करता है। यदि आपके पास क्रियाएँ नहीं हैं, तो आप reducers को पुनः लोड नहीं कर सकते। यह DevTools सक्षम वर्कफ़्लो की सबसे शक्तिशाली विशेषता है।

समय यात्रा अशुद्ध एक्शन रचनाकारों के साथ ठीक काम करती है क्योंकि _इट प्रेषण (अंतिम) कच्ची क्रियाओं के स्तर पर होता है। ये सादे वस्तुएं हैं इसलिए वे पूरी तरह से नियतात्मक हैं। हां, आप API कॉल को "रोलबैक" नहीं कर सकते, लेकिन मुझे इसमें कोई समस्या नहीं है। आप इसके द्वारा उत्सर्जित कच्चे कार्यों को रोलबैक कर सकते हैं।

ऐसा इसलिए है क्योंकि वे स्वयं राज्य नहीं रखते हैं, लेकिन वे अभी भी कहीं और आयोजित राज्य पर निर्भर हैं और वे नियंत्रण तर्क को परिभाषित कर सकते हैं कि यह राज्य समय में कैसे विकसित होते हैं?

हाँ, ठीक यही मेरा मतलब है। लेकिन आप अपने नियंत्रण तर्क के दोहराव के साथ भी समाप्त हो सकते हैं। समस्या को प्रदर्शित करने के लिए कुछ कोड (मेरे उदाहरण से ऊपर डबल सबमिट क्लिक के साथ)।

function submit(data) {
  return (dispatch, getState) => {
    const { isSubmitting } = getState().isSubmitting;
    if (!isSubmitting) {
      dispatch(started(data));

      MyAPI.submit(data).then(
        json => dispatch(success(json)),
        error => dispatch(failure(error))
      )
    }
  }
}

function started(data) {
   return { type: SUBMIT_STARTED, data };
}

function success(result) {
  return { type: SUBMIT_SUCCESS, result };
}

function failure(error) {
  return { type: SUBMIT_FAILURE, error };
}

और फिर आपके पास फिर से "राज्य को स्वीकार" करने के लिए आपका reducer है

const initialState = new Immutable.Map({
  isSubmitting: false,
  pendingData: null,
  error: null
});

export default function form(state = initialState, action) {
  switch (action.type) {
    case SUBMIT_STARTED:
      if (!state.isSubmitting) {
        return state.merge({
          isSubmitting: true,
          pendingData: action.data
        });
      } else {
        return state;
      }
  }
}

इसलिए आप दो स्थानों पर एक ही तार्किक जांच करते हैं। इस उदाहरण में स्पष्ट रूप से दोहराव न्यूनतम है, लेकिन अधिक जटिल सुंदर के लिए यह सुंदर नहीं हो सकता है।

मुझे लगता है कि आखिरी उदाहरण में चेक _not_ reducer के अंदर होना चाहिए। अन्यथा यह जल्दी से असंगतता में उतर सकता है (जैसे कार्रवाई गलती से भेज दी जाती है, लेकिन नजरअंदाज कर दिया जाता है, लेकिन फिर "सफलता" कार्रवाई भी भेज दी जाती है लेकिन यह अप्रत्याशित था, और राज्य गलत तरीके से विलय हो सकता है)।

(क्षमा करें यदि वह बिंदु था जो आप बना रहे थे; ;-)

मैं गैरों के साथ सहमत हूं क्योंकि isSubmitting पहले से ही इस तथ्य में एन्कोडेड है कि SUBMIT_STARTED कार्रवाई भेज दी गई है। जब कोई क्रिया किसी तर्क का परिणाम होती है तो उस तर्क को reducer में दोहराया नहीं जाना चाहिए। तब reducer जिम्मेदारी सिर्फ यह है कि जब कभी भी यह SUBMIT_STARTED प्राप्त करता है तो यह नहीं सोचता है और कार्रवाई पेलोड के साथ केवल अपडेट करता है क्योंकि किसी और ने यह निर्णय लेने के लिए जिम्मेदारी ली थी कि SUBMIT_STARTED।

व्यक्ति को हमेशा यह लक्ष्य रखना चाहिए कि एक ही बात है जो किसी एक निर्णय की जिम्मेदारी लेती है।

Reducer तब SUBMIT_STARTED तथ्य पर आगे निर्माण कर सकता है और इसे अतिरिक्त तर्क के साथ बढ़ा सकता है लेकिन यह तर्क अलग होना चाहिए। फे:

case SUBMIT_STARTED:
  if (goodMood) loading...
  else nothing_happens

मैं सोच सकता हूं कि यह तय करना कभी-कभी मुश्किल हो सकता है कि किसके लिए जिम्मेदार होना चाहिए। एक्शन क्रिएटर, मिडलवेयर, स्टैंडअलोन कॉम्प्लेक्स मॉड्यूल, रिड्यूसर?

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

AC सीधे स्थिति को म्यूट नहीं कर सकता है। इसलिए, यदि इसका तर्क इस पर निर्भर करता है कि AC को इस बात की गारंटी है कि state.isSubmitting इसके तर्क के साथ सम्‍मिलित होगी। यदि एसी तर्क राज्य सेट करना चाहता है। नए डेटा के साथ सही करने के लिए सबमिट किया गया है और यह वापस आ गया है तो उम्मीद है कि यह इस तरह सेट है। संभावित रूप से इस आधार को बदलने वाले अन्य तर्क नहीं होने चाहिए। क्रिया ही सिंक आदिम है। मूल रूप से क्रियाएं प्रोटोकॉल को परिभाषित करती हैं और प्रोटोकॉल को अच्छी तरह से और स्पष्ट रूप से परिभाषित किया जाना चाहिए।

लेकिन मुझे लगता है कि मुझे पता है कि आप क्या कहना चाह रहे हैं। Redux.state साझा स्थिति है। साझा स्थिति हमेशा मुश्किल होती है। रीड्यूसर में कोड लिखना आसान है जो राज्य को एक तरह से बदलता है जो एसी लॉजिक द्वारा अप्रत्याशित है। इसलिए मैं सोच सकता हूं कि एसी और रेड्यूसर के बीच तर्क को कुछ बहुत ही जटिल परिदृश्यों में रखना मुश्किल हो सकता है। इससे कीड़े हो सकते हैं, जिनका पालन करना और डिबग करना मुश्किल हो सकता है। मेरा मानना ​​है कि इस तरह के परिदृश्यों के लिए एसी / मिडलवेयर के लिए लॉजिक को ध्वस्त करना और केवल बिना किसी तर्क या छोटे तर्क के साथ अच्छी तरह से परिभाषित क्रियाओं के आधार पर केवल मूर्खतापूर्ण कार्य करना संभव है।

कोई भी हमेशा नया reducer जोड़ सकता है जो कुछ पुराने आश्रित एसी को तोड़ देगा। Redux.state पर निर्भर एसी बनाने से पहले एक बार दो बार सोचना चाहिए।

मेरे पास एक एक्शन क्रिएटर है जिसके लिए उपयोगकर्ता क्रेडेंशियल्स के साथ एक एपीआई अनुरोध द्वारा लौटाए गए प्रमाणीकरण टोकन की आवश्यकता होती है। इस टोकन की एक समय सीमा है और इसे किसी चीज से ताज़ा और प्रबंधित करने की आवश्यकता है। आप जो प्रस्ताव कर रहे हैं, उससे यह प्रतीत होता है कि यह राज्य Redux.state में नहीं है?

कहाँ जाना चाहिए? वैचारिक रूप से यह अपरिवर्तनीय बाहरी राज्य के रूप में रेडक्स स्टोर के निर्माणकर्ता में पारित हो जाता है?

इसलिए मैं सोच सकता हूं कि एसी और रेड्यूसर के बीच तर्क को कुछ बहुत ही जटिल परिदृश्यों में रखना मुश्किल हो सकता है।

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

यदि आप एसी से घटनाओं के उचित क्रम पर भरोसा करते हैं - आप बस अपने राज्य इंजन के कुछ हिस्सों को एसी में स्थानांतरित करते हैं और इसे reducer के साथ जोड़ते हैं।

हो सकता है कि यह सिर्फ वरीयता की बात हो, लेकिन मुझे बहुत अच्छा लगता है जब स्टोर / रिड्यूसर हमेशा लगातार काम करता है और कहीं न कहीं बाहरी चीजों को बनाए रखने के लिए किसी बाहरी चीज पर निर्भर नहीं होता है।

Redux.state पर निर्भर एसी बनाने से पहले एक बार दो बार सोचना चाहिए।

मुझे लगता है कि आप इसे जटिल मामलों में (कुछ साइड इफेक्ट्स को रिड्यूसर / इवेंट-हैंडलर पर स्थानांतरित किए बिना) से नहीं बचा सकते हैं।

ऐसा लगता है कि यह एक ट्रेडऑफ़ है: "ड्रॉपिंग हॉट-रीलोडिंग या रीप्ले फ़ीचर" बनाम "मैनेजिंग स्टेट इन वन प्लेस"। बाद के मामले में आप वास्तविक FSM या स्टेटचैट जैसे री-फ्रेम प्रस्ताव लिख सकते हैं, पूर्व के मामले में यह अधिक तदर्थ नियंत्रण तर्क है जैसा कि फ्लक्स में अभी हमारे पास है।

मैंने री-फ्रेम के माध्यम से (बहुत जल्दी) पढ़ा है और यह कुछ उसी तरह का है जैसे कि कुछ कार्यान्वयन विवरण अंतर के साथ Redux। पुनः-फ़्रेम दृश्य घटक वेधशालाओं पर आधारित होते हैं, घटनाएँ क्रिया होती हैं, पुनः-फ्रेम घटनाओं (क्रियाओं) को सीधे वस्तुओं के रूप में भेजते हैं (वे एक दृश्य घटक में निर्मित होते हैं) रचनाकारों का उपयोग किए बिना, इवेंट हैंडलर शुद्ध होते हैं और वे Redux के समान ही होते हैं reducers।

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

इसका मतलब है कि कोई भी री-फ्रेम ईवेंट रिकॉर्ड नहीं कर सकता है और आसानी से उन्हें रिप्ले कर सकता है।

जब मैं संभावित विसंगतियों के बारे में बात कर रहा था, तो मैंने साझा स्थिति को मूल कारण माना और मेरा मानना ​​है कि री-फ्रेम का एक ही जोखिम है।

अंतर reducers के साथ मध्यवार युग्मन में है। जब मिडवेर्स री-फ्रेम में खत्म होते हैं तो वे सीधे ईवेंट हैंडलर (रिड्यूसर) को परिणाम देते हैं, इस परिणाम को ईवेंट / एक्शन के रूप में दर्ज नहीं किया जाता है, इसलिए पुनरावृत्ति नहीं होती है। मैं कहूंगा कि Redux केवल क्रियाओं के रूप में बीच-बीच में हुक लगाता है, इसलिए मेरा मानना ​​है कि मैं तकनीकी रूप से वही प्राप्त कर सकता हूं जो री-फ्रेम करता है, अधिक टाइपिंग की कीमत पर अधिक लचीलेपन के साथ (क्रियाओं को बनाने के लिए) और शायद इसे करने के लिए अधिक जगह। गलत।

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

मुझे अभी भी और अधिक सोचना है अगर कुछ सरलीकरण (क्रियाओं की घटती मात्रा) के ऊपर री-फ्रेम दृष्टिकोण में एक महत्वपूर्ण लाभ है। मैं मुझे गलत साबित करने के लिए खुला हूं, जैसा कि मैंने कहा है कि मैं इसके माध्यम से जल्दी से पढ़ता हूं।

दरअसल, मैं थोड़ा गलत था। अंतर Redux बनाम री-फ्रेम कार्यान्वयन में नहीं है, लेकिन वास्तव में "जहां आप अपना दुष्प्रभाव डालते हैं"।

यदि आप इवेंट हैंडलर (रेड्यूसर) में ऐसा करते हैं और अपने नियंत्रण प्रवाह को प्रभावित करने के लिए एक्शन क्रिएटर्स को हटाते हैं, तो तकनीकी रूप से कोई अंतर नहीं है - आप Redux में fsm / Statecharts का भी उपयोग कर सकते हैं और एक ही स्थान पर आपका नियंत्रण प्रवाह कर सकते हैं।

लेकिन वास्तव में - एक अंतर है। @gaearon ने इसे बहुत अच्छी तरह से समझाया: Redux को उम्मीद है कि आपके

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

फिर यह दिलचस्प है कि वे रिप्ले कैसे पहुंचते हैं (और यही मैंने https://github.com/Day8/re-frame/issues/86 पर पूछा)।

मैं इसे करने का एकमात्र तरीका मानता हूं जब आपके ईवेंट हैंडलर के साइड इफेक्ट्स हो सकते हैं, तो @ tomkis1 का उल्लेख किया गया है - हर ईवेंट हैंडलर द्वारा लौटाए गए रिकॉर्डिंग स्टेट (हर इवेंट पर

हॉट रीलोडिंग अभी भी काम कर सकता है, सिवाय इसके कि यह "अतीत" की घटनाओं को प्रभावित नहीं कर सकता है - केवल समय में राज्य की कुछ नई शाखा का उत्पादन करता है।

इसलिए डिजाइन में अंतर शायद सूक्ष्म है, लेकिन मेरे लिए यह महत्वपूर्ण है।

मुझे लगता है कि वे साइड इफ़ेक्टिंग मिडलवर्स के साथ शुद्ध ईवेंट हैंडलर्स की रचना करके HTTP अनुरोध करते हैं। यह रचना नए ईवेंट हैंडलर को लौटाती है जो अब शुद्ध नहीं है लेकिन आंतरिक शुद्ध रहता है। मुझे नहीं लगता कि वे इवेंट हैंडलर बनाने की सलाह देते हैं जो ऐप-डीबी (स्टेट) म्यूटेशन और साइड-इफेक्ट्स को मिलाते हैं। यह कोड को अधिक परीक्षण योग्य बनाता है।

यदि आप किसी इवेंट हैंडलर का परिणाम रिकॉर्ड करते हैं तो आप उसे हॉट-रीलोडेबल नहीं बना सकते हैं जिसका अर्थ है कि आप मक्खी पर उसका कोड बदल सकते हैं। आपको मिडलवेयर का परिणाम रिकॉर्ड करना होगा और वही होगा जो Redux करता है - इस परिणाम को एक क्रिया के रूप में रिकॉर्ड करें और इसे reducer (इसे सुनें) पास करें।

मुझे लगता है कि मैं कह सकता हूं कि रि-फ्रेम बिचौलिये सक्रिय हैं जबकि रेडक्स प्रतिक्रियाशीलता की अनुमति देता है (कोई भी तदर्थ reducer मिडलवेयर / एसी के परिणाम को सुन सकता है)। एक बात जो मैं महसूस करना शुरू कर रहा हूं वह यह है कि फ्लक्स और मिडलवेर्स में इस्तेमाल होने वाले एसी कंट्रोलर की तरह ही होते हैं।

जैसा कि मैंने समझा @ tomkis1 राज्य को बचाने के माध्यम से

ठीक है, यह महसूस करते हुए कि रिड्यूसर / इवेंट हैंडलर पूरा नया राज्य लौटाते हैं, इसलिए आपने ऐसा ही कहा।

@merk मैं सोमवार को शायद इसके बारे में अपने विचार लिखने की कोशिश करूंगा क्योंकि मैं शायद एक सप्ताहांत के दौरान यहां नहीं पहुंचता।

ई-फ्रेम डॉक्स ईवेंट हैंडलर में सर्वर से बात करने की सलाह देते हैं: https://github.com/Day8/re-frame#talking -to-a-server

तो यह वह जगह है जहाँ यह Redux से अलग होता है। और यह अंतर पहली नज़र में देखने से ज्यादा गहरा है।

हम्म, मैं Redux से अंतर देखने में विफल रहा हूं:

आरंभ करने वाले इवेंट हैंडलर को व्यवस्थित करना चाहिए कि इन HTTP अनुरोधों के लिए ऑन-सक्सेस या ऑन-फेल हैंडलर केवल एक नई घटना भेजते हैं । उन्हें कभी भी ऐप-डीबी को स्वयं संशोधित करने का प्रयास नहीं करना चाहिए। जो हमेशा एक हैंडलर में किया जाता है।

ईवेंट को एक्शन से बदलें। Redux में एक शुद्ध इवेंट हैंडलर का एक विशेष नाम है - एक reducer। मुझे लगता है कि मुझे कुछ याद आ रहा है या मेरा दिमाग इस सप्ताहांत में बंद है।

मैं अधिक महत्वपूर्ण अंतर को सूँघ सकता हूँ कि कैसे घटनाओं को अंजाम दिया जाता है - कतारबद्ध और async। मुझे लगता है कि Redux कार्रवाई को समन्वयन और लॉक-स्टेप कार्रवाई को राज्य की स्थिरता की गारंटी देता है। यह आगे चलकर पुन: प्रयोज्यता को प्रभावित कर सकता है क्योंकि मुझे यकीन नहीं है कि अगर घटनाओं को बचाने और उन्हें फिर से दोहराने और फिर से उसी अंतिम स्थिति में परिणाम होगा। अवहेलना करते हुए कि मैं ऐसा नहीं कर सकता क्योंकि मुझे नहीं पता कि कौन सी घटनाएँ Redux में विपरीत प्रभावों को ट्रिगर करती हैं जहां क्रियाएं हमेशा शुद्ध कोड को ट्रिगर करती हैं।

@vladap अंतर को सारांशित करने के लिए जैसा कि मैं इसे देखता हूं:

1।

• Redux में आप एक्शन क्रिएटर में सर्वर अनुरोध शुरू करते हैं (देखें @gaearon इस मुद्दे के मूल प्रश्न का उत्तर); आपके reducers शुद्ध होने चाहिए
• री-फ्रेम में आप इसे इवेंट हैंडलर (रिड्यूसर) में करते हैं; आपके ईवेंट-हैंडलर (रिड्यूसर) के दुष्प्रभाव हो सकते हैं

2।

• पहले मामले में आपका नियंत्रण प्रवाह एसी और रेड्यूसर के बीच विभाजित होता है।
• दूसरे मामले में आपके सभी नियंत्रण प्रवाह एक स्थान पर होते हैं - ईवेंट-हैंडलर (रिड्यूसर)।

3।

• यदि आपका नियंत्रण प्रवाह विभाजित है - आपको एसी और रेड्यूसर के बीच समन्वय की आवश्यकता है (भले ही यह निहित हो): एसी रीड्यूसर द्वारा उत्पादित राज्य को पढ़ता है; reducer एसी से घटनाओं के उचित क्रम को मानता है। तकनीकी रूप से आप AC और reducer के युग्मन का परिचय देते हैं, क्योंकि reducer में परिवर्तन भी AC और vise versa को प्रभावित कर सकता है।
• यदि आपका नियंत्रण प्रवाह एक स्थान पर है - तो आपको अतिरिक्त समन्वय की आवश्यकता नहीं है
• 
  
  
  
  1. शुद्ध reducers को लागू करने और AC को स्थानांतरित करने के साइड-इफेक्ट होने का Redux तरीका गर्म-पुनः लोड करने और फिर से चलाने में सक्षम बनाता है
  
  
• ईवेंट-हैंडलर (रिड्यूसर) में साइड इफेक्ट होने का पुनः-फ्रेम तरीका फिर से खेलना बंद कर देता है क्योंकि यह Redux में किया जाता है ( रिड्यूस का पुनर्मूल्यांकन करके), लेकिन अन्य (शायद कम शक्तिशाली) विकल्प अभी भी संभव हैं -

देव अनुभव में अंतर के रूप में - यह केवल तब दिखाई देता है जब आपके पास कई एसिंक्स सामान (टाइमर, समानांतर http अनुरोध, वेब सॉकेट, आदि) होते हैं। सिंक सामान के लिए यह सब समान है (क्योंकि एसी में कोई नियंत्रण प्रवाह नहीं है)।

मुझे लगता है कि मुझे अपनी बात को और अधिक स्पष्ट करने के लिए ऐसे जटिल परिदृश्य के कुछ वास्तविक दुनिया उदाहरण तैयार करने की आवश्यकता है।

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

1।

Redux में आप एक्शन क्रिएटर में सर्वर अनुरोध शुरू करते हैं (देखें @gaearon इस मुद्दे के मूल प्रश्न का उत्तर); आपके reducers शुद्ध होने चाहिए
री-फ्रेम में आप इसे इवेंट हैंडलर (रिड्यूसर) में करते हैं; आपके ईवेंट-हैंडलर (रिड्यूसर) के दुष्प्रभाव हो सकते हैं

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

देव अनुभव में अंतर के रूप में - यह केवल तब दिखाई देता है जब आपके पास कई एसिंक्स सामान (टाइमर, समानांतर http अनुरोध, वेब सॉकेट, आदि) होते हैं। सिंक सामान के लिए यह सब समान है (क्योंकि एसी में कोई नियंत्रण प्रवाह नहीं है)।

हम इस पर सहमत नहीं हैं। Async सामान वास्तव में कोई फर्क नहीं पड़ता, आप उन्हें Redux में फिर से नहीं कर सकते हैं इसलिए आपके पास यहां कोई देव अनुभव नहीं है। अंतर तब दिखाई देता है जब आपके पास कई जटिल शुद्ध रेड्यूसर होते हैं। Redux में आप स्टेट ए, कुछ एक्शन सीक्वेंस, रिड्यूसर ले सकते हैं, इसे रीप्ले कर सकते हैं और स्टेट बी प्राप्त कर सकते हैं। आप सब कुछ वही रखते हैं लेकिन आप रिड्यूसर में कोड परिवर्तन करते हैं और इसे फिर से लोड करते हैं, राज्य ए और आप से उसी एक्शन सीक्वेंस को दोबारा से लेते हैं। राज्य कोड प्राप्त करें, तुरंत अपने कोड परिवर्तन का प्रभाव देखें। आप इसे @ tomkis1 दृष्टिकोण के साथ नहीं कर सकते।

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

वास्तव में मुझे काफी हैरानी होगी अगर क्लोजुरिस्ट्स मैं लगभग कार्यात्मक प्रोग्रामिंग के कठिन चिकित्सकों को मरने के रूप में मानता हूं क्योंकि हास्केलर कोड के साथ साइड-इफेक्ट्स को मिश्रण करने की सिफारिश करेंगे जो कम से कम रचना के कुछ स्तरों के बिना शुद्ध हो सकते हैं।

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

मुझे समझ नहीं आ रहा है कि मैं एक ही ईवेंट हैंडलर में इस डिस्पैच किए गए इवेंट को कैसे संभाल सकता हूं।

मैं ऐसा नहीं कह रहा हूं। "साइड इफेक्ट्स" से मेरा मतलब है कि इवेंट हैंडलर (रिड्यूसर) में शुरू किए गए HTTP अनुरोध। IO का प्रदर्शन भी साइड इफेक्ट है, भले ही यह आपके फ़ंक्शन की वापसी को प्रभावित न करे। राज्य को सीधे सफलता / त्रुटि संचालकों में संशोधित करने के संदर्भ में "साइड इफेक्ट्स" से मेरा मतलब नहीं है।

यह दूसरा ईवेंट हैंडलर शुद्ध है और Redux Reducer के बराबर है, पहला एक्शन क्रिएटर के बराबर है।

मुझे नहीं लगता कि पहले वाला एक्शन क्रिएटर के बराबर है। अन्यथा आपको एक्शन क्रिएटर्स को ऐसा करने की आवश्यकता क्यों है? यदि आप reducer में एक ही कर सकते हैं?

आप इसे @ tomkis1 दृष्टिकोण के साथ नहीं कर सकते।

इस बात से सहमत। और यही मेरा मतलब था जब मैंने "अन्य (शायद कम शक्तिशाली) विकल्प" लिखा था।

मुझे नहीं लगता कि पहले वाला एक्शन क्रिएटर के बराबर है। अन्यथा आपको एक्शन क्रिएटर्स को ऐसा करने की आवश्यकता क्यों है? यदि आप reducer में एक ही कर सकते हैं?

एक्शन क्रिएटर्स का उपयोग शुद्ध ऐप से साइड-इफेक्ट को अलग करने के लिए किया जाता है (जिसे फिर से चलाया जा सकता है)। जैसा कि Redux को डिज़ाइन किया गया है आप reducers में साइड-इफ़ेक्ट नहीं कर सकते हैं आपको एक और निर्माण की आवश्यकता है जहां आप साइड-इफ़ेक्टिंग कोड रख सकते हैं। Redux में ये निर्माण AC या मिडलवेयर हैं। एकमात्र अंतर जो मुझे री-फ्रेम में दिखाई देता है, वही है जो बिचौलिये करते हैं और हैंडलर के ट्रिगर होने से पहले री-फ्रेम में ईवेंट्स (क्रियाओं) को बदलने के लिए बिचौलिये नहीं होते हैं।

एसी / मिडलवेर्स के बजाय वास्तव में किसी भी चीज का उपयोग किया जा सकता है - उपयोग मॉड्यूल, सेवाओं (जैसे कोणीय सेवाओं), आप इसे एक अलग लिबास के रूप में बना सकते हैं जिसे आप तब एसी या मिडलवेयर द्वारा इंटरफेस करते हैं और इसके एपीआई को कार्यों में अनुवाद करते हैं। यदि आप मुझसे पूछते हैं कि AC इस कोड को रखने के लिए सही जगह नहीं है। AC को केवल साधारण निर्माता / कारखाने होने चाहिए जो तर्क से कार्य वस्तुओं का निर्माण कर रहे हों। यदि मैं एक शुद्धतावादी बनना चाहता हूं तो साइड-इफ़ेक्टिंग कोड को सख्ती से बिचौलियों पर रखना बेहतर होगा। ActionCreator नियंत्रक जिम्मेदारी के प्रकार के लिए एक बुरा शब्द है। लेकिन अगर यह कोड सिर्फ एक-लाइनर वेबपी कॉल है, तो बस एसी के अंदर रखने की प्रवृत्ति है और सरल ऐप के लिए यह ठीक हो सकता है।

AC, midwares, 3rd party libs एक लेयर बनाता है जिसे मैं सर्विस लेयर कहलाना पसंद करता हूं। मूल Facebook WebApiUtils इस परत का हिस्सा होगा, जैसे कि यदि आप प्रतिक्रिया-राउटर का उपयोग करेंगे और इसके बदलावों को सुनेंगे और Redux.state को अपडेट करने के लिए उन्हें क्रियाओं में अनुवाद करेंगे, तो रिले को सर्विस लेयर के रूप में उपयोग किया जा सकता है (ऐप और व्यू से Redux का उपयोग करने के लिए) राज्य)। वर्तमान में अधिकांश 3 पार्टी के कामों को प्रोग्राम किया जाता है, वे फिर से खेलना नहीं करते हैं। जाहिर है मैं खरोंच से सब कुछ फिर से लिखना नहीं चाहता, तो यह होगा। मैं इसके बारे में कैसे सोचना पसंद करता हूं कि ये लिबास, सेवाएं, बर्तन आदि ब्राउज़र वातावरण को एक साथ मिलकर एक मंच बनाते हैं जिसके शीर्ष पर मैं अपने पुन: उपयोग योग्य एप्लिकेशन का निर्माण कर सकता हूं। यह प्लेटफ़ॉर्म साइड-इफ़ेक्ट से भरा है, वास्तव में यह वह जगह है जहाँ मैं जानबूझकर साइड-इफ़ेक्ट ले जाता हूँ। मैं इस प्लेटफ़ॉर्म एपीआई को कार्यों में अनुवाद करता हूं और मेरा ऐप अप्रत्यक्ष रूप से इन एक्शन ऑब्जेक्ट्स (हास्केल दृष्टिकोण को अनुकरण करने की कोशिश कर रहा है जो मैंने ऊपर पोस्ट में वर्णन करने की कोशिश की) को सुनकर इस प्लेटफॉर्म से जुड़ता है। यह कार्यात्मक प्रोग्रामिंग में हैक का एक प्रकार है कि कैसे अभी भी शुद्धता प्राप्त करना है (संभवत: एक पूर्ण अकादमिक अर्थ में नहीं) लेकिन साइड-इफेक्ट को ट्रिगर करता है।

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

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

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

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

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

मुझे समझ नहीं आ रहा है कि मैं एक ही ईवेंट हैंडलर में इस डिस्पैच किए गए इवेंट को कैसे संभाल सकता हूं।
मैं ऐसा नहीं कह रहा हूं।

मैंने सोचा था कि आप reducers तर्क के साथ webapi कॉल को एक जगह पर रखना चाहते हैं। जो मैं कह रहा हूं कि आप इसे री-फ्रेम में नहीं करते हैं क्योंकि वे सफलता पर घटना को भेजने का सुझाव देते हैं।

ऐसी स्थिति हो सकती है जब वेबैपी -> बहुत सारे तर्क -> वेबपी -> बहुत सारे तर्क -> ... ... -> reducer के लिए परिणाम, पूरी श्रृंखला एक क्लिक से चालू हो जाती है। ऐसे मामलों में अधिकांश तर्क संभवतः एसी में होंगे, मैं इसे तब तक नहीं बांटूंगा जब तक कि सभी साइड-इफेक्ट खत्म न हो जाएं। क्या यह आपको संदर्भित है?

मैं यहां जो सबसे अच्छा कर सकता हूं, वह है कि परीक्षण के लिए शुद्ध कार्यों के लिए तर्क के रूप में बहुत कुछ है लेकिन उन्हें एसी दायरे में कहा जाएगा।

यह नहीं लगता कि मुझे अप्रत्यक्ष रूप से जुड़े इवेंट हैंडलर्स की एक श्रृंखला के रूप में करने की संभावना है। यह वादा या वेधशाला श्रृंखला होगी।

अधिक अनुभवी Reduxers कि सोचा पर अलग अलग राय हो सकती है (@gaearon, @johanneslumpe, @acdlite, @emmenko ...)

@vladap मुझे लगता है कि यह बातचीत इस मुद्दे के विषय से बहुत दूर चली गई। आपने मेरी टिप्पणियों के मुख्य बिंदु का पहले ही उल्लेख कर दिया है:

इसलिए मैं सोच सकता हूं कि एसी और रेड्यूसर के बीच तर्क को कुछ बहुत ही जटिल परिदृश्यों में रखना मुश्किल हो सकता है।

त्वरित उदाहरण:

स्थिति 1: आपके पास पृष्ठ पर कहीं शीर्ष -10 ब्लॉग लेखकों की सूची है। अब आपने ब्लॉग में पोस्ट की एक श्रेणी हटा दी है। सफल हटाने पर आपको इसे अप-टू-डेट करने के लिए सर्वर से लेखकों की इस सूची को अपडेट करना होगा।

स्थिति 2: आप एक अलग पृष्ठ पर हैं। इसमें लेखकों की सूची नहीं है, लेकिन इसमें शीर्ष -10 टिप्पणियों की सूची है। आप कुछ ब्लॉग पोस्ट को भी हटा सकते हैं और सफल डिलीट पर टिप्पणियों की सूची अपडेट करनी होगी।

तो हम इसे राज्य-इंजन के स्तर पर कैसे संभालते हैं? (हम कुछ मदद के लिए रिएक्ट हुक का उपयोग भी कर सकते हैं, लेकिन अच्छा राज्य इंजन अपने आप पर लगातार रहने में सक्षम होना चाहिए)

विकल्प:
ए) हमने इस तर्क को एसी में रखा। तब AC CategoryApi (हटाएगा) को स्पर्श करेगा, userList राज्य से और commentList राज्य (अब राज्य में मौजूद कौन-सी सूचियों की जाँच करने के लिए) से पढ़ेगा, UserListApi से बात करेगा CommentListApi (सूचियों को ताज़ा करने के लिए) + TOP_AUTHORS_UPDATED और / या TOP_COMMENTS_UPDATED । तो यह मूल रूप से 3 अलग-अलग डोमेन को स्पर्श करेगा।

बी) हम इसे घटना संचालकों userList और commentList में डालते हैं। ये हैंडलर दोनों DELETE_CATEGORY_SUCCESS ईवेंट सुनेंगे, फिर अपनी API सेवा को कॉल करेंगे और बदले में TOP_AUTHORS_UPDATED / TOP_COMMENTS_UPDATED ईवेंट देंगे। इसलिए प्रत्येक हैंडलर केवल स्वयं के डोमेन की सेवाओं / स्थिति को छूता है।

यह उदाहरण शायद बहुत सरल है, लेकिन इस स्तर पर भी एसी में एपीआई कॉल के साथ चीजें बहुत कम मिलती हैं।

यह अंतर इस तथ्य से आता है कि री-फ्रेम में ईवेंट हैंडलर के विपरीत, एक्शन क्रिटर्स व्यावसायिक तर्क को संभालने में सक्रिय हैं। और DOM इवेंट के आधार पर केवल एक AC को निष्पादित किया जा सकता है। यह शीर्ष-स्तरीय एसी हालांकि अन्य एसी को कॉल कर सकता है। UserListApi और CommentListApi के लिए अलग-अलग AC हो सकते हैं ताकि डोमेन बेहतर रूप से अलग हो जाएं, लेकिन हमेशा AC (नियंत्रक जैसा) होना चाहिए जो उन्हें तार करता है। यह हिस्सा काफी क्लासिक अनिवार्य कोड है जबकि री-फ्रेम पूरी तरह से घटना-आधारित है। थोड़े से काम के साथ इसे पसंदीदा दृष्टिकोण, घटना-आधारित, वेधशालाओं, cps आदि के साथ बदला जा सकता है।

@vladap यह देखना दिलचस्प होगा कि क्या एक और दृष्टिकोण व्यवहार्य है: जब reducers के दुष्प्रभाव हो सकते हैं, लेकिन उन्हें अलग भी कर सकते हैं ताकि उन्हें फिर से खेलना पर नजरअंदाज किया जा सके।

यह कहें कि रिड्यूसर हस्ताक्षर बदल जाएगा: (state, action) => (state, sideEffects?) जहां साइडइफेक्ट्स एक बंद है। फिर संदर्भ ढांचे के आधार पर या तो इन साइडइफेक्ट्स का मूल्यांकन कर सकते हैं या उन्हें अनदेखा कर सकते हैं (रीप्ले के मामले में)।

तब मूल अंक विवरण से उदाहरण इस तरह दिखेगा:

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      return [state, () => {LoginApiCall.login(action.user)}];
    case LOGGED_FAILED:
      // do something
      return state;
    case LOGGED_SUCCESSFULLY:
      // do something else
     return state;
    default:
      return state;
  }
}

(बाकी सब कुछ बहुत समान है)

कम से कम आपका नियंत्रण प्रवाह एक ही स्थान पर है, आपके साइड इफेक्ट्स हमेशा सरल होते हैं (क्योंकि वे async हैंडलर में सिर्फ एक और एक्शन / ईवेंट बनाते हैं, और तर्क रिड्यूसर्स में रहता है - इसलिए आपका अधिक कोड फिर से दोहराया जाएगा)।

आप नियमित FSM या Statechart जैसे कोड (रीड्यूसर / इवेंट-हैंडलर की रचना के साथ) भी लिख सकते हैं

इसके अलावा, आपको एक्शन क्रिएटर्स में पूर्व-निर्धारित हस्ताक्षर के साथ क्लोजर लौटने की आवश्यकता नहीं है।

निश्चित नहीं है कि यह दृष्टिकोण संभावित रूप से क्या समस्याएँ पैदा कर सकता है, लेकिन मेरे लिए यह खेलने के लायक है।

यह कहें कि रिड्यूसर हस्ताक्षर बदल जाएगा: (राज्य, क्रिया) => (राज्य, साइडइफेक्ट्स?) जहां साइडइफेक्ट्स एक बंद है। फिर संदर्भ ढांचे के आधार पर या तो इन साइडइफेक्ट्स का मूल्यांकन कर सकते हैं या उन्हें अनदेखा कर सकते हैं (रीप्ले के मामले में)।

यह वास्तव में ऐसा ही है जैसा मैंने एल्म को (State, Action) => (State, Request?) साथ करते हुए सुना था। मैंने अभी तक कोई उदाहरण नहीं देखा है लेकिन अगर कोई इसका पता लगाना चाहता है तो कृपया बेझिझक करें।

फिर भी एक और दृष्टिकोण संभवतः कुछ प्रेरणा प्राप्त करने के लिए अभिनेता मॉडल के शीर्ष पर eventsourcing के एक कार्यान्वयन है से - अक्का हठ , PersistentFSM । मैं नहीं कहता कि यह बेहतर है लेकिन अन्य प्रयासों को जानना बुरा नहीं है। अभिनेता साइड-इफेक्ट का उपयोग कर सकते हैं लेकिन अगर मुझे सही याद है तो कभी-कभी यह स्पष्ट कोड लिखने की आवश्यकता होती है कि कैसे फिर से खेलना है।

हो सकता है कि रीप्ले फ़ीचर हमारे फ़ैसलों को तिरछा कर रहा हो, जहाँ कोड होता है। ऐसा लगता है कि हम इस बारे में सोचना शुरू कर रहे हैं ... "मैं यह फिर से करना चाहता हूं इसलिए इसे एक reducer पर जाना होगा"। यह अस्पष्ट सीमाओं के साथ एक कोड को जन्म दे सकता है क्योंकि हम इसे इसकी जिम्मेदारियों / भूमिकाओं द्वारा नहीं काट रहे हैं और हम इसे पुन: प्रयोज्य बनाने के लिए अपने व्यापार तर्क को कृत्रिम रूप से स्लाइस करते हैं।

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

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

नकारात्मक पक्ष यह है कि अक्का दृढ़ता के विपरीत मुझे इस कोड को फिर से चलाने के लिए कोई सुविधा नहीं है।

मुझे एक दिन एल्म पर गहराई से विचार करना होगा और समझना होगा कि आपका प्रस्ताव कैसे काम करेगा।

Elga meninging के लिए https://gist.github.com/evancz/44c90ac34f46c63a27ae - समान विचारों (लेकिन बहुत अधिक उन्नत) के साथ।

वे कार्य (http, db, आदि) और प्रभाव (कार्यों की एक कतार) की अवधारणा का परिचय देते हैं। तो आपका "reducer" वास्तव में नए राज्य और प्रभाव वापस कर सकता है।

इसके बारे में अच्छी बात (और मैंने इसके बारे में इस तरह से नहीं सोचा था) - वह यह है कि यदि आप अपने रीड्यूसर का पीछा करते हुए कार्य एकत्र कर सकते हैं - और बाद में इस सूची में कुछ फ़ंक्शन लागू करें। मान लें कि आप http अनुरोधों को बैच सकते हैं, लेनदेन के साथ DB प्रश्नों को लपेट सकते हैं, आदि।

या आप कह सकते हैं, "रीप्ले मैनेजर" कहें जो प्रभाव के लिए सिर्फ एक नॉओप है।

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

सामान्य अनुप्रयोग को टोकन की आवश्यकता नहीं होती है और समाप्ति की समाप्ति एक उपयोगकर्ता को प्रस्तुत की जाती है ताकि तकनीकी रूप से यह Redux.state में न हो। व्यवस्थापन ऐप के पास होना आवश्यक है। इसलिए आप इसे दोनों तरीकों से लागू कर सकते हैं जो भी आपको फिट बैठता है।

एक विकल्प लॉगिन एसी में समाप्ति समाप्ति शुरू करना है और मेरा मानना ​​है कि यह अंतहीन रूप से चलता है और ऐप या लॉगऑफ के साथ मर जाता है। जब अंतराल ट्रिगर करता है तो यह करता है कि टोकन की पुष्टि करने के लिए क्या आवश्यक है और यदि यह समाप्त हो गया है तो यह LOGIN_EXPIRED कार्रवाई को भेजता है और रीड्यूसर को सुनने से उपयोगकर्ता सत्र को साफ करता है और स्थान बदलता है जो बदले में रूटर संक्रमण को / लॉगिन में ट्रिगर करता है।

एक अन्य पक्ष का उपयोग करने के लिए तीसरे पक्ष के दायित्व का उपयोग करना है और चिंताओं को सौंपना है और इसके एपीआई को LOGIN_EXPIRED कार्रवाई में अनुवाद करना है। या अपनी खुद की लिखो और टोकन और उलटी गिनती राज्य यहाँ रखो अगर आपको इसे दृश्य परत में ज़रूरत नहीं है।

आप इसे Redux.state में रख सकते हैं लेकिन यह स्थिति अस्थिर है। बड़े राज्य के साथ हम वैश्विक चर के साथ प्रोग्रामिंग के समान समस्याएं प्राप्त कर सकते हैं। और यह कठिन है, शायद इसका परीक्षण करना असंभव है। रीड्यूसर का परीक्षण करना आसान है, लेकिन तब यह साबित होता है कि जब केवल एक reducer राज्य वस्तु में उस विशेष कुंजी को अपडेट कर रहा है। यह विभिन्न गुणों के कई डेवलपर्स के साथ बड़ी परियोजना में खराब हो सकता है। कोई भी reducer लिखने का फैसला कर सकता है और सोच सकता है कि राज्य का कुछ टुकड़ा अद्यतन करने के लिए अच्छा है और मैं कल्पना नहीं कर सकता कि सभी संभावित अद्यतन अनुक्रमों में सभी reducers को एक साथ कैसे परीक्षण किया जाए।

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

@vladar @vladap

वाह, कि एल्म मुट्ठी शांत शांत है! यह Cycle.js "ड्राइवरों" वास्तुकला की भी याद दिलाता है।

@merk वास्तव में, स्वायत्त LOGIN_EXPIRED रिप्ले को बहुत प्रभावित नहीं करेगा क्योंकि यह एक्शन लॉग के अंत में मिल जाएगा और रीप्ले द्वारा तुरंत संसाधित नहीं किया जाएगा और शायद यह एक्शन लॉग को बिल्कुल नहीं मिलेगा - मुझे नहीं पता कैसे फिर से लागू किया जाता है।

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

@merk : आगे। यदि टोकन और इसकी समाप्ति Redux.state / या कहीं भी किसी अन्य js सेवा में रखी जाएगी, तो उपयोगकर्ता द्वारा नए टैब में ऐप खोलने पर यह स्थानांतरित नहीं होता है। मैं कहूंगा कि उपयोगकर्ता को उम्मीद है कि वह लॉग इन रहेगा। इसलिए मुझे लगता है कि यह राज्य वास्तव में सेशनस्टोर में होना चाहिए।

इसके बिना भी, राज्य अलग हो सकते हैं जब टोकन समाप्ति का मतलब उपयोगकर्ता जानकारी की तत्काल सफाई और / लॉगिन में संक्रमण नहीं है। जब तक उपयोगकर्ता अपने इंटरैक्शन के साथ सर्वर को नहीं छूता (उसके पास पर्याप्त डेटा कैश है) वह काम करना जारी रख सकता है और केवल एक सर्वर की आवश्यकता होने पर कुछ करने के लिए LOGIN_EXPIRED कार्रवाई शुरू हो सकती है। Redux.state पर आधारित पृथक स्थिति का मतलब यह नहीं है कि मान्य टोकन मौजूद है। Redux.state में पृथक राज्य का उपयोग यह तय करने के लिए किया जाता है कि एक टोकन के आसपास की स्थिति को एक दृश्य परत पर छिपाया जा सकता है और पूरी तरह से इसके लिए कार्रवाई और पुनर्खरीद लिखे बिना कार्रवाई करने वाले स्तर पर बनाए रखा जा सकता है, सिवाय उन लोगों के जो एक दृश्य परत को प्रभावित करते हैं।

@vladar मुझे लगता है कि मुझे आपका

कोई आसान तरीका नहीं है कि रिड्यूसर से एक्शन क्रिएटर के लिए नियंत्रण वापस कैसे लौटाया जाए और कुछ मूल्यों को पारित किया जाए। मान लें कि इन मानों को प्रतिपादन के लिए आवश्यक नहीं है, वे अस्थायी भी हैं, लेकिन उन्हें एक async कार्रवाई शुरू करने की आवश्यकता है।

actionCreator() {
  ... getState
  ... some logic L1
  ... dispatch({ACTION1})
}

reducer() {
  case ACTION1
    ... some logic L2
    ... x, y result from L2
    ... some logic L3
    ... resulting in new state
    ... return new state
}

Reducer में गणना की गई x, y का उपयोग करके async कार्रवाई आरंभ करने के 3 विकल्प हैं। उनमें से कोई भी परिपूर्ण नहीं है।

1) एक्शन क्रिएटर के लिए reducer से तर्क को स्थानांतरित करें और हॉट-रीलोड की शक्ति कम करें। Reducer केवल गूंगा राज्य अद्यतनकर्ता है या उसके पास तर्क L3 है।

2) x, y से Redux.state में सेव करें, इसे अस्थायी / क्षणिक मान के साथ प्रदूषित करते हैं और मूल रूप से इसे reducers और एक्शन क्रिएटर्स के बीच एक वैश्विक संचार चैनल के रूप में उपयोग कर रहे हैं जो मुझे पसंद नहीं है। मुझे लगता है कि अगर यह वास्तविक स्थिति है तो ठीक है लेकिन इस तरह के मूल्यों के लिए नहीं। एक्शन क्रिएटर में बदलाव:

actionCreator() {
  ... getState
  ... some logic L1
  ... dispatch({ACTION1})
  // I assume I get updated state if previous dispatch is sync.
  // If previous dispatch is async it has to be chained properly.
  // If updated state can't be received here after a dispatch
  // then I would think there is a flaw.
  ... getState
  ... asyncOperation(state.x, state.y)
}

3) x, y को राज्य करने के लिए सहेजें, इसे किसी घटक में प्रॉपर के रूप में उपयोग करें और घटक को देखते हुए पूरे व्यू लेयर लूप के माध्यम से घटक का उपयोग करते हुएWillReceiveProps नए एक्शन क्रिएटर और async ऑपरेशन को ट्रिगर करता है। सबसे खराब विकल्प यदि आप मुझसे पूछते हैं, तो सभी जगह व्यापार तर्क फैलाते हैं।

@vladar
आम तौर पर इससे कोई फर्क नहीं पड़ता है कि जहाँ तक इस कार्रवाई के परिणाम के रूप में async शुरू किया गया है एक कार्रवाई के रूप में पैक किया गया है, भेजा और एक reducer द्वारा लागू किया गया है। यह उसी तरह काम करेगा। यह वैनिला फ्लक्स के साथ एक ही चर्चा है अगर एस्कॉन को एक्शन क्रिएटर्स या स्टोर्स में शुरू किया जाना चाहिए।

इसके लिए यह आवश्यक होगा कि Redux रिप्ले पर इन एसिंक्स कॉल्स को पहचानने और अनदेखा करने में सक्षम हो, जो वास्तव में आपके सुझाव हैं।

कोई आसान तरीका नहीं है कि रिड्यूसर से एक्शन क्रिएटर के लिए नियंत्रण वापस कैसे लौटाया जाए और कुछ मूल्यों को पारित किया जाए।

मैं कहूंगा कि यह लक्षणों में से एक है। आपका दूसरा उदाहरण मेरे दृष्टिकोण को बहुत अच्छी तरह से दिखाता है (नीचे देखें)।

राज्य संक्रमण के सामान्यीकृत प्रवाह पर विचार करें (FSM दुनिया में):

1. इवेंट आता है
2. वर्तमान स्थिति को देखते हुए FSM नए लक्ष्य राज्य की गणना करता है
3. एफएसएम वर्तमान स्थिति से नए राज्य में संक्रमण के लिए ऑपरेशन करता है

ध्यान दें कि वर्तमान स्थिति महत्वपूर्ण है! एक ही घटना वर्तमान स्थिति के आधार पर विभिन्न परिणामों को जन्म दे सकती है। और चरण 3 में संचालन (या तर्क) के विभिन्न अनुक्रमों के परिणामस्वरूप।

तो यह बहुत ज्यादा है कि फ्लक्स में राज्य संक्रमण कैसे काम करता है जब आपकी कार्रवाई सिंक होती है। आपके Reducers / स्टोर वास्तव में FSM हैं।

लेकिन async कार्रवाई के बारे में क्या? Async क्रियाओं के साथ फ्लक्स के अधिकांश उदाहरण आपको यह सोचने के लिए मजबूर करते हैं कि यह उलटा है:

1. एसी एस्क् संचालन (वर्तमान स्थिति की परवाह किए बिना) करता है
2. एसी इस ऑपरेशन के परिणामस्वरूप कार्रवाई को भेजता है
3. Reducer / Store इसे संभालता है और स्थिति बदलता है

इसलिए वर्तमान स्थिति को नजरअंदाज किया जाता है, लक्ष्य राज्य को हमेशा समान माना जाता है। जबकि वास्तव में सुसंगत राज्य संक्रमण प्रवाह अभी भी वैसा ही है। और इसे इस तरह से देखना होगा (एसी के साथ):

1. कार्रवाई भेजे जाने से पहले एसी को वर्तमान स्थिति मिलती है
2. एसी ने कार्रवाई को किया रवाना
3. एसी कार्रवाई के बाद नए राज्य को पढ़ता है
4. कार्रवाई से पहले और बाद में राज्य को देखते हुए - यह तय करता है कि कौन से ऑपरेशन करना है (या तर्क के रूप में पारित करने के लिए कौन से मूल्य हैं)

बिल्कुल आपका दूसरा उदाहरण। मैं यह नहीं कह रहा हूं, कि इन सभी चरणों की आवश्यकता हर समय होती है। अक्सर आप उनमें से कुछ को छोड़ सकते हैं। लेकिन जटिल मामलों में - कि आपको कैसे कार्य करना होगा। यह किसी भी राज्य संक्रमण का सामान्यीकृत प्रवाह है। और इसका मतलब यह भी है कि आपके FSM की सीमाएँ AC बनाम रिड्यूसर / स्टोर में चली गई हैं।

लेकिन सीमाएँ बढ़ने से अन्य समस्याएं होती हैं:

1. यदि async ऑपरेशन स्टोर / रिड्यूसर में होते हैं - तो आप एक ही घटना पर प्रतिक्रिया देने वाले दो स्वतंत्र FSM हो सकते हैं। इसलिए नई सुविधा जोड़ने के लिए - आप केवल स्टोर / reducer जोड़ सकते हैं जो किसी मौजूदा घटना पर प्रतिक्रिया करता है और यह सब है।
   लेकिन AC में संचालन के साथ - आपको स्टोर / रिड्यूसर को जोड़ना होगा और मौजूदा एसी को तर्क के async हिस्से को जोड़कर संपादित करना होगा। यदि यह पहले से ही कुछ अन्य reducer के लिए async तर्क समाहित करता है ... यह ठंडा नहीं होता है।
   ऐसे कोड को बनाए रखना स्पष्ट रूप से कठिन है।
2. सिंक बनाम async क्रियाओं के मामले में आपके ऐप का नियंत्रण प्रवाह अलग है। सिंक क्रियाओं के लिए reducer संक्रमण के नियंत्रण में है, async के मामले में - एसी प्रभावी रूप से उन सभी संक्रमणों के नियंत्रण में है जो संभावित रूप से इस घटना / कार्रवाई के कारण हो सकते हैं।

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

ज्यादातर मामलों में आप संभवतः सभी प्रकार के वर्कअराउंड के साथ आएंगे। लेकिन आप पहले स्थान पर उनसे बच सकते हैं यदि आपका राज्य संक्रमण तर्क बेहतर ढंग से समझाया गया था और आपके FSM को AC और reducers के बीच अलग नहीं किया गया था।

दुर्भाग्य से राज्य संक्रमण का "साइड-इफ़ेक्टिंग" हिस्सा अभी भी राज्य संक्रमण का एक हिस्सा है, और तर्क के कुछ अलग स्वतंत्र टुकड़े नहीं। इसलिए मेरे लिए (state, action) => (state, sideEffects) अधिक स्वाभाविक लगता है। हाँ, यह "कम" हस्ताक्षर अब% नहीं है) लेकिन फ्रेमवर्क का डोमेन डेटा परिवर्तन नहीं है, लेकिन राज्य संक्रमण है।

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

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

@vladar

(state, action) => (state, sideEffects)

बस सोच। इसका अर्थ है कि हमें रिटर्न प्रकार के कॉम्बिनेशनर फ़ंक्शन को [राज्य, साइडइफ़ेक्ट्स] या [राज्य, [साइडइफ़ेक्ट्स]] में बदलना होगा और साइडइफेक्ट्स को रिड्यूसर से संयोजित करने के लिए इसका कोड बदलना होगा। मूल (राज्य, क्रिया) => राज्य reducer प्रकार समर्थित रह सकता है क्योंकि CombReducers राज्य (या राज्य), [] [] को वापस करने के लिए टाइप करेंगे।

फिर हमें Redux में साइडइफ़ेक्ट्स को निष्पादित करने और भेजने की आवश्यकता है। यह Store.dispatch () में किया जा सकता है जो नए राज्य को लागू करेगा और साइडइफ़ेक्ट्स सूची निष्पादित करेगा और इसे प्रेषण करेगा। मैं सोच रहा हूं कि क्या हम कुछ अच्छे अंतहीन पुनरावृत्ति में जा सकते हैं।

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

@vladar https://github.com/gaearon/redux/issues/291#issuecomment -125267879

@vladar

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

मैं मानता हूँ कि ActionCreators को नियंत्रकों के रूप में मानना ​​एक अच्छी मानसिकता नहीं है। यह मार्ग कारण है कि मैं अंत में यह सोचकर कि एक जटिल तर्क के लिए मुझे reducer से एसी पर नियंत्रण वापस करने की आवश्यकता है। मुझे उसकी जरूरत नहीं होनी चाहिए यदि AC, Async को हैंडल करते हैं, तो उन्हें अधिकतर अनुरोध हैंडलर की तरह होना चाहिए - कहीं और किए गए निर्णय के आधार पर निष्पादित करें और यह अनुरोध क्रॉस-कट डोमेन को नहीं करना चाहिए।

नियंत्रकों के रूप में उनकी भूमिका से बचने के लिए अब एकमात्र विकल्प स्मार्ट घटकों के माध्यम से तर्क को रूट करना है और UI के लिए एक सीधी प्रतिक्रिया में तर्क के प्रारंभिक चरण को निष्पादित करने के लिए केवल ActionCreators का उपयोग करना है। वास्तविक पहला निर्णय Redux.state और / या घटक की स्थानीय स्थिति के आधार पर एक स्मार्ट घटक में किया जाता है।

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

मैं async कॉल को दुकानों से दूर रखने के लिए बिंदु खरीद रहा था। लेकिन मुझे नहीं लगता कि यह मान्य है, क्योंकि, यह कहीं और जटिलता को बढ़ाता है। दूसरी ओर मुझे किसी स्टोर / रिड्यूसर में async फंक्शन होने की बहुत जटिलता दिखाई नहीं देती है, क्योंकि यह केवल वहाँ निष्पादित होता है और प्रेषण - या शुद्ध दृष्टिकोण और डेटा के रूप में इन कार्यों को संभालता है और उन्हें कहीं दूर ट्रिगर करता है।

अभिनेता भी ऐसा ही करते हैं, वे async निष्पादित कर सकते हैं और अन्य अभिनेता को संदेश (एक्शन ऑब्जेक्ट) भेज सकते हैं, या अपने एफएसएम में जारी रखने के लिए खुद को भेज सकते हैं।

मैं बंद कर रहा हूं क्योंकि यहां कुछ भी कार्रवाई योग्य नहीं लगता है। Async क्रियाएँ doc को अधिकांश प्रश्नों का उत्तर देना चाहिए। इसके अलावा, सैद्धांतिक चर्चाएं मेरे लिए मूल्यवान नहीं लगतीं, वास्तविक कोड के बिना हम नहीं चल सकते। ;-)

@gaearon आप

मुझे अभी भी सभी डॉक्स पढ़ने के बाद वास्तविक प्लेसमेंट के बारे में प्रश्न हैं और यह समस्या कुछ समय के लिए मुझे समझने में परेशानी हो रही है कि इन साइड इफेक्ट्स को रखने के लिए कौन सी फाइलें हैं https://github.com/rackt/redux/issues/291#issuecomment -123010379 । मुझे लगता है कि यह इस मुद्दे के धागे से "सही" उदाहरण है।

इस क्षेत्र में किसी भी स्पष्टीकरण के लिए अग्रिम धन्यवाद।

मैं अशुद्ध कार्रवाई रचनाकारों के बारे में एक महत्वपूर्ण विचार बताना चाहता हूं:

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

मैं जिस ऐप को विकसित कर रहा हूं उसमें कम से कम दो संस्करण होंगे: एक जो एक ऑनसाइट रास्पबेरी पाई में चलता है, और दूसरा जो एक पोर्टल चलाता है। ग्राहक द्वारा संचालित सार्वजनिक पोर्टल / पोर्टल के लिए अलग संस्करण भी हो सकते हैं। चाहे मुझे अलग-अलग एपीआई का उपयोग करना है अनिश्चित है, लेकिन मैं उस संभावना के लिए तैयार करना चाहता हूं जो मैं कर सकता हूं, और मिडलवेयर मुझे ऐसा करने की अनुमति देता है।

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

@ jedwards1211 आपको https://github.com/redux-effects/redux-effects में रुचि हो सकती है यदि आपने उन्हें अभी तक चेक नहीं किया है, साथ ही साथ # 569 पर चर्चा की है।

@gaearon शांत, यह इंगित करने के लिए धन्यवाद! किसी भी मामले में, मेरे अपने मिडलवेयर का उपयोग करना अब तक बहुत मुश्किल नहीं रहा है :)

मैंने एल्म जैसा दृष्टिकोण बनाया: रिडक्स-साइड-इफ़ेक्ट । आरईएडीएमई दृष्टिकोण की व्याख्या करता है और इसकी तुलना विकल्पों से करता है।

@gregwebs मुझे redux-side-effect , हालांकि यह स्वैपेबल कंट्रोल लॉजिक के साथ भी अजीब होगा, क्योंकि मेरे रिड्यूसर मॉड्यूल में sideEffect फंक्शन होने का सवाल है, जब कई अलग-अलग स्टोर कॉन्फ़िगरेशन हैं। विभिन्न बिल्ड में उपयोग किए जाने वाले मॉड्यूल।

मैं एक अजीब हैक का उपयोग कर सकता हूं: बस sideEffect state ही संग्रहीत करता हूं, इसलिए यह reducer के लिए स्वचालित रूप से उपलब्ध है! :जीभ चिढ़ाना आंख मारना:

Https://github.com/rackt/redux/pull/569/ जैसी कोई चीज़ आदर्श के करीब है कि मैं कैसे काम करना चाहता हूं, हालांकि निश्चित रूप से मैं इसे उत्पादन परियोजना में उपयोग नहीं करना चाहता जब तक कि यह एक मानक हिस्सा नहीं बन जाता। एपीआई के।

यहाँ एक विचार है: कार्रवाई पर एक मिडलवेयर स्टिक sideEffect फ़ंक्शन है। थोड़ा हैकरी, लेकिन पुन: उपयोग करने के लिए आवश्यक सबसे महत्वपूर्ण परिवर्तन async कोड आरंभ करने में सक्षम है:

sideEffectMiddleware.js :

export default store => next => action => {
  let sideEffects = [];
  action.sideEffect = callback => sideEffects.push(callback);
  let result = next(action);
  sideEffects.forEach(sideEffect => sideEffect(store));
  return result;
};

सरल पक्ष के दृष्टिकोण के कई तरीके हैं। कृपया अपने वेरिएंट को आज़माएं और वापस रिपोर्ट करें

मैंने ऊपर sideEffectMiddleware दृष्टिकोण का उपयोग करने के लिए अपना कोड रिफैक्ट किया, और मुझे वास्तव में परिणामी कोड संगठन पसंद है। यह अच्छा है कि मेरे reducers में कहीं से भी sideEffect फंक्शन इम्पोर्ट न करें, यह सिर्फ action ।

@ jedwards1211 मैंने आपके कोड को पैकेज के संस्करण 2.1.0 में actionSideEffectMiddleware के रूप में प्रकाशित किया।

@ कूल कूल! एक सहयोगी के रूप में मुझे सूचीबद्ध करने का मन?

@ jedwards1211 आपको जोड़ा जाता है। हो सकता है कि आप उचित रीप्ले समर्थन जोड़ेंगे :) मैं अभी तक इसका फायदा नहीं उठा सकता जहां मैं इसका उपयोग कर रहा हूं।

@gaearon मैं इसे रिकॉर्ड और

वे करते हैं, यह सिर्फ इतना है कि वे पहले से ही दर्ज की गई वस्तुओं को पहले से ही सादे हैं, इसलिए मिडलवेयर आमतौर पर हस्तक्षेप नहीं करता है।

@ जियारोन हम्म । तो मैं वास्तव में उस सुविधा की कोशिश नहीं की है, लेकिन ... मैं कुछ साइड इफेक्ट का अनुमान लगा रहा हूँ कि बिचौलियों रिकॉर्ड तोड़ होगा / फिर से खेलना? उदाहरण के लिए redux-effects-fetch लें, यह अभी भी एक सादे वस्तु FETCH कार्रवाई पर एक अजाक्स अनुरोध करेगा:

function fetchMiddleware ({dispatch, getState}) {
  return next => action =>
    action.type === 'FETCH'
      ? fetch(action.payload.url, action.payload.params).then(checkStatus).then(deserialize, deserialize)
      : next(action)
}

यदि रिकॉर्डर FETCH कार्रवाई के steps से [success, failure] कॉलबैक को साफ करता है, तो redux-effects मिडलवेयर किसी भी राज्य-परिवर्तनकारी कार्यों को नहीं भेजेगा, लेकिन फिर भी, एक नहीं चाहेगा; अजाक्स अनुरोधों का एक गुच्छा ट्रिगर करने के लिए फिर से खेलना।

क्या "शुद्ध" मिडलवेयर (जो अतिरिक्त कार्यों को कभी नहीं भेजता है) को अलग करने का कोई तरीका है, जैसे "अशुद्ध" मिडलवेयर से redux-logger (जो कार्यों को भेज सकता है)?

दुर्भाग्य से मैंने redux-effects बारीकी से नहीं देखा है इसलिए मैं आपके प्रश्न का उत्तर नहीं दे सकता।

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

यह नहीं है यह उम्मीद की जाती है कि वर्धमान रचना श्रृंखला में devTools() _after_ applyMiddleware डाला जाए, ताकि जब तक यह क्रिया पूरी हो जाए, यह एक "अंतिम" क्रिया हो, जिसे आगे की व्याख्या की आवश्यकता न हो।

ओह, मैं देख रहा हूं, इसलिए एक मिडलवेयर एक साइड इफ़ेक्ट करने के बाद इसे एक्शन से किसी भी फील्ड को हटा सकता है / इसे ट्वीक कर सकता है ताकि रीप्ले पर मिडलवेयर के माध्यम से वापस जाने पर यह साइड इफेक्ट को ट्रिगर न करे, और फिर इसे करना चाहिए देव उपकरण के साथ काम, सही?

हाँ, यह एक अच्छा तरीका लगता है।

महान, मुझे ज्ञानवर्धन के लिए धन्यवाद!

@gaearon @vladar @ jedwards1211 आपको https://github.com/salsita/redux-side-effects में रुचि हो सकती है (state, action) => (state, sideEffects) का कार्यान्वयन है, लेकिन बदले में टपल लौटाने के बजाय (जो आपने पहले ही देखा है कि यह संभव नहीं है) यह उपज-प्रभाव प्रभाव है।
मैंने इसके साथ जल्द ही खेला, हॉट रील और रीप्ले ठीक लग रहा है। मुझे अब तक कोई भी redux फ़ीचर टूटा हुआ नहीं दिखाई दे रहा है, लेकिन हो सकता है कि कुछ सीनियर reduxers को कुछ मिल जाए। :)
मेरे लिए, यह रिड्यूक्स स्टैक के लिए वास्तव में महत्वपूर्ण अतिरिक्त के रूप

एक अन्य दृष्टिकोण है रेडक्स-सागा जो जनरेटर का भी उपयोग करता है लेकिन साइड इफेक्ट को रेड्यूसर से अलग रखता है।

@gaearon मेरा मानना ​​है कि @minedeljkovic का मतलब था

मेरे लिए, यह रिडक्स स्टैक के रूप में वास्तव में महत्वपूर्ण है क्योंकि यह तर्क को मुख्य रूप से reducers में होने की अनुमति देता है जिससे वे एक प्रभावी और परीक्षण योग्य राज्य मशीन बना सकते हैं, जो प्रभाव (संक्रमण कार्यों जिसका परिणाम केवल वर्तमान स्थिति पर निर्भर नहीं करता है) बाहरी सेवाओं ( एल्म आर्किटेक्चर, प्रभाव और सेवाओं की तरह बहुत)।

पारंपरिक दृष्टिकोण पर मुख्य लाभ के रूप में, क्योंकि https://github.com/yelouafi/redux-saga/ बहुत समान है कि redux-thunk काम करता है, इसके बजाय कुछ सिंटैक्स चीनी के शीर्ष पर जो लंबे समय तक चलने वाले लेनदेन को आसान बनाता है। ।

https://github.com/salsita/redux-side-effects दूसरी ओर एल्म वास्तुकला की तरह है।

हां, Redux-saga और Redux-side-effects क्रमशः जनरेटर का उपयोग केवल साइड इफेक्ट्स की घोषणा करने के लिए करते हैं, जो क्रमशः सागा और रीड्यूसर को शुद्ध रखते हैं। वह समान है।

दो कारणों से मुझे यह पसंद है कि reducers में:

1. आपके पास वर्तमान स्थिति तक स्पष्ट पहुंच है जो प्रभावित हो सकती है कि कैसे प्रभाव घोषित किया जाना चाहिए (मुझे लगता है कि इस चर्चा के दौरान @vladar के बिंदुओं में से एक था)
2. कोई नई अवधारणा पेश नहीं की गई है (Redux-saga में सागा)

Https://github.com/rackt/redux/issues/1139#issuecomment -165419770 में मेरी टिप्पणी अभी भी redux-saga रूप में मान्य है और इसे हल करने के अलावा और कोई उपाय नहीं है सिवाय मॉडल को स्वीकार करने के एल्म वास्तुकला में उपयोग किया जाता है।

मैंने एक साधारण सा संकेत दिया है, जो रेड-साइड-इफ़ेक्ट के बारे में मेरी बातों पर ज़ोर देने की कोशिश कर रहा है: https://gist.github.com/minedeljkovic/7347c0b528110889aa50

मैंने सबसे सरल संभव परिदृश्य को परिभाषित करने की कोशिश की, जो मुझे लगता है कि बस "वास्तविक दुनिया" पर्याप्त है लेकिन फिर भी इस चर्चा से कुछ बिंदुओं पर जोर दिया गया है।

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

वास्तुकला की कमी:

1. कंट्रीब्यूशन फ़ंक्शंस मॉड्यूलर होना चाहिए ( Redux ducks की भावना में), इसलिए इसे एप्लिकेशन के कई हिस्सों में पुन: उपयोग किया जा सकता है (उदाहरण के लिए "उत्पाद प्रशासन" अनुप्रयोग के भाग में, जहां उत्पादन का देश दर्ज किया जाना चाहिए)
2. देश के राज्य के स्लाइस को वैश्विक नहीं माना जाना चाहिए (Redux राज्य की जड़ में), लेकिन यह स्थानीय होना चाहिए (और उस मॉड्यूल द्वारा नियंत्रित) जो इसे लागू कर रहा है।
3. इस कार्यक्षमता के मुख्य तर्क को यथासंभव कम चलती भागों को शामिल करने की आवश्यकता है (मेरे जिस्ट में यह मूल तर्क केवल और केवल तर्क के सबसे महत्वपूर्ण भाग में पुनर्परिभाषित में लागू किया गया है। घटक तुच्छ होना चाहिए, क्योंकि सभी Redux- संचालित घटक होने चाहिए। हो :)। उनकी एकमात्र जिम्मेदारी वर्तमान स्थिति, और कार्यों को भेजना होगी।)

इस बातचीत के संबंध में, जिस्ट का सबसे महत्वपूर्ण हिस्सा है, जिस तरह से देश में चयन reducer CONFIRM_SELECTION कार्रवाई को संभाल रहा है।

@gaearon , मैं ज्यादातर अपने बयान पर आपकी राय को स्पष्ट करूंगा कि मानक redux के अलावा redux- साइड इफेक्ट्स कसना पर विचार करते हुए सरलतम समाधान के लिए सतह प्रदान करते हैं।

इस परिदृश्य को लागू करने के लिए संभावित वैकल्पिक विचार (Redux-side-effects का उपयोग किए बिना, लेकिन redux-saga, redux-thunk या किसी अन्य विधि का उपयोग करके), यह भी बहुत ही उचित होगा।

@ tomkis1 , मुझे आपकी राय यहाँ पसंद

(इस gist में थोड़ा अलग कार्यान्वयन है https://gist.github.com/minedeljkovic/9d4495c7ac5203def688, जहां GlobalActions से बचा जाता है। यह इस विषय के लिए महत्वपूर्ण नहीं है, लेकिन शायद कोई इस पैटर्न पर टिप्पणी करना चाहेगा)

@minedeljkovic जीस्ट के लिए धन्यवाद। मैं आपके उदाहरण के साथ एक वैचारिक समस्या देखता हूं। redux-side-effects का उपयोग केवल साइड इफेक्ट के लिए किया जाना है। आपके उदाहरण में हालांकि कोई साइड-इफेक्ट नहीं हैं, लेकिन लंबे समय तक रहने वाले व्यापारिक लेनदेन हैं और इसलिए redux-saga अधिक उपयुक्त है। @slorber और @yelouafi इस पर अधिक प्रकाश

दूसरे शब्दों में मेरे लिए सबसे अधिक महत्वपूर्ण मुद्दा समकालिक dispatching रिड्यूसर (https://github.com/salsita/redux-side-effects/pull/9#issuecomment-165575751) के भीतर नई कार्रवाई का

yield dispatch => dispatch({type: COUNTRY_SELECTION_SUCCESS, payload: state.selectedCountryId});

मेरा मानना ​​है कि @slorber "व्यावसायिक पक्ष प्रभाव" शब्द के साथ आया था और यह वास्तव में आपका मामला है। redux-saga इस विशेष समस्या को हल करने में चमकता है।

@mindjuice मैं आपके उदाहरण को समझने के लिए पूरी तरह से निश्चित नहीं हूं, लेकिन मुझे यहां दिए गए ऑनबोर्डिंग उदाहरण पसंद हैं: https://github.com/paldepind/functional-frontend-Healthecture/issues/20#issuecunment -162822909

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

इसके अलावा, आप गाथा को बतखों के बीच एक युग्मन बिंदु के रूप में देख सकते हैं।
उदाहरण के लिए, आपके पास प्रत्येक पर स्थानीय क्रियाओं के साथ duck1 और duck2 है। अगर आपको 2 बत्तखों की जोड़ी बनाने का विचार पसंद नहीं है (मेरा मतलब है कि एक बत्तख दूसरे बत्तखों के क्रियाकलापों का उपयोग कर रही होगी) तो आप उन्हें केवल यह बता सकते हैं कि क्या हुआ था, और फिर एक सागा बनाएं जो कुछ जटिल व्यापार नियमों को तार-तार करता है। 2 बत्तख।

Sooooo, यह एक बहुत लंबा धागा है और अभी भी समस्या का कोई समाधान है?

मान लीजिए, आपके पास एक अतुल्यकालिक action() और आपके कोड को या तो त्रुटि का संकेत देना चाहिए या परिणाम दिखाना चाहिए।

पहला तरीका इसे पसंद करना था

// the action call
action().then(dispatch(SUCCESS)).catch(dispatch(FAILURE))

// the reducer
case SUCCESS:
    state.succeeded = true
    alert('Success')

case FAILURE:
    state.succeeded = false
    alert('Failure')

लेकिन यह पता चला है कि यह Redux-way नहीं है क्योंकि अब Reducer में "दुष्प्रभाव" हैं (मुझे नहीं पता कि इसका क्या मतलब है)।
लंबी कहानी छोटी, सही तरीका ये है कि इन alert() को reducer से कहीं बाहर ले जाना है।

यह कहीं न कहीं रिएक्ट घटक हो सकता है जो इस action कॉल करता है।
तो अब मेरा कोड दिखता है:

// the reducer
case SUCCESS:
    state.succeeded = true

case FAILURE:
    state.succeeded = false

// the React component
on_click: function()
{
    action().then
    ({
        dispatch(SUCCESS)

        alert('Success')
        // do something else. maybe call another action
    })
    .catch
    ({
        dispatch(FAILURE)

        alert('Failure')
        // do something else. maybe call another action
    })
}

क्या अब ऐसा करने का सही तरीका है?
या क्या मुझे और जांच करने और कुछ 3 पार्टी लाइब्रेरी लागू करने की आवश्यकता है?

Redux सरल नहीं है। वास्तविक दुनिया के ऐप्स के मामले में समझना आसान नहीं है। Mabye एक नमूना वास्तविक दुनिया एप्लिकेशन रेपो को सही तरीके से दर्शाती एक विहित उदाहरण के रूप में आवश्यक है।

@ हाल्ट-हैम्ज़निट रेडक्स ने इसे बहुत ही सरल बनाया; भ्रामक विखंडन Redux का उपयोग करते समय Reducers से दुष्प्रभाव को एकीकृत / अलग करने के बारे में विभिन्न आवश्यकताओं या राय से आता है।

इसके अलावा, विखंडन इस तथ्य से आता है कि यह वास्तव में ऐसा नहीं है कि साइड इफेक्ट्स करना मुश्किल है लेकिन आप Redux के साथ चाहते हैं। यह केवल मुझे अपने मूल साइड इफेक्ट मिडलवेयर को रोल करने के लिए कोड की लगभग 10 लाइनें ले गया। तो अपनी स्वतंत्रता को गले लगाओ और "सही" तरीके के बारे में चिंता मत करो।

@ jedwards1211 "Redux ही" का कोई मूल्य या अर्थ नहीं है और इसका कोई मतलब नहीं है क्योंकि इसका मुख्य उद्देश्य फ्लक्स डेवलपर्स के रोजमर्रा के मुद्दों को हल करना है। इसका मतलब है AJAX, सुंदर एनिमेशन और अन्य सभी _ordinary और अपेक्षित_ सामान

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

क्या आपने रेपो में "उदाहरण" फ़ोल्डर देखा है?

जबकि साइड इफेक्ट्स करने के कई तरीके हैं, आमतौर पर सिफारिश यह है कि Redux के बाहर या एक्शन क्रिएटर्स के अंदर, जैसे हम हर उदाहरण में करते हैं।

हां, मुझे पता है ... मैं कह रहा हूं कि इस धागे ने साइड इफेक्ट्स करने के सबसे अच्छे तरीके के बारे में आम सहमति की कमी (कम से कम यहां लोगों के बीच) को चित्रित किया है।

हालांकि शायद अधिकांश उपयोगकर्ता थंक एक्शन क्रिएटर्स का उपयोग करते हैं और हम सिर्फ आउटलेयर हैं।

^ उसने क्या कहा।

मैं एक धर्मी समाधान पर सहमत होने के लिए सभी महान दिमागों को पसंद करूंगा
और इसे पत्थर में उकेरा ताकि मुझे 9000 स्क्रीनों के माध्यम से न पढ़ना पड़े
थ्रेड

गुरुवार, 7 जनवरी 2016 को एंडी एडवर्ड्स नोटिफिकेशन @

हां, मुझे पता है ... मैं कह रहा हूं कि इस धागे में कमी है
आम सहमति (कम से कम यहां लोगों के बीच) पक्ष प्रदर्शन करने के सर्वोत्तम तरीके के बारे में
प्रभाव।

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

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

गुरुवार 7 जनवरी 2016 को, Николай Кучумов [email protected] ने लिखा:

^ उसने क्या कहा।

मैं एक धर्मी समाधान पर सहमत होने के लिए सभी महान दिमागों को पसंद करूंगा
और इसे पत्थर में उकेरा ताकि मुझे 9000 स्क्रीनों के माध्यम से न पढ़ना पड़े
थ्रेड

गुरुवार, 7 जनवरी 2016 को एंडी एडवर्ड्स < नोटिफिकेशन @github.com
<_e i = "16">

हां, मुझे पता है ... मैं कह रहा हूं कि इस धागे में कमी है
आम सहमति (कम से कम यहां लोगों के बीच) पक्ष प्रदर्शन करने के सर्वोत्तम तरीके के बारे में
प्रभाव।

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

यह और इसी तरह के धागे मौजूद हैं क्योंकि 1% Redux उपयोगकर्ता साइड इफेक्ट्स के लिए अधिक शक्तिशाली / शुद्ध / घोषित समाधानों की तलाश करना पसंद करते हैं। कृपया इस धारणा को न लें कि कोई भी उस पर सहमत नहीं हो सकता है। मूक बहुमत सोच और वादों का उपयोग करता है, और ज्यादातर इस दृष्टिकोण से खुश हैं। लेकिन किसी भी टेक की तरह इसमें डाउनसाइड और ट्रेडऑफ होते हैं। यदि आपके पास जटिल अतुल्यकालिक तर्क है, तो आप Redux को छोड़ना चाहते हैं और इसके बजाय Rx को एक्सप्लोर कर सकते हैं। रेडक्स पैटर्न आरएक्स में आसानी से अभिव्यंजक है।

ठीक है धन्यवाद

गुरुवार, 7 जनवरी, 2016 को, दान अब्रामोव सूचनाएं @github.com ने लिखा:

यह और इसी तरह के धागे मौजूद हैं क्योंकि 1% Redux उपयोगकर्ता देखना चाहते हैं
साइड इफेक्ट्स के लिए अधिक शक्तिशाली / शुद्ध / घोषणात्मक समाधान। कृपया नहीं
यह धारणा लें कि कोई भी उस पर सहमत नहीं हो सकता है। मौन बहुमत का उपयोग करता है
सोचता है और वादा करता है, और ज्यादातर इस दृष्टिकोण से खुश हैं। लेकिन किसी भी तरह
टेक में यह डाउनसाइड और ट्रेडऑफ है। यदि आपके पास जटिल अतुल्यकालिक तर्क है
आप Redux को छोड़ना चाहते हैं और इसके बजाय Rx को देखना चाहते हैं Redux पैटर्न है
आरएक्स में आसानी से अभिव्यंजक।

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

@gaearon हाँ, तुम सही हो। और मैं सराहना करता हूं कि Redux हमारे सभी अलग-अलग तरीकों को समायोजित करने के लिए पर्याप्त लचीला है!

@ पड़ाव-हथौड़ी मेरे जवाब पर एक नज़र डालते हैं जहाँ मैं समझाता हूँ कि Redux-saga Redux-thunk से बेहतर क्यों हो सकता है: http://stackoverflow.com/questions/34570758/why-do-we-weed-middleware-for- async-प्रवाह में redux / 34599594

@gaearon वैसे,
http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-async-flow-in-redux/34599594#34599594
वास्तविक दुनिया के एप्लिकेशन जल्दी से AJAX के माध्यम से डेटा लाने से परे जाते हैं: उन्हें त्रुटियों को भी संभालना चाहिए और एक्शन कॉल के आउटपुट के आधार पर कुछ क्रियाएं करनी चाहिए।
आपकी सलाह सिर्फ dispatch कुछ अन्य घटना है और यही है।
तो क्या होगा यदि मेरा कोड alert() उपयोगकर्ता को कार्रवाई पूर्ण होने पर देना चाहता है?
यही वह जगह है जहां thunk s मदद नहीं करेंगे, लेकिन वादे करेंगे।
मैं वर्तमान में साधारण वादों का उपयोग करके अपना कोड लिखता हूं और यह उसी तरह से काम करता है।

मैंने redux-saga बारे में आसन्न टिप्पणी पढ़ी है।
समझ में नहीं आया कि यह क्या करता है, योग्य।
मैं monads चीज़ और इस तरह से बहुत अधिक नहीं हूं, और मुझे अभी भी नहीं पता है कि thunk है, और मुझे शुरू करने के लिए वह अजीब शब्द पसंद नहीं है।

ठीक है, तो मैं तब रिएक्ट घटकों में वादों का उपयोग करता रहता हूं।

हम सुझाव देते हैं कि डॉक्स के दौरान थ्रक्स से वादे वापस करें।

@gaearon हाँ, यही तो मैं बात कर रहा हूँ: on_click() { dispatch(load_stuff()).then(show_modal('done')) }
करना होगा।

मुझे लगता है कि आप अभी भी कुछ याद कर रहे हैं।
कृपया Redux-thunk की README देखें।
यह दिखाता है कि "रचना" अनुभाग के तहत थन एक्शन क्रिएटर्स को कैसे चेन करना है।

@gaearon हाँ, ठीक यही मैं कर रहा हूँ:

store.dispatch(
  makeASandwichWithSecretSauce('My wife')
).then(() => {
  console.log('Done!');
});

यह वही है जो मैंने ऊपर लिखा है:

on_click()
{
    dispatch(load_stuff())
        .then(() => show_modal('done'))
        .catch(() => show_error('not done'))
}

वह README सेक्शन अच्छी तरह से लिखा गया है, thx

नहीं, यह मेरी बात नहीं थी। makeSandwichesForEverybody पर एक नज़र डालें। यह एक ठग एक्शन क्रिएटर है जिसे अन्य थंक एक्शन क्रिएटर कहते हैं। यही कारण है कि आपको घटकों में सब कुछ डालने की आवश्यकता नहीं है। इस से अधिक के लिए इस रेपो में async उदाहरण भी देखें।

@gaearon लेकिन मुझे लगता है कि एक्शन क्रिएटर में मेरा फैंसी एनिमेशन कोड डालना, कहना उचित नहीं होगा?
इस उदाहरण पर विचार करें:

button_on_click()
{
    this.props.dispatch(load_stuff())
        .then(() =>
        {
                const modal = ReactDOM.getDOMNode(this.refs.modal)
                jQuery(modal).fancy_animation(1200 /* ms */)
                setTimeout(() => jQuery.animate(modal, { background: 'red' }), 1500 /* ms */)
        })
        .catch(() =>
        {
                alert('Failed to bypass the root mainframe protocol to override the function call on the hyperthread's secondary firewall')
        })
}

आप इसे सही तरीके से कैसे लिखेंगे?

@ पड़ाव-हथौड़े से आप एक्शन क्रिएटर को वादे वापस कर सकते हैं ताकि घटक स्थानीय घटक राज्य का उपयोग करके कुछ स्पिनर या जो कुछ भी दिखा सके (वैसे भी jquery का उपयोग करते समय बचने के लिए कठिन)

अन्यथा आप रेडक्स-सागा के साथ एनिमेशन ड्राइव करने के लिए जटिल टाइमर का प्रबंधन कर सकते हैं।

इस ब्लॉग पोस्ट पर एक नज़र डालें: http://jaysoo.ca/2016/01/03/managing-processes-in-redux-using-sagas/

ओह, इस मामले में इसे घटक में रखना ठीक है।
(ध्यान दें: आम तौर पर रिएक्ट में यह सब कुछ के लिए घोषणात्मक मॉडल का उपयोग करना सबसे अच्छा है बजाय इसके कि jQuery के साथ अनिवार्य रूप से मॉडल दिखाए जाएं। कोई बड़ी बात नहीं है।)

@slorber हाँ, मैं पहले से ही अपने "थ्रक्स" (या जो भी आप उन्हें फोन करता हूं, उससे प्रॉमिस और सामान वापस कर रहा हूं; मुझे यह अजीब शब्द पसंद नहीं है), इसलिए मैं स्पिनरों और ऐसे को संभाल सकता हूं।

@gaearon ठीक है, मैं तुम्हें मिल गया। आदर्श मशीनरी की दुनिया में, निश्चित रूप से घोषणात्मक प्रोग्रामिंग मॉडल के अंदर रहना संभव होगा, लेकिन वास्तविकता की अपनी मांगें हैं, तर्कहीन, कहना, एक मशीन के दृष्टिकोण से। लोग तर्कहीन प्राणी हैं जो न केवल शुद्ध शून्य और लोगों के साथ काम कर रहे हैं और इसे कुछ तर्कहीन सामान करने में सक्षम होने के पक्ष में कोड सौंदर्य और शुद्धता से समझौता करने की आवश्यकता है।

मैं इस सूत्र में समर्थन से संतुष्ट हूं। मेरी शंका का अब समाधान होता दिख रहा है।

प्रासंगिक नई चर्चा: https://github.com/reactjs/redux/issues/1528

@ बेयरॉन बहुत भयानक स्पष्टीकरण! : ट्रॉफी: धन्यवाद: +1: