ErrorBoundary रिएक्ट घटकों से उत्पन्न त्रुटियों को पकड़ने के लिए एक शानदार उपकरण है। आप त्रुटि की प्रकृति और स्थान के अनुसार कस्टम त्रुटि संदेश प्रदान कर सकते हैं। लेकिन सभी त्रुटियों को ErrorBoundary द्वारा नियंत्रित नहीं किया जाता है! आप उनके साथ क्या करते हैं?

जब रिएक्ट के बाहर से आने वाली एसिंक त्रुटियों और त्रुटियों दोनों पर विचार किया जाता है, तो ErrorBoundary कम हो जाती है। इसे कम करने के लिए, मैंने अपने एप्लिकेशन में एक ग्लोबल एररहैंडलर बनाया है। एक कार्यात्मक घटक जो बस ए) एक त्रुटि संवाद पॉप अप करता है, उपयोगकर्ता को बताता है कि कुछ गलत हो गया, बी) त्रुटि को सर्वर पर लॉग करता है, ताकि हम जांच कर सकें और समाधान ढूंढ सकें।

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

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

क्या त्रुटि पहले ही संभाल ली गई है

एररबाउंडरी द्वारा किए गए हैंडलिंग के शीर्ष पर अनावश्यक संवादों के साथ अंतिम उपयोगकर्ताओं को परेशान करने से पहले, हमें सबसे पहले त्रुटि पूछना शुरू करना होगा: क्या आपको पहले ही हैंडल किया जा चुका है? इसका मेरा समाधान, त्रुटि-ऑब्जेक्ट isHandledByBoundary पर एक नया फ़ील्ड पेश करना है। इसे ErrorBoundary के अंतर्गत सत्य पर सेट किया गया है:

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    (error as any).isHandledByBoundary = true;
    ....
  }

सभी ErrorBoundary-घटकों (और अन्य मशीनरी जो ध्यान में न आई त्रुटियों को संभालती हैं) में इसे लागू करने के साथ, हम अपने GlobalErrorHandler को परिभाषित करना शुरू करने के लिए तैयार हैं।

नंगा कंकाल

फिर हम अपने ग्लोबलएररहैंडलर का ढांचा बना सकते हैं। यह सीधे तौर पर अपने बच्चों को प्रस्तुत करता है, और यह अन्यत्र परिभाषित "ErrorDialog" को भी प्रस्तुत करता है। (यदि आप इस घटक को सभी अनुप्रयोगों में साझा करना चाहते हैं, तो ErrorDialog इसके बजाय एक सहारा हो सकता है।)

import { useState, useEffect, ReactNode } from 'react';
import { ErrorDialog } from '../Components/ErrorDialog';

type Props = {
  children: ReactNode;
};

export function GlobalErrorHandler({ children }: Props) {
  const [error, setError] = useState(null);
  const [isDialogOpen, setDialogOpen] = useState(false);

  useEffect(() => {
    ....
  }, []);

  function handleCloseDialog() {
    setDialogOpen(false);
    setError(null);
  }

  return (
    
      {children}

      {isDialogOpen && error && (
        
      )}
    >
  );
}

अब हमारे पास केवल एक चीज की कमी है, वह है त्रुटि प्रबंधन, जो कि यूज़इफेक्ट के भीतर परिभाषित है।

त्रुटियों को संभालना

इस अनुभाग के सभी कोड यूज़इफ़ेक्ट फ़ंक्शन के भीतर स्थित होने चाहिए!

सबसे पहले हम HandleWindowError को परिभाषित करते हैं। इसे विंडो-ऑब्जेक्ट पर त्रुटि इवेंट-हैंडलर को डिलीवर किया जाना है। यहां कुछ भी रहस्यमय नहीं है, लेकिन गवाह है कि त्रुटि घटना में स्रोत, लाइन नंबर और कॉलम नंबर के बारे में भी जानकारी शामिल है। जिसे एकत्र करना मूल्यवान हो सकता है।

आमतौर पर यह जानकारी त्रुटि ऑब्जेक्ट में भी पाई जाती है, लेकिन मुझे इसमें और अधिक अनुभवजन्य जांच करने की आवश्यकता है। शायद हमें हमेशा त्रुटि-घटना द्वारा रिपोर्ट की गई लाइन और कॉलम संख्याएं रखनी चाहिए? उस स्थिति में, हमारे पास GlobalErrorHandler के भीतर इसके लिए एक स्थिति भी हो सकती है (और सुनिश्चित करें कि त्रुटि लॉग करते समय यह भेजा गया है)।

   function handleWindowError(
      message: string | Event,
      source?: string,
      lineno?: number,
      colno?: number,
      error?: Error
    ) {
      if (error && (error as any).isHandledByBoundary) {
        return true;
      }

      const errorMessage = error
        ? error
        : `Error: ${message} at ${source}:${lineno}:${colno}`;
      setError(errorMessage);
      setDialogOpen(true);
      return true;
    }

हम हैंडलअनहैंडलरिजेक्शन हैंडलर को भी परिभाषित करेंगे। यह उन त्रुटियों के लिए है जो वादों के भीतर उत्पन्न होती हैं, लेकिन जहां हम .catch()-क्लॉज लिखना भूल गए हैं।

    function handleUnhandledRejection(event: PromiseRejectionEvent) {
      setError(`Unhandled promise rejection: ${event.reason}`);
      setDialogOpen(true);
    }

तब हमें बस श्रोताओं को सेटअप करना है, और जब भी ग्लोबल एररहैंडलर प्रस्तुत नहीं किया जाता है तो श्रोताओं को हटा देना है:

    window.addEventListener('error', handleWindowError);
    window.addEventListener('unhandledrejection', handleUnhandledRejection);

    return () => {
      window.removeEventListener('error', handleWindowError);
      window.removeEventListener(
        'unhandledrejection',
        handleUnhandledRejection
      );
    };

निश्चित रूप से, रिटर्न स्टेटमेंट वह है, जहां हम उस फ़ंक्शन से बाहर लौटते हैं जिसे हम उपयोग प्रभाव खिला रहे हैं। यह सुनिश्चित करता है कि हम घटनाओं को सुनना शुरू कर रहे हैं और जब घटक प्रस्तुत होता है तो उन्हें संभालते हैं, और जब घटक प्रस्तुत नहीं होता है तो रुक जाते हैं।

इस प्रकार हमारे रिएक्ट-एप्लिकेशन में उन खतरनाक त्रुटियों को संभालने के लिए हमारे पास एक ग्लोबलइवेंटहैंडलर है, जो या तो एसिंक्रोनस स्रोतों से फेंकी जाती हैं, या रिएक्ट घटकों के बाहर से फेंकी जाती हैं!