React: पदावनत `isMounted`

मैं इससे सहमत नहीं हूं। विशेष रूप से ES6 वादों को componentWillUnmount पर विश्वसनीय रूप से रद्द नहीं किया जा सकता है, इसलिए यह जांचने का एकमात्र तरीका है कि घटक सेटस्टेट से पहले आरोहित है या कोई अन्य क्रिया एसिंक बग का पता लगाने के लिए बहुत कठिन रास्ता खोल रही है।

@yaycmyk इस प्रकार रेखा:

हमें अभी भी वादों (और संबंधित उपयोग के मामलों) के आसपास कुछ अच्छी कहानियों का पता लगाने की जरूरत है।

कृपया मेरे द्वारा सूचीबद्ध पृष्ठभूमि के मुद्दों को पढ़ें, विशेष रूप से: https://github.com/facebook/react/issues/2787#issuecomment -68738793

मैंने टिप्पणियाँ पढ़ीं। मुझे बस मुद्दे अटपटे लगते हैं।

वादों को विश्वसनीय रूप से रद्द क्यों नहीं किया जा सकता? कोई स्रोत/सबूत/उदाहरण?

सोमवार, 16 नवंबर, 2015 को, इवान जैकब्स नोटिफिकेशन @github.com ने लिखा:

मैं इससे सहमत नहीं हूं। ES6 वादे विशेष रूप से विश्वसनीय नहीं हो सकते हैं
कंपोनेंटविलअनमाउंट पर रद्द कर दिया गया है, इसलिए यह जांचने का एकमात्र तरीका है कि क्या
घटक सेटस्टेट से पहले आरोहित है या कोई अन्य क्रिया खोल रही है
async बग्स का पता लगाने के लिए बहुत मेहनत करने का तरीका।

@nvartolomei ES6 वादा युक्ति को देखें।

यह एक दीर्घकालिक लक्ष्य है, न कि ऐसा कुछ जो तुरंत हो रहा है। लेकिन हम योजना और चर्चाओं को एक ही स्थान पर ट्रैक करना चाहते हैं, न कि हर मुद्दे पर टिप्पणियों में जब यह सामने आता है। हम वर्तमान में रद्द करने योग्य वादों की समस्या से अवगत हैं, जो एक प्रमुख कारण है कि हमने इसे पहले ही नहीं किया है।

@yaycmyk एक बहुत ही जटिल मुद्दे को अति-सरल बनाने के लिए... टिप्पणियाँ कह रही हैं... अनमाउंट घटकों के लिए setState से बचने के लिए isMounted करने से वास्तव में समस्या का समाधान नहीं होता है कि setState चेतावनी इंगित करने का प्रयास कर रही थी - वास्तव में, यह केवल समस्या को छुपाती है। साथ ही, किसी वादे के परिणामस्वरूप setState को कॉल करना वैसे भी एक विरोधी पैटर्न है, क्योंकि यह दौड़ की स्थिति पैदा कर सकता है जो जरूरी नहीं कि परीक्षण में दिखाई दे। इस प्रकार हम इससे छुटकारा पाना चाहते हैं, और रिएक्ट के साथ वादों का उपयोग करने के लिए "सर्वोत्तम अभ्यास" अनुशंसा का पता लगाना चाहते हैं।

मैं मानता हूं कि मुद्दे थोड़े उलझे हुए हैं, लेकिन यह काफी हद तक इसलिए है क्योंकि यह एक जटिल मुद्दा है जिसे हम अभी भी समझ रहे हैं और अभी तक इसके लिए कोई पूर्वनिर्धारित प्रतिक्रिया नहीं है।

एक वादे के परिणाम के रूप में सेटस्टेट को कॉल करना वैसे भी एक विरोधी पैटर्न है, क्योंकि यह दौड़ की स्थिति पैदा कर सकता है जो जरूरी नहीं कि परीक्षण में दिखाई दे

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

हो सकता है कि आप किसी वादे को रद्द करने में सक्षम न हों, लेकिन आप इसे अनमाउंट पर घटक को असंबद्ध बना सकते हैं, जैसे:

const SomeComponent = React.createClass({
    componentDidMount() {
        this.protect = protectFromUnmount();

        ajax(/* */).then(
            this.protect( // <-- barrier between the promise and the component
                response => {this.setState({thing: response.thing});}
            )
        );
    },
    componentWillUnmount() {
        this.protect.unmount();
    },
});

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

किसी भी वादे को रद्द करने के लिए इस सरल विधि का उपयोग किया जा सकता है

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise.then((val) =>
      hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
    );
    promise.catch((error) =>
      hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

संपादित करें: शुद्धता/पूर्णता के लिए अद्यतन किया गया।

कैसे इस्तेमाल करे

const somePromise = new Promise(r => setTimeout(r, 1000));

const cancelable = makeCancelable(somePromise);

cancelable
  .promise
  .then(() => console.log('resolved'))
  .catch(({isCanceled, ...error}) => console.log('isCanceled', isCanceled));

// Cancel promise
cancelable.cancel();

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

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

हम केवल निम्न द्वारा सरल जाँच रख सकते हैं:

React.createClass(function() {
  componentDidMount: function() {
    this._isMounted = true;

    ajax(/* */).then(this.handleResponse);
  }

  handleResponse: function(response) {
    if (!this._isMounted) return; // Protection

    /* */
  }

  componentWillUnmount: function() {
    this._isMounted = false;
  }
});

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

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

क्या होगा यदि setState को एक जंजीर वादा पारित किया जा सकता है जो वांछित राज्य परिवर्तनों को हल करता है? यदि घटक अनमाउंट हो जाता है, तो यदि कोई लंबित वादे हैं तो उनके अंतिम परिणाम को अनदेखा कर दिया जाता है।

@istarkov अच्छा पैटर्न, इसे पसंद है! यहाँ इसके लिए थोड़ा बदला हुआ एपीआई है:

// create a new promise
const [response, cancel] = await cancelable(fetch('/api/data'));

// cancel it
cancel();

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

@dtertman https://github.com/facebook/react/pull/5870 में फिक्स्ड है, जब डॉक्स चेरी-पिक ओवर हो जाएंगे तो ऑनलाइन होंगे।

@jimfb धन्यवाद, सुनिश्चित नहीं है कि मैंने इसे खोज में कैसे याद किया।

@istarkov सुनिश्चित नहीं है कि यह जानबूझकर था लेकिन मूल वादा विफल होने पर आपका makeCancelable संभाल नहीं पाता है। जब मूल वादा खारिज कर दिया जाता है, तो कोई हैंडलर नहीं बुलाया जाता है।

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

यहाँ एक makeCancelable लिए मेरा प्रस्ताव है जो मूल वादे में अस्वीकृति को संभालता है:

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise.then((val) =>
      hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
    );
    promise.catch((error) =>
      hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

मुझे यकीन नहीं है कि मैं कहां खड़ा हूं अगर रद्द करने योग्य वादे करना एक अच्छा विचार है, लेकिन अगर हम वादे रद्द करने जा रहे हैं, तो हमें अंतर्निहित व्यवहार को संरक्षित करना चाहिए :)।

@vpontis : +1:

@istarkov आपकी मूल पोस्ट यहाँ संदर्भित है: https://facebook.github.io/react/blog/2015/12/16/ismounted-antipattern.html

अपनी पोस्ट को अपडेट करना चाहते हैं या क्या मुझे पोस्ट के लेखक को संदेश देना चाहिए?

@vpontis धन्यवाद, मैं ठीक कर दूंगा! (https://github.com/facebook/react/pull/6152)

अरे @jimfb , इंटरनेट पर आपका मज़ाक उड़ाया जा रहा है!

makeCancelable फ़ंक्शन में एक और बग फिक्स: यह हाल के नोड संस्करणों में UnhandledPromiseRejectionWarning का कारण बन सकता है (विशेषकर जब नोड के नए संस्करण के साथ परीक्षण चल रहा हो)। नोड 6.6.0 में हुए परिवर्तनों में से एक यह है कि सभी अनहेल्ड वादों के अस्वीकरण के परिणामस्वरूप एक चेतावनी होती है। @vpontis के मौजूदा कोड में अलग-अलग then और catch कॉल एक ही मूल वादे पर थे। प्रभावी रूप से, यह _दो_ वादे बनाता है, एक जो केवल सफलता को संभालता है, और एक जो केवल त्रुटियों को संभालता है। इसका मतलब है कि यदि कोई त्रुटि है, तो नोड द्वारा पहले वादे को एक अनहेल्ड वादा अस्वीकृति के रूप में देखा जाएगा।

फिक्स बहुत आसान है: बस दो कॉलों को चेन करें ताकि यह एक सफलता और त्रुटि हैंडलर दोनों के साथ एक वादा करे। यहाँ निश्चित कोड है:

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise
      .then((val) =>
        hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
      )
      .catch((error) =>
        hasCanceled_ ? reject({isCanceled: true}) : reject(error)
      );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

@alangpierce यह सही के बहुत करीब है, लेकिन काफी नहीं; यदि resolve() या reject() किसी भी कारण से एक हल किए गए वादे पर समकालिक रूप से फेंकता है, तो दोनों हैंडलर को बुलाया जाएगा।

समाधान .then(onFulfilled, onRejected) पैटर्न का उपयोग करना है:

const makeCancelable = (promise) => {
  let hasCanceled_ = false;

  const wrappedPromise = new Promise((resolve, reject) => {
    promise.then(
      (val) => hasCanceled_ ? reject({isCanceled: true}) : resolve(val),
      (error) => hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    );
  });

  return {
    promise: wrappedPromise,
    cancel() {
      hasCanceled_ = true;
    },
  };
};

क्या यह प्रभावी रूप से रद्द करने योग्य समाधान नहीं है, वही isMounted() कॉल है जब बिंदु 3 को देखते हुए कि isMounted() को बहिष्कृत क्यों किया जाता है:

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

एक कॉलबैक कोई बड़ी बात नहीं है। हालांकि, वह कॉलबैक ऑब्जेक्ट्स और इंटरमीडिएट कॉलबैक, वादे और सब्सक्रिप्शन पर लटकता है। यदि आपके बहुत से घटक ऐसा करते हैं, तो आप जल्दी से स्मृति समस्याओं में भाग लेंगे

makeCancellable बस एक और वादा बनाता है जो घटक के संदर्भ वाले कार्यों के संदर्भ में समाप्त होता है। मेक कैंसेलेबल समाधान सिर्फ बूलियन संपत्ति को वादे में ले जा रहा है।

जीसी मुद्दे को हल करने के लिए आपको रद्द करने() को कॉल करने पर कुछ रद्द करने की आवश्यकता है। अन्यथा आपके पास अभी भी एसिंक प्रक्रिया से घटक तक एक संदर्भ श्रृंखला है।

class CancellableDeferred {
  constructor(request) {
    this.deferred = $.Deferred();

    request.then((data) => {
      if (this.deferred != null) {
        this.deferred.resolve(data);
      }
    });

    request.fail((data) => {
      if (this.deferred != null) {
        this.deferred.reject(data);
      }
    });
  }

  cancel() {
    this.deferred = null;
  } 

  promise() {
    return this.deferred.promise();
  }
}

-> यह है कि मैं इसे jQuery आस्थगित वस्तुओं के साथ कैसे करूंगा। मैं वास्तव में प्रॉमिस एपीआई से परिचित नहीं हूं इसलिए मुझे नहीं पता कि यह कैसा दिखेगा। साथ ही, यह स्थगित को अस्वीकार नहीं करता है जब रद्द() को कॉल किया गया है और स्थगित को हल नहीं किया गया है। शायद, यह कैसे काम करना चाहिए, इस पर लोगों की अलग राय है।

तो चेन कुछ इस तरह दिखती है:

AJAX अनुरोध -> बंद -> CancellableDeferredInstance -> JQuery स्थगित -> घटक

फिर रद्द करने के बाद ऐसा दिखता है:

AJAX अनुरोध -> बंद -> रद्द करने योग्यDeferredInstance/वस्तु संदर्भ अब शून्य/JQuery स्थगित -> घटक

इसलिए AJAX अनुरोध अब घटक को GCd होने से नहीं रोक रहा है [यह मानते हुए कि मैंने गलती से स्थगित करने के लिए एक संदर्भ धारण करके कहीं भी कार्यान्वयन को खराब नहीं किया है। याय बंद ....]

हाय @benmmurphy , मैं जेएस कचरा संकलन से सुपर परिचित नहीं हूं और यह रिएक्ट के साथ अलग तरह से काम कर सकता है, लेकिन मुझे एक अलग समझ है।

makeCancellable एक प्रतिक्रिया घटक को अनमाउंट होने पर कचरा एकत्र करने की अनुमति देता है। मैं समझाता हूँ।

makeCancellable बस एक और वादा बनाता है जो घटक के संदर्भ वाले कार्यों के संदर्भ में समाप्त होता है। मेक कैंसेलेबल समाधान सिर्फ बूलियन संपत्ति को वादे में ले जा रहा है।

बिना makeCancellable :

handleError() {
  if (this.isMounted()) {
    console.log('ERROR')
  }
}

makeCancellable :

promise.then(...).fail((reason) => {
  if (reason.isCancelled) return;
  console.log('ERROR');
})

makeCancellable बिना आपके पास अभी भी this संदर्भ है,

@vpontis

मेरे पास कुछ नोडज कोड है जो समस्या को दिखाता है। एक बार एसिंक्रोनस कॉलबैक resolve को शून्य पर सेट करने के बाद Foo घटक केवल GC'd होगा। उदाहरण के लिए मान लें कि आप एक अजाक्स अनुरोध को बंद कर देते हैं जिसे हल करने में 30s लगते हैं तो घटक अनमाउंट किया जाता है। तब घटक 30 के लिए GCd नहीं होगा। यह उन समस्याओं में से एक है जिन्हें वे isMount() पदावनत करने के साथ हल करने का प्रयास कर रहे हैं।

npm install promise
npm install weak

node --expose-gc gc.js
first gc Foo {}
after first gc Foo {}
after resolve = null Foo {}
foo gc'd
after second gc {}

https://gist.github.com/benmmurphy/aaf35a44a6e8a1fbae1764ebed9917b6

संपादित करें:

आपसे बात करने के लिए खेद है, लेकिन पहली बार जब मैंने पोस्ट पढ़ी तो मुझे वह बात समझ में नहीं आई जिसे आप बनाने की कोशिश कर रहे थे, लेकिन अब मुझे लगता है कि मैं करता हूं। मुझे लगता है कि आप जो कहने की कोशिश कर रहे हैं वह यह है कि त्रुटि कॉलबैक में घटक का संदर्भ नहीं है (या घटक के संदर्भ का पालन नहीं करता है) तो घटक को वादे द्वारा संदर्भित नहीं माना जाता है। यह वास्तव में सच है। वैसे पहला भाग सत्य है। हालाँकि, इस तर्क में समस्याएँ हैं:

1) भले ही आपके उदाहरण में त्रुटि हैंडलर में घटक का संदर्भ न हो, then() कॉलबैक आमतौर पर होगा। उदाहरण के लिए then हैंडल आमतौर पर this.setState(...) ।
2) भले ही आपके उदाहरण में त्रुटि हैंडलर में उस घटक का संदर्भ न हो जो अधिकांश त्रुटि हैंडलर करेंगे। उदाहरण के लिए वे कुछ ऐसा करेंगे:

promise.then(...).fail((reason) => {
  if (reason.isCancelled) return;
  console.log('ERROR');

  this.setState({error: true});
})

3) भले ही हम जानते हैं कि कोड then() कॉलबैक का पालन नहीं करेगा और हम जानते हैं कि यह isCancelled चर की जांच के बाद फ़ंक्शन से बाहर निकल जाएगा, जीसी को यह नहीं पता है।

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

वादा एपीआई के संदर्भ में यह मेरे लिए जीसी के संदर्भ में नोडज में काम करता है। हालांकि, मैं बंद होने के पास _resolve , _reject पैराम्स नहीं रखना पसंद करूंगा क्योंकि मुझे यकीन नहीं है कि यह जेएस स्पेक के अनुसार काम करने की गारंटी है या यदि यह काम करने के लिए होता है क्योंकि नोड कुछ अनुकूलन कर रहा है। क्या कोई कार्यान्वयन दृश्यमान सभी चर या केवल वेरिएबल को कैप्चर कर सकता है जिन्हें बंद करने में संदर्भित किया गया है? मुझे पता नहीं है कि कोई व्यक्ति जो वास्तव में जेएस को समझता है वह झंकार कर सकता है और समझा सकता है :)

var makeCancelable = (promise) => {
  let resolve;
  let reject;

  const wrappedPromise = new Promise((_resolve, _reject) => {
    resolve = _resolve;
    reject = _reject;

    promise.then((val) => {
       if (resolve != null) resolve(val)
    });
    promise.catch((error) => {
       if (reject != null) reject(error)
    });
  });

  return {
    promise: wrappedPromise,
    cancel() {
      resolve = null;
      reject = null;
    },
  };
};

क्या माउंटेड फ़ंक्शन को 16.0 में हटा दिया जाएगा?

@Istarkov कोड के साथ छोटे सुधार के लिए सुझाव:

const makeCancelable = (promise) => {
    let hasCanceled_ = false
    promise.then((val) =>
        hasCanceled_ ? reject({isCanceled: true}) : resolve(val)
    )
    .catch((error) =>
        hasCanceled_ ? reject({isCanceled: true}) : reject(error)
    )

    return {
        promise,
        cancel() {
            hasCanceled_ = true
        }
    }
}

बात बस इतनी सी है कि नया वादा बेमानी है।

बात बस इतनी सी है कि नया वादा बेमानी है।

@BnayaZil आप resolve और reject फ़ंक्शंस को कॉल कर रहे हैं, लेकिन यह स्पष्ट नहीं है कि वे कहां से हैं। क्या आपका मतलब Promise.resolve और Promise.reject ? उस स्थिति में, आप अभी भी एक नया वादा वापस कर रहे होंगे।

कुछ दिनों पहले DOM विनिर्देशन में एक नया API जोड़ा गया था जो आपको fetch() अनुरोधों को निरस्त करने की अनुमति देता है। यह एपीआई अभी तक किसी भी ब्राउज़र में लागू नहीं किया गया है, लेकिन मैंने इसके लिए एक पॉलीफिल बनाया है जो एनपीएम पर उपलब्ध है "abortcontroller-polyfill"। पॉलीफिल अनिवार्य रूप से

विवरण यहाँ:
https://mo.github.io/2017/07/24/abort-fetch-abortcontroller-polyfill.html

चूंकि React.createClass अब रिएक्ट 16 में मौजूद नहीं है और नए create-react-class पैकेज में isMounted लिए एक स्पष्ट बहिष्करण संदेश शामिल है, मैं इसे बंद करने जा रहा हूं।

मैं @benmmurphy से सहमत @istarkov का समाधान प्रभावी रूप से isMounted() का उपयोग करने जैसा ही है क्योंकि यह कचरा संग्रहण समस्या का समाधान नहीं करता है।

@benmmurphy का समाधान करीब है लेकिन गलत चर को संदर्भित नहीं किया जाता है।

कुंजी बंद करने के माध्यम से एक फ़ंक्शन पास कर रही है जो हैंडलर को संदर्भित करती है:

const makeCancelable = promise => {
  let cancel = () => {};

  const wrappedPromise = new Promise((resolve, reject) => {
    cancel = () => {
      resolve = null;
      reject = null;
    };

    promise.then(
      val => {
        if (resolve) resolve(val);
      },
      error => {
        if (reject) reject(error);
      }
    );
  });

  wrappedPromise.cancel = cancel;
  return wrappedPromise;
};

इस समाधान के बारे में और स्पष्टीकरण कि यह समाधान कचरा संग्रहण की अनुमति क्यों देता है और पिछले समाधान यहां नहीं मिल सकते

मैंने आगे बढ़कर इसे npm पैकेज में बदल दिया, ट्रैशेबल-प्रतिक्रिया हो जाता है तो उन्हें रद्द कर देता है।

संपादित करें: मेरा बुरा, मैंने अभी @hjylevis थ्रैशेबल को देखा, और यह वादों को भी रद्द करता है। फिर भी नीचे दिया गया पैटर्न आईएमओ एक छोटा सा सुधार है।

इनमें से कोई भी समाधान वादे को

function makeCancelable(promise) {
  let active = true;
  return {
    cancel() {active = false},
    promise: promise.then(
      value => active ? value : new Promise(()=>{}),
      reason => active ? reason : new Promise(()=>{})
    )
  }
}

// used as above:

const {promise, cancel} = makeCancelable(Promise.resolve("Hey!"))

promise.then((v) => console.log(v)) // never logs
cancel()

यहां रहते हैं

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

@pygy उत्तर के लिए धन्यवाद!

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

आप इस कार्यान्वयन को ट्रैशेबल में

आपका कार्यान्वयन भी त्रुटियों को ठीक से संभालने में विफल रहता है।

यह 2018 है क्या ऊपर बताए गए से भी बेहतर तरीका है?

हां, आप कुछ नेविगेशन ढांचे का उपयोग कर सकते हैं जिनके पास मूल निवासी प्रतिक्रिया के आकार से दोगुना दस्तावेज है लेकिन यह बहुत ही पेशेवर है

एक वादा "रद्द" करने के लिए ये स्निपेट महान IMHO नहीं हैं। रद्द किए गए वादे तब भी हल नहीं होंगे जब तक कि मूल वादा हल नहीं हो जाता। तो मेमोरी क्लीनअप तब तक नहीं होगा जब तक कि आप सिर्फ एक माउंटेड ट्रिक का इस्तेमाल नहीं करते।

एक उचित रद्द करने योग्य वादा रैपर को दूसरे वादे और Promise.race का उपयोग करना होगा। यानी Promise.race([originalPromise, cancelationPromise])

@benmmurphy का समाधान करीब है लेकिन गलत चर को संदर्भित नहीं किया जाता है।

मुझे लगता है कि मेरा समाधान काम करता है लेकिन मुझे इस बारे में पर्याप्त जानकारी नहीं है कि जावास्क्रिप्ट रनटाइम निश्चित रूप से क्या वादा करता है। यदि आप अपने परीक्षण में नोड के तहत समाधान चलाते हैं तो यह सही ढंग से जीसी मूल्य का उपयोग करता है। मेरे समाधान ने संकल्प/अस्वीकार कार्यों को उच्च दायरे में असाइन किया और फिर रद्द किए जाने पर इन मानों को हटा दिया। हालाँकि, फ़ंक्शंस अभी भी निचले दायरे में उपलब्ध थे लेकिन संदर्भित नहीं थे। मुझे लगता है कि आधुनिक जावास्क्रिप्ट इंजन बंद होने तक चर को कैप्चर नहीं करते हैं जब तक कि उन्हें संदर्भित नहीं किया जाता है। मुझे लगता है कि यह एक बड़ी समस्या हुआ करती थी जहां लोग गलती से डोम लीक बना लेते थे क्योंकि उन्होंने सामान किया था: var element = findDOM (); element.addEventListener ('क्लिक', फ़ंक्शन() {}); और तत्व को बंद करने में संदर्भित किया जाएगा, भले ही इसे बंद करने में उपयोग नहीं किया गया हो।

@hjylewis @benmmurphy हमें हैंडलर्स को हटाने की आवश्यकता क्यों है ?? संचालकों के उत्साहित होने के बाद, कचरा संग्रहण किसी भी तरह से होता है, है ना ??

एक वादा "रद्द" करने के लिए ये स्निपेट महान IMHO नहीं हैं। रद्द किए गए वादे तब भी हल नहीं होंगे जब तक कि मूल वादा हल नहीं हो जाता। तो मेमोरी क्लीनअप तब तक नहीं होगा जब तक कि आप सिर्फ एक माउंटेड ट्रिक का इस्तेमाल नहीं करते।

एक उचित रद्द करने योग्य वादा रैपर को दूसरे वादे और Promise.race का उपयोग करना होगा। यानी Promise.race([originalPromise, cancelationPromise])

@hjylewis और मेरा क्या आप वास्तव में काम करते हैं आप इसे कमजोर नोड के साथ सत्यापित कर सकते हैं। लेकिन उन्हें फिर से देखकर मैं सहमत हूं कि उनमें से कोई भी मूर्खतापूर्ण लिखित वादा कोड नहीं है। एक वादा उपयोगकर्ता के रूप में आप संभावित रूप से अस्वीकार किए गए राज्य में हल करने के लिए 'रद्द' वादे की अपेक्षा करेंगे और उनमें से कोई भी ऐसा नहीं करेगा। हालांकि, संभवतः एक घटक के मामले में यह एक ऐसा समाधान है जिसका उपयोग करना आसान होगा क्योंकि आपको अस्वीकार करने वाले हैंडलर को अनदेखा करने के लिए अतिरिक्त कोड लिखने की आवश्यकता नहीं है।

मुझे लगता है कि एक मूर्खतापूर्ण अस्वीकार्य वादा एक रद्द करने योग्य वादा बनाने के लिए Promise.race([]) का उपयोग करेगा। यह काम करता है क्योंकि जब कोई वादा हल हो जाता है तो लंबित कॉलबैक हटा दिए जाते हैं, इसलिए उस बिंदु पर ब्राउज़र नेटवर्क से आपके घटक के लिए कोई संदर्भ श्रृंखला नहीं होगी क्योंकि अब रेस वादे और घटक के बीच कोई संदर्भ नहीं होगा।

मुझे उत्सुकता है कि अगर किसी तरह से उन रद्द करने योग्य वादों के साथ Promise.all() का उपयोग करना संभव है और ब्राउज़र कंसोल में अनकही त्रुटियों से बचना है ...

यह 2018 है क्या ऊपर बताए गए से भी बेहतर तरीका है?

किसी वादे के निष्पादन को रद्द करने के लिए कोई बेहतर तरीका यानी, सेटटाइमआउट, एपीआई कॉल आदि। यह 2019 है

टीसी39 पर प्रॉमिस कैंसिलेशन थ्रेड चल रहा है, (मुझे लगता है) यह यहां प्रासंगिकता का है (शायद .. निश्चित नहीं)
https://github.com/tc39/proposal-cancellation/issues/24

किसी वादे के निष्पादन को रद्द करने के लिए कोई बेहतर तरीका यानी, सेटटाइमआउट, एपीआई कॉल आदि। यह 2019 है

क्या हम कुछ ऐसा ढूंढ रहे हैं

const promise = new Promise(r => setTimeout(r, 1000))
  .then(() => console.log('resolved'))
  .catch(()=> console.log('error'))
  .canceled(() => console.log('canceled'));

// Cancel promise
promise.cancel();