फ़ेच एपीआई का इस्तेमाल करते समय गड़बड़ी ठीक करने के तरीके को लागू करें

इस लेख में, Fetch API का इस्तेमाल करते समय, गड़बड़ी को मैनेज करने के कुछ तरीके बताए गए हैं. Fetch API की मदद से, किसी रिमोट नेटवर्क संसाधन का अनुरोध किया जा सकता है. रिमोट नेटवर्क कॉल करने पर, आपके वेब पेज पर नेटवर्क से जुड़ी कई तरह की गड़बड़ियां हो सकती हैं.

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

नेटवर्क से जुड़ी संभावित गड़बड़ियों का अनुमान लगाना

इस सेक्शन में एक स्थिति के बारे में बताया गया है. इसमें उपयोगकर्ता, "My Travels.mp4" नाम का एक नया वीडियो बनाता है और फिर वीडियो शेयर करने वाली वेबसाइट पर उसे अपलोड करने की कोशिश करता है.

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

उपयोगकर्ता की ओर से होने वाली गड़बड़ियों के उदाहरण

  • उपयोगकर्ता, वीडियो फ़ाइल के बजाय इमेज फ़ाइल (जैसे, JPEG) अपलोड करता है.
  • उपयोगकर्ता गलत वीडियो फ़ाइल अपलोड करना शुरू कर देता है. इसके बाद, अपलोड के दौरान उपयोगकर्ता, अपलोड करने के लिए सही वीडियो फ़ाइल चुनता है.
  • वीडियो अपलोड होने के दौरान, उपयोगकर्ता गलती से "अपलोड रद्द करें" पर क्लिक कर देता है.

पर्यावरण में होने वाले बदलावों के उदाहरण

  • वीडियो अपलोड होने के दौरान इंटरनेट कनेक्शन बंद हो जाता है.
  • वीडियो अपलोड होने के दौरान ब्राउज़र रीस्टार्ट हो जाता है.
  • वीडियो अपलोड होने के दौरान, वीडियो शेयर करने वाली वेबसाइट के सर्वर रीस्टार्ट हो जाते हैं.

वीडियो शेयर करने वाली वेबसाइट से जुड़ी गड़बड़ियों के उदाहरण

  • वीडियो शेयर करने वाली वेबसाइट, स्पेस वाली फ़ाइल का नाम नहीं दिखा सकती. "My Travels.mp4" के बजाय, "My_Travels.mp4" या "MyTravels.mp4" जैसा कोई नाम डालें.
  • वीडियो शेयर करने वाली वेबसाइट, ऐसा वीडियो अपलोड नहीं कर सकती जिसका साइज़, तय किए गए साइज़ से ज़्यादा हो.
  • वीडियो शेयर करने वाली वेबसाइट, अपलोड किए गए वीडियो में वीडियो कोडेक के साथ काम नहीं करती.

ये उदाहरण, असल दुनिया में हो सकते हैं और हो भी रहे हैं. ऐसा हो सकता है कि आपको पहले भी इस तरह के उदाहरण मिले हों! आइए, पिछली सभी कैटगरी में से एक उदाहरण चुनें और इन बातों पर चर्चा करें:

  • अगर वीडियो शेयर करने वाली सेवा, दिए गए उदाहरण को हैंडल नहीं कर सकती, तो डिफ़ॉल्ट रूप से क्या होगा?
  • उदाहरण में, उपयोगकर्ता को क्या दिखना चाहिए?
  • हम इस प्रोसेस को कैसे बेहतर बना सकते हैं?
कार्रवाई उपयोगकर्ता गलत वीडियो फ़ाइल अपलोड करना शुरू कर देता है. इसके बाद, अपलोड के दौरान उपयोगकर्ता, अपलोड करने के लिए सही वीडियो फ़ाइल चुनता है.
डिफ़ॉल्ट रूप से क्या होता है नई फ़ाइल अपलोड होने के दौरान, ओरिजनल फ़ाइल बैकग्राउंड में अपलोड होती रहती है.
उपयोगकर्ता क्या चाहता है उपयोगकर्ता चाहता है कि ओरिजनल अपलोड रुक जाए, ताकि इंटरनेट बैंडविड्थ बर्बाद न हो.
क्या बेहतर किया जा सकता है नई फ़ाइल अपलोड होने से पहले, JavaScript ओरिजनल फ़ाइल के लिए फ़ेच करने का अनुरोध रद्द कर देता है.
कार्रवाई वीडियो अपलोड करने के दौरान, उपयोगकर्ता का इंटरनेट कनेक्शन बंद हो जाता है.
डिफ़ॉल्ट रूप से क्या होता है अपलोड की प्रोग्रेस बार 50% पर रुक गई है. आखिर में, फ़ेच एपीआई को टाइम आउट का सामना करना पड़ता है और अपलोड किया गया डेटा खारिज कर दिया जाता है. इंटरनेट कनेक्शन वापस आने पर, उपयोगकर्ता को अपनी फ़ाइल फिर से अपलोड करनी होगी.
उपयोगकर्ता क्या उम्मीद करता है उपयोगकर्ता को यह उम्मीद होती है कि अगर उसकी फ़ाइल अपलोड नहीं हो पा रही है, तो उसे इसकी सूचना दी जाएगी. साथ ही, इंटरनेट कनेक्शन वापस आने पर, फ़ाइल अपलोड करने की प्रोसेस अपने-आप 50% तक फिर से शुरू हो जाएगी.
क्या बेहतर किया जा सकता है अपलोड पेज पर, उपयोगकर्ता को इंटरनेट कनेक्शन से जुड़ी समस्याओं के बारे में बताया जाता है. साथ ही, उसे यह भी बताया जाता है कि इंटरनेट कनेक्शन वापस आने पर, अपलोड की प्रोसेस फिर से शुरू हो जाएगी.
कार्रवाई वीडियो शेयर करने वाली वेबसाइट, स्पेस में फ़ाइल नाम को मैनेज नहीं कर सकती. "My Travels.mp4" के बजाय, "My_Travels.mp4" या "MyTravels.mp4" जैसे नाम इस्तेमाल करें.
डिफ़ॉल्ट रूप से क्या होता है उपयोगकर्ता को अपलोड पूरा होने का इंतज़ार करना होगा. फ़ाइल अपलोड होने के बाद, प्रोग्रेस बार में "100%" दिखने पर, प्रोग्रेस बार में यह मैसेज दिखता है: "कृपया फिर से कोशिश करें."
उपयोगकर्ता क्या चाहता है उपयोगकर्ता को अपलोड शुरू होने से पहले या कम से कम अपलोड के पहले सेकंड में, फ़ाइल नाम से जुड़ी सीमाओं के बारे में बताया जाना चाहिए.
क्या बेहतर किया जा सकता है आम तौर पर, वीडियो शेयर करने वाली सेवा, स्पेस वाले फ़ाइल नामों के साथ काम करती है. इसके अलावा, अपलोड शुरू करने से पहले, उपयोगकर्ता को फ़ाइल नाम की सीमाओं के बारे में सूचना दी जा सकती है. इसके अलावा, वीडियो शेयर करने वाली सेवा को गड़बड़ी के बारे में पूरी जानकारी देने वाले मैसेज के साथ, वीडियो अपलोड करने की अनुमति नहीं देनी चाहिए.

फे़च एपीआई की मदद से गड़बड़ियां मैनेज करना

ध्यान दें कि कोड के इन उदाहरणों में, टॉप लेवल await (ब्राउज़र सहायता) का इस्तेमाल किया गया है, क्योंकि यह सुविधा आपके कोड को आसान बना सकती है.

जब Fetch API गड़बड़ियां दिखाता है

इस उदाहरण में, try ब्लॉक में आने वाली गड़बड़ियों को पकड़ने के लिए, try/catch ब्लॉक स्टेटमेंट का इस्तेमाल किया गया है. उदाहरण के लिए, अगर Fetch API, तय किए गए संसाधन को फ़ेच नहीं कर पाता है, तो गड़बड़ी का मैसेज दिखता है. इस तरह के catch ब्लॉक में, उपयोगकर्ता को काम का अनुभव देने का ध्यान रखें. अगर उपयोगकर्ता को कोई स्पिनर दिखाया जाता है, तो catch ब्लॉक में ये कार्रवाइयां की जा सकती हैं:

  1. पेज से स्पिनर हटाएं.
  2. उपयोगकर्ता को काम के मैसेज भेजें. इनमें यह जानकारी होनी चाहिए कि क्या गड़बड़ी हुई है और उपयोगकर्ता के पास कौनसे विकल्प हैं.
  3. उपलब्ध विकल्पों के आधार पर, उपयोगकर्ता को "फिर से कोशिश करें" बटन दिखाएं.
  4. पर्दे के पीछे, अपनी गड़बड़ी-ट्रैकिंग सेवा या बैक-एंड को गड़बड़ी की जानकारी भेजें. यह कार्रवाई गड़बड़ी को लॉग करती है, ताकि बाद में इसका पता लगाया जा सके.
try {
  const response = await fetch('https://website');
} catch (error) {
  // TypeError: Failed to fetch
  console.log('There was an error', error);
}

बाद में, लॉग की गई गड़बड़ी का पता लगाते समय, आपके पास टेस्ट केस लिखने का विकल्प होता है. इससे, उपयोगकर्ताओं को गड़बड़ी का पता चलने से पहले ही, उसे ठीक किया जा सकता है. गड़बड़ी के हिसाब से, यह टेस्ट यूनिट, इंटिग्रेशन या स्वीकार करने से जुड़ा टेस्ट हो सकता है.

जब नेटवर्क स्टेटस कोड में गड़बड़ी दिखती है

कोड का यह उदाहरण ऐसी एचटीटीपी टेस्टिंग सेवा के लिए अनुरोध करता है जो हमेशा एचटीटीपी स्टेटस कोड 429 Too Many Requests के साथ जवाब देती है. दिलचस्प बात यह है कि जवाब, catch ब्लॉक तक नहीं पहुंचता. कुछ अन्य स्थिति कोड के साथ-साथ 404 स्थिति, नेटवर्क की गड़बड़ी नहीं दिखाती है. इसके बजाय, यह सामान्य रूप से ठीक हो जाती है.

यह देखने के लिए कि एचटीटीपी स्टेटस कोड सही है या नहीं, इनमें से किसी भी विकल्प का इस्तेमाल किया जा सकता है:

  • Response.ok प्रॉपर्टी का इस्तेमाल करके यह पता लगाएं कि स्टेटस कोड, 200 से 299 की रेंज में था या नहीं.
  • जवाब सही है या नहीं, यह पता लगाने के लिए Response.status प्रॉपर्टी का इस्तेमाल करें.
  • जवाब सही है या नहीं, इसका आकलन करने के लिए, Response.headers जैसे किसी दूसरे मेटाडेटा का इस्तेमाल करें.
let response;

try {
  response = await fetch('https://httpbin.org/status/429');
} catch (error) {
  console.log('There was an error', error);
}

// Uses the 'optional chaining' operator
if (response?.ok) {
  console.log('Use the response here!');
} else {
  console.log(`HTTP Response Code: ${response?.status}`)
}

सबसे सही तरीका यह है कि आप अपने संगठन और टीम के लोगों के साथ मिलकर, संभावित एचटीटीपी रिस्पॉन्स स्टेटस कोड को समझें. बैकएंड डेवलपर, डेवलपर ऑपरेशंस, और सर्विस इंजीनियर कभी-कभी ऐसे एज केस के बारे में खास जानकारी दे सकते हैं जिनकी आपको शायद उम्मीद न हो.

नेटवर्क के जवाब को पार्स करते समय गड़बड़ी होने पर

इस कोड के उदाहरण में, एक और तरह की गड़बड़ी के बारे में बताया गया है. यह गड़बड़ी, रिस्पॉन्स बॉडी को पार्स करने के दौरान हो सकती है. Response इंटरफ़ेस, अलग-अलग तरह के डेटा को पार्स करने के आसान तरीके उपलब्ध कराता है. जैसे, टेक्स्ट या JSON. नीचे दिए गए कोड में, एचटीटीपी टेस्टिंग सेवा के लिए नेटवर्क अनुरोध किया गया है. यह सेवा, रिस्पॉन्स बॉडी के तौर पर एक एचटीएमएल स्ट्रिंग दिखाती है. हालांकि, रिस्पॉन्स बॉडी को JSON के तौर पर पार्स करने की कोशिश की जाती है, जिससे गड़बड़ी का मैसेज मिलता है.

let json;

try {
  const response = await fetch('https://httpbin.org/html');
  json = await response.json();
} catch (error) {
  if (error instanceof SyntaxError) {
    // Unexpected token < in JSON
    console.log('There was a SyntaxError', error);
  } else {
    console.log('There was an error', error);
  }
}

if (json) {
  console.log('Use the JSON here!', json);
}

आपको अपने कोड को अलग-अलग तरह के रिस्पॉन्स फ़ॉर्मैट के हिसाब से तैयार करना होगा. साथ ही, यह भी पक्का करना होगा कि किसी अनचाहे रिस्पॉन्स की वजह से, उपयोगकर्ता के वेब पेज पर कोई गड़बड़ी न हो.

यहां दी गई स्थिति देखें: आपके पास एक रिमोट रिसॉर्स है, जो मान्य JSON रिस्पॉन्स देता है. साथ ही, इसे Response.json() तरीके से पार्स किया जाता है. ऐसा हो सकता है कि सेवा बंद हो जाए. डाउन होने के बाद, 500 Internal Server Error दिखता है. अगर JSON को पार्स करते समय, गड़बड़ी को ठीक करने के सही तरीकों का इस्तेमाल नहीं किया जाता है, तो उपयोगकर्ता के लिए पेज काम नहीं करेगा. ऐसा इसलिए होता है, क्योंकि गड़बड़ी को ठीक नहीं किया जा सका.

जब नेटवर्क अनुरोध पूरा होने से पहले उसे रद्द करना ज़रूरी हो

इस कोड के उदाहरण में, फ़्लाइट के दौरान किए गए अनुरोध को रद्द करने के लिए AbortController का इस्तेमाल किया गया है. इन-फ़्लाइट अनुरोध, ऐसा नेटवर्क अनुरोध है जो शुरू हो गया है, लेकिन पूरा नहीं हुआ.

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

const controller = new AbortController();
const signal = controller.signal;

// Cancel the fetch request in 500ms
setTimeout(() => controller.abort(), 500);

try {
  const url = 'https://httpbin.org/delay/1';
  const response = await fetch(url, { signal });
  console.log(response);
} catch (error) {
  // DOMException: The user aborted a request.
  console.log('Error: ', error)
}

नतीजा

गड़बड़ियों को मैनेज करने का एक अहम पहलू यह है कि उन अलग-अलग हिस्सों की पहचान की जाए जिनमें गड़बड़ी हो सकती है. हर स्थिति के लिए, यह पक्का करें कि आपके पास उपयोगकर्ता के लिए सही फ़ॉलबैक मौजूद हो. फ़ेच करने के अनुरोध के लिए, खुद से इस तरह के सवाल पूछें:

  • टारगेट सर्वर के बंद होने पर क्या होता है?
  • अगर 'फ़ेच करें' को कोई अनचाहा जवाब मिलता है, तो क्या होता है?
  • अगर उपयोगकर्ता का इंटरनेट कनेक्शन काम नहीं करता है, तो क्या होगा?

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