மீள்திறன் கொண்ட ரியாக்ட் செயலிகளை உருவாக்குதல்: தானியங்கி காம்பொனென்ட் மறுதொடக்க உத்தி

நாம் அனைவரும் இந்தச் சூழலைச் சந்தித்திருப்போம். நீங்கள் ஒரு இணையச் செயலியைப் பயன்படுத்திக் கொண்டிருக்கிறீர்கள், எல்லாம் சீராகச் சென்று கொண்டிருக்கிறது, அப்போது அது நடக்கிறது. ஒரு கிளிக், ஒரு ஸ்க்ரோல், பின்னணியில் ஏற்றப்படும் ஒரு தரவு—திடீரென்று, பக்கத்தின் ஒரு முழுப் பகுதியும் மறைந்துவிடும். அல்லது இன்னும் மோசமாக, முழுத் திரையும் வெள்ளையாகிவிடும். இது ஒரு செங்கல் சுவரில் மோதுவதற்குச் சமமான ஒரு டிஜிட்டல் அனுபவம். இது ஒரு அதிர்ச்சியூட்டும் மற்றும் எரிச்சலூட்டும் அனுபவமாகும், இது பெரும்பாலும் பயனர் பக்கத்தைப் புதுப்பிப்பதில் அல்லது செயலியை முற்றிலுமாக கைவிடுவதில் முடிகிறது.

ரியாக்ட் மேம்பாட்டு உலகில், இந்த 'வெள்ளைத் திரை மரணம்' என்பது ரெண்டரிங் செயல்பாட்டின் போது கையாளப்படாத ஜாவாஸ்கிரிப்ட் பிழையின் விளைவாகும். இயல்பாக, அத்தகைய பிழைக்கு ரியாக்டின் பதில், முழு காம்பொனென்ட் ட்ரீயையும் அவிழ்த்துவிடுவதாகும், இது செயலியை சாத்தியமான சிதைந்த நிலையிலிருந்து பாதுகாக்கிறது. இது பாதுகாப்பானது என்றாலும், இந்த நடத்தை ஒரு மோசமான பயனர் அனுபவத்தை வழங்குகிறது. ஆனால் நமது காம்பொனென்ட்கள் அதிக மீள்திறன் கொண்டதாக இருந்தால் என்ன செய்வது? செயலிழப்பதற்குப் பதிலாக, ஒரு உடைந்த காம்பொனென்ட் அதன் தோல்வியை நேர்த்தியாகக் கையாண்டு, தன்னைத்தானே சரிசெய்ய முயற்சித்தால் என்ன செய்வது?

இதுதான் சுயமாக குணமாகும் UI-யின் வாக்குறுதி. இந்த விரிவான வழிகாட்டியில், ரியாக்டில் பிழை மீட்புக்கான ஒரு சக்திவாய்ந்த மற்றும் நேர்த்தியான உத்தியை ஆராய்வோம்: தானியங்கி காம்பொனென்ட் மறுதொடக்கம். ரியாக்டின் உள்ளமைக்கப்பட்ட பிழை கையாளும் வழிமுறைகளை ஆழமாகப் பார்ப்போம், `key` prop-இன் ஒரு புத்திசாலித்தனமான பயன்பாட்டைக் கண்டுபிடிப்போம், மேலும் செயலி செயலிழப்புகளை தடையற்ற மீட்பு ஓட்டங்களாக மாற்றும் ஒரு வலுவான, உற்பத்திக்குத் தயாரான தீர்வை உருவாக்குவோம். பிழைகளைத் தடுப்பதில் இருந்து, அவை தவிர்க்க முடியாமல் ஏற்படும்போது அவற்றை நேர்த்தியாக நிர்வகிப்பதற்கு உங்கள் மனநிலையை மாற்றத் தயாராகுங்கள்.

நவீன UI-களின் பலவீனம்: ரியாக்ட் காம்பொனென்ட்கள் ஏன் செயலிழக்கின்றன

ஒரு தீர்வைக் உருவாக்குவதற்கு முன், நாம் முதலில் சிக்கலைப் புரிந்து கொள்ள வேண்டும். ஒரு ரியாக்ட் செயலியில் பிழைகள் எண்ணற்ற மூலங்களிலிருந்து வரலாம்: நெட்வொர்க் கோரிக்கைகள் தோல்வியடைவது, API-கள் எதிர்பாராத தரவு வடிவங்களைத் தருவது, மூன்றாம் தரப்பு நூலகங்கள் விதிவிலக்குகளை எறிவது, அல்லது எளிய நிரலாக்கத் தவறுகள். பொதுவாக, இவை நிகழும் நேரத்தைப் பொறுத்து வகைப்படுத்தப்படலாம்:

• ரெண்டரிங் பிழைகள்: இவை மிகவும் அழிவுகரமானவை. இவை ஒரு காம்பொனென்டின் ரெண்டர் முறை அல்லது ரெண்டரிங் கட்டத்தில் அழைக்கப்படும் எந்தவொரு செயல்பாட்டிலும் (வாழ்க்கைச் சுழற்சி முறைகள் மற்றும் ஃபங்ஷன் காம்பொனென்ட்களின் உடல் உட்பட) நிகழ்கின்றன. இங்கு ஒரு பிழை, `null` இல் ஒரு பண்பை அணுக முயற்சிப்பது போன்றவை (`cannot read property 'name' of null`), காம்பொனென்ட் ட்ரீயில் மேல்நோக்கிப் பரவும்.
• நிகழ்வு கையாளுதல் பிழைகள்: இந்தப் பிழைகள் பயனர் தொடர்புக்குப் பதிலாக, `onClick` அல்லது `onChange` கையாளுதலுக்குள் ஏற்படுகின்றன. இவை ரெண்டர் சுழற்சிக்கு வெளியே நிகழ்கின்றன, மேலும் அவை தாமாகவே ரியாக்ட் UI-ஐ உடைக்காது. இருப்பினும், அவை ஒரு சீரற்ற செயலி நிலைக்கு வழிவகுக்கலாம், இது அடுத்த புதுப்பிப்பில் ரெண்டரிங் பிழையை ஏற்படுத்தக்கூடும்.
• ஒத்திசைவற்ற பிழைகள்: இவை ரெண்டர் சுழற்சிக்குப் பிறகு இயங்கும் குறியீட்டில் நிகழ்கின்றன, அதாவது `setTimeout`, `Promise.catch()` பிளாக், அல்லது ஒரு சந்தா கால்பேக். நிகழ்வு கையாளுதல் பிழைகளைப் போலவே, அவை உடனடியாக ரெண்டர் ட்ரீயை செயலிழக்கச் செய்யாது, ஆனால் நிலையை சிதைக்கக்கூடும்.

ரியாக்டின் முதன்மைக் கவலை UI ஒருமைப்பாட்டைப் பராமரிப்பதாகும். ஒரு ரெண்டரிங் பிழை ஏற்படும் போது, ரியாக்டுக்கு செயலியின் நிலை பாதுகாப்பானதா அல்லது UI எப்படி இருக்க வேண்டும் என்று தெரியாது. அதன் இயல்பான, தற்காப்பு நடவடிக்கை ரெண்டரிங்கை நிறுத்திவிட்டு எல்லாவற்றையும் அவிழ்த்துவிடுவதாகும். இது மேலும் சிக்கல்களைத் தடுக்கிறது, ஆனால் பயனரை ஒரு வெற்றுப் பக்கத்தைப் பார்க்க வைக்கிறது. எங்கள் குறிக்கோள் இந்த செயல்முறையை இடைமறித்து, சேதத்தைக் கட்டுப்படுத்தி, மீட்புக்கான ஒரு பாதையை வழங்குவதாகும்.

முதல் தற்காப்புக் கோடு: ரியாக்ட் எர்ரர் பவுண்டரிகளில் தேர்ச்சி பெறுதல்

ரியாக்ட் ரெண்டரிங் பிழைகளைப் பிடிப்பதற்கு ஒரு சொந்த தீர்வை வழங்குகிறது: எர்ரர் பவுண்டரிகள். ஒரு எர்ரர் பவுண்டரி என்பது ஒரு சிறப்பு வகை ரியாக்ட் காம்பொனென்ட் ஆகும், இது அதன் குழந்தை காம்பொனென்ட் ட்ரீயில் எங்கும் ஜாவாஸ்கிரிப்ட் பிழைகளைப் பிடிக்கலாம், அந்தப் பிழைகளைப் பதிவு செய்யலாம், மற்றும் செயலிழந்த காம்பொனென்ட் ட்ரீக்கு பதிலாக ஒரு பின்னடைவு UI-ஐக் காட்டலாம்.

சுவாரஸ்யமாக, எர்ரர் பவுண்டரிகளுக்கு இன்னும் ஹூக் சமமான எதுவும் இல்லை. எனவே, அவை கிளாஸ் காம்பொனென்ட்களாக இருக்க வேண்டும். ஒரு கிளாஸ் காம்பொனென்ட் இந்த இரண்டு வாழ்க்கைச் சுழற்சி முறைகளில் ஒன்று அல்லது இரண்டையும் வரையறுத்தால் அது ஒரு எர்ரர் பவுண்டரியாக மாறும்:

• static getDerivedStateFromError(error): இந்த முறை ஒரு வழித்தோன்றல் காம்பொனென்ட் ஒரு பிழையை எறிந்த பிறகு 'ரெண்டர்' கட்டத்தில் அழைக்கப்படுகிறது. இது காம்பொனென்டின் நிலையைப் புதுப்பிக்க ஒரு ஸ்டேட் ஆப்ஜெக்டைத் திருப்ப வேண்டும், அடுத்த பாஸில் ஒரு பின்னடைவு UI-ஐ ரெண்டர் செய்ய உங்களை அனுமதிக்கிறது.
• componentDidCatch(error, errorInfo): இந்த முறை 'கமிட்' கட்டத்தில், பிழை ஏற்பட்ட பிறகு மற்றும் பின்னடைவு UI ரெண்டர் செய்யப்படும்போது அழைக்கப்படுகிறது. பிழையை ஒரு வெளிப்புற சேவைக்கு பதிவு செய்வது போன்ற பக்க விளைவுகளுக்கு இது சிறந்த இடம்.

ஒரு அடிப்படை எர்ரர் பவுண்டரி எடுத்துக்காட்டு

ஒரு எளிய, மீண்டும் பயன்படுத்தக்கூடிய எர்ரர் பவுண்டரி எப்படி இருக்கும் என்பது இங்கே:

            import React from 'react';

class SimpleErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    console.error("Uncaught error:", error, errorInfo);
    // Example: logErrorToMyService(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children;
  }
}

// How to use it:
<SimpleErrorBoundary>
  <MyPotentiallyBuggyComponent />
</SimpleErrorBoundary>
            

              
                Copy
              
            
          

எர்ரர் பவுண்டரிகளின் வரம்புகள்

சக்திவாய்ந்ததாக இருந்தாலும், எர்ரர் பவுண்டரிகள் ஒரு வெள்ளித் தோட்டா அல்ல. அவை எதைப் பிடிக்காது என்பதைப் புரிந்துகொள்வது முக்கியம்:

• நிகழ்வு கையாளுதல்களுக்குள் உள்ள பிழைகள்.
• ஒத்திசைவற்ற குறியீடு (எ.கா., `setTimeout` அல்லது `requestAnimationFrame` கால்பேக்குகள்).
• சர்வர்-சைட் ரெண்டரிங்கில் ஏற்படும் பிழைகள்.
• எர்ரர் பவுண்டரி காம்பொனென்டிலேயே எறியப்படும் பிழைகள்.

எங்கள் உத்திக்கு மிக முக்கியமாக, ஒரு அடிப்படை எர்ரர் பவுண்டரி ஒரு நிலையான பின்னடைவை மட்டுமே வழங்குகிறது. அது பயனருக்கு ஏதோ உடைந்துவிட்டது என்பதைக் காட்டுகிறது, ஆனால் அது முழு பக்க மறுஏற்றம் இல்லாமல் மீட்க ஒரு வழியை அவர்களுக்கு வழங்காது. இங்குதான் எங்கள் மறுதொடக்க உத்தி செயல்படுகிறது.

முக்கிய உத்தி: `key` Prop உடன் காம்பொனென்ட் மறுதொடக்கத்தைத் திறத்தல்

பெரும்பாலான ரியாக்ட் டெவலப்பர்கள் முதலில் `key` prop-ஐ உருப்படிகளின் பட்டியல்களை ரெண்டர் செய்யும்போது சந்திக்கின்றனர். திறமையான புதுப்பிப்புகளுக்கு, எந்த உருப்படிகள் மாற்றப்பட்டுள்ளன, சேர்க்கப்பட்டுள்ளன, அல்லது அகற்றப்பட்டுள்ளன என்பதை ரியாக்ட் அடையாளம் காண உதவுவதற்காக, ஒரு பட்டியலில் உள்ள ஒவ்வொரு உருப்படிக்கும் ஒரு தனித்துவமான `key`-ஐச் சேர்க்குமாறு நமக்குக் கற்பிக்கப்படுகிறது.

இருப்பினும், `key` prop-இன் சக்தி பட்டியல்களைத் தாண்டியது. இது ரியாக்டின் சமரச வழிமுறைக்கு ஒரு அடிப்படைக் குறிப்பு. இங்கே முக்கியமான நுண்ணறிவு: ஒரு காம்பொனென்டின் `key` மாறும்போது, ரியாக்ட் பழைய காம்பொனென்ட் நிகழ்வையும் அதன் முழு DOM ட்ரீயையும் தூக்கி எறிந்துவிட்டு, புதிதாக ஒன்றை உருவாக்கும். இதன் பொருள் அதன் நிலை முற்றிலும் மீட்டமைக்கப்படுகிறது, மேலும் அதன் வாழ்க்கைச் சுழற்சி முறைகள் (அல்லது `useEffect` ஹூக்குகள்) முதல் முறையாக மவுண்ட் செய்வது போல மீண்டும் இயங்கும்.

இந்த நடத்தை எங்கள் மீட்பு உத்திக்கான மாயாஜால மூலப்பொருள். நமது செயலிழந்த காம்பொனென்டின் (அல்லது அதைச் சுற்றியுள்ள ஒரு ரேப்பரின்) `key`-இல் ஒரு மாற்றத்தை நாம் கட்டாயப்படுத்த முடிந்தால், நாம் அதை திறம்பட 'மறுதொடக்கம்' செய்யலாம். இந்த செயல்முறை இப்படி இருக்கும்:

1. எங்கள் எர்ரர் பவுண்டரிக்குள் ஒரு காம்பொனென்ட் ஒரு ரெண்டரிங் பிழையை எறிகிறது.
2. எர்ரர் பவுண்டரி பிழையைப் பிடித்து, அதன் நிலையை ஒரு பின்னடைவு UI-ஐக் காட்டும்படி புதுப்பிக்கிறது.
3. இந்த பின்னடைவு UI-இல் "மீண்டும் முயற்சிக்கவும்" பொத்தான் உள்ளது.
4. பயனர் பொத்தானைக் கிளிக் செய்யும்போது, எர்ரர் பவுண்டரிக்குள் ஒரு ஸ்டேட் மாற்றத்தைத் தூண்டுகிறோம்.
5. இந்த ஸ்டேட் மாற்றத்தில், குழந்தை காம்பொனென்டிற்கு ஒரு `key`-ஆக நாம் பயன்படுத்தும் மதிப்பை புதுப்பிப்பது அடங்கும்.
6. ரியாக்ட் புதிய `key`-ஐக் கண்டறிந்து, பழைய உடைந்த காம்பொனென்ட் நிகழ்வை அவிழ்த்துவிட்டு, ஒரு புதிய, சுத்தமான ஒன்றை ஏற்றுகிறது.

ஒரு தற்காலிக சிக்கல் (ஒரு தற்காலிக நெட்வொர்க் கோளாறு போன்றவை) தீர்க்கப்பட்ட பிறகு, காம்பொனென்ட் சரியாக ரெண்டர் செய்ய இரண்டாவது வாய்ப்பைப் பெறுகிறது. பயனர் முழுப் பக்கப் புதுப்பிப்பு மூலம் செயலியில் தங்கள் இடத்தை இழக்காமல் மீண்டும் வணிகத்தில் இருக்கிறார்.

படிப்படியான செயல்படுத்தல்: மீட்டமைக்கக்கூடிய எர்ரர் பவுண்டரியை உருவாக்குதல்

நமது `SimpleErrorBoundary`-ஐ இந்த கீ-யால் இயக்கப்படும் மறுதொடக்க உத்தியைச் செயல்படுத்தும் `ResettableErrorBoundary`-ஆக மேம்படுத்துவோம்.

            import React from 'react';

class ResettableErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    // The 'key' state is what we'll increment to trigger a re-render.
    this.state = { hasError: false, errorKey: 0 };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // In a real app, you'd log this to a service like Sentry or LogRocket
    console.error("Error caught by boundary:", error, errorInfo);
  }

  // This method will be called by our 'Try Again' button
  handleReset = () => {
    this.setState(prevState => ({
      hasError: false,
      errorKey: prevState.errorKey + 1
    }));
  };

  render() {
    if (this.state.hasError) {
      // Render a fallback UI with a reset button
      return (
        <div role="alert">
          <h2>Oops, something went wrong.</h2>
          <p>A component on this page failed to load. You can try to reload it.</p>
          <button onClick={this.handleReset}>Try Again</button>
        </div>
      );
    }

    // When there's no error, we render the children.
    // We wrap them in a React.Fragment (or a div) with the dynamic key.
    // When handleReset is called, this key changes, forcing React to re-mount the children.
    return (
      <React.Fragment key={this.state.errorKey}>
        {this.props.children}
      </React.Fragment>
    );
  }
}

export default ResettableErrorBoundary;
            

              
                Copy
              
            
          

இந்த காம்பொனென்டைப் பயன்படுத்த, உங்கள் செயலியின் தோல்வியடையக்கூடிய எந்தப் பகுதியையும் சுற்றி இதை வைக்கவும். உதாரணமாக, சிக்கலான தரவு பெறுதல் மற்றும் செயலாக்கத்தை நம்பியிருக்கும் ஒரு காம்பொனென்ட்:

            import DataHeavyWidget from './DataHeavyWidget';
import ResettableErrorBoundary from './ResettableErrorBoundary';

function Dashboard() {
  return (
    <div>
      <h1>My Dashboard</h1>
      <ResettableErrorBoundary>
        <DataHeavyWidget userId="123" />
      </ResettableErrorBoundary>
      {/* Other components on the dashboard are unaffected */}
      <AnotherWidget />
    </div>
  );
}
            

              
                Copy
              
            
          

இந்த அமைப்புடன், `DataHeavyWidget` செயலிழந்தால், `Dashboard`-இன் மற்ற பகுதிகள் ஊடாடும் வகையில் இருக்கும். பயனர் பின்னடைவு செய்தியைக் காண்கிறார் மற்றும் `DataHeavyWidget`-க்கு ஒரு புதிய தொடக்கத்தை வழங்க "மீண்டும் முயற்சிக்கவும்" என்பதைக் கிளிக் செய்யலாம்.

உற்பத்தி-தர மீள்திறனுக்கான மேம்பட்ட நுட்பங்கள்

நமது `ResettableErrorBoundary` ஒரு சிறந்த தொடக்கமாகும், ஆனால் ஒரு பெரிய அளவிலான, உலகளாவிய செயலியில், நாம் இன்னும் சிக்கலான சூழ்நிலைகளைக் கருத்தில் கொள்ள வேண்டும்.

முடிவற்ற பிழை சுழற்சிகளைத் தடுத்தல்

காம்பொனென்ட் ஒவ்வொரு முறையும் ஏற்றப்பட்டவுடன் உடனடியாக செயலிழந்தால் என்ன செய்வது? கைமுறையான மறுமுயற்சிக்குப் பதிலாக நாம் ஒரு *தானியங்கி* மறுமுயற்சியை செயல்படுத்தினால், அல்லது பயனர் மீண்டும் மீண்டும் "மீண்டும் முயற்சிக்கவும்" என்பதைக் கிளிக் செய்தால், அவர்கள் ஒரு முடிவற்ற பிழை சுழற்சியில் சிக்கிக் கொள்ளலாம். இது பயனருக்கு எரிச்சலூட்டுகிறது மற்றும் உங்கள் பிழைப் பதிவுச் சேவையை ஸ்பேம் செய்யலாம்.

இதைத் தடுக்க, நாம் ஒரு மறுமுயற்சிக் கவுண்டரை அறிமுகப்படுத்தலாம். காம்பொனென்ட் ஒரு குறுகிய காலத்தில் ஒரு குறிப்பிட்ட எண்ணிக்கையிலான முறைகளுக்கு மேல் தோல்வியுற்றால், நாம் மறுமுயற்சி விருப்பத்தை வழங்குவதை நிறுத்திவிட்டு, மேலும் நிரந்தரமான பிழைச் செய்தியைக் காண்பிக்கிறோம்.

            // Inside ResettableErrorBoundary...

constructor(props) {
  super(props);
  this.state = {
    hasError: false,
    errorKey: 0,
    retryCount: 0
  };
  this.MAX_RETRIES = 3;
}

// ... (getDerivedStateFromError and componentDidCatch are the same)

handleReset = () => {
  if (this.state.retryCount < this.MAX_RETRIES) {
    this.setState(prevState => ({
      hasError: false,
      errorKey: prevState.errorKey + 1,
      retryCount: prevState.retryCount + 1
    }));
  } else {
    // After max retries, we can just leave the error state as is
    // The fallback UI will need to handle this case
    console.warn("Max retries reached. Not resetting component.");
  }
};

render() {
  if (this.state.hasError) {
    if (this.state.retryCount >= this.MAX_RETRIES) {
      return (
        <div role="alert">
          <h2>This component could not be loaded.</h2>
          <p>We have tried to reload it multiple times without success. Please refresh the page or contact support.</p>
        </div>
      );
    }
    // Render the standard fallback with the retry button
    // ...
  }
  // ...
}

// Important: Reset retryCount if the component works for some time
// This is more complex and often better handled by a library. We could add a
// componentDidUpdate check to reset the counter if hasError becomes false
// after being true, but the logic can get tricky.

            

              
                Copy
              
            
          

ஹூக்குகளைத் தழுவுதல்: `react-error-boundary` ஐப் பயன்படுத்துதல்

எர்ரர் பவுண்டரிகள் கிளாஸ் காம்பொனென்ட்களாக இருக்க வேண்டும் என்றாலும், ரியாக்ட் சூழல் அமைப்பின் மற்ற பகுதிகள் பெரும்பாலும் ஃபங்ஷனல் காம்பொனென்ட்கள் மற்றும் ஹூக்குகளுக்கு நகர்ந்துவிட்டன. இது ஒரு நவீன மற்றும் நெகிழ்வான API-ஐ வழங்கும் சிறந்த சமூக நூலகங்களின் உருவாக்கத்திற்கு வழிவகுத்துள்ளது. மிகவும் பிரபலமானது `react-error-boundary` ஆகும்.

இந்த நூலகம் நாம் இப்போது உருவாக்கிய அனைத்து தர்க்கத்தையும் (மற்றும் பலவற்றையும்) பெட்டிக்கு வெளியே கையாளும் ஒரு `` காம்பொனென்டை வழங்குகிறது. அதன் உண்மையான சக்தி அதன் இயற்றல் தன்மை மற்றும் ஹூக்குகளுடனான ஒருங்கிணைப்பில் உள்ளது.

            import { ErrorBoundary } from 'react-error-boundary';

function ErrorFallback({ error, resetErrorBoundary }) {
  return (
    <div role="alert">
      <p>Something went wrong:</p>
      <pre>{error.message}</pre>
      <button onClick={resetErrorBoundary}>Try again</button>
    </div>
  );
}

function App() {
  return (
    <ErrorBoundary
      FallbackComponent={ErrorFallback}
      onReset={() => {
        // reset the state of your app so the error doesn't happen again
      }}
      // you can also pass resetKeys prop to automatically reset
      // resetKeys={[someKeyThatChanges]}
    >
      <MyComponent />
    </ErrorBoundary>
  );
}
            

              
                Copy
              
            
          

`react-error-boundary` நூலகம் கவலைகளை நேர்த்தியாகப் பிரிக்கிறது. `ErrorBoundary` காம்பொனென்ட் நிலையை நிர்வகிக்கிறது, மேலும் UI-ஐ ரெண்டர் செய்ய நீங்கள் ஒரு `FallbackComponent`-ஐ வழங்குகிறீர்கள். உங்கள் பின்னடைவுக்கு அனுப்பப்பட்ட `resetErrorBoundary` செயல்பாடு மறுதொடக்கத்தைத் தூண்டுகிறது, `key` கையாளுதலை உங்களுக்காகச் சுருக்குகிறது.

மேலும், இது `useErrorHandler` ஹூக் மூலம் ஒத்திசைவற்ற பிழைகளைக் கையாளும் சிக்கலைத் தீர்க்க உதவுகிறது. நீங்கள் ஒரு `.catch()` பிளாக் அல்லது `try/catch` க்குள் ஒரு பிழை ஆப்ஜெக்டுடன் இந்த ஹூக்கை அழைக்கலாம், அது பிழையை அருகிலுள்ள எர்ரர் பவுண்டரிக்கு பரப்பும், ஒரு ரெண்டரிங் அல்லாத பிழையை உங்கள் பவுண்டரி கையாளக்கூடிய ஒன்றாக மாற்றும்.

உத்திசார்ந்த இடம்: உங்கள் பவுண்டரிகளை எங்கே வைப்பது

ஒரு பொதுவான கேள்வி: "நான் எனது எர்ரர் பவுண்டரிகளை எங்கே வைக்க வேண்டும்?" பதில் உங்கள் செயலியின் கட்டமைப்பு மற்றும் பயனர் அனுபவ இலக்குகளைப் பொறுத்தது. ஒரு கப்பலில் உள்ள தடுப்புகளைப் போல நினைத்துப் பாருங்கள்: அவை ஒரு பகுதிக்கு ஒரு மீறலைக் கட்டுப்படுத்துகின்றன, முழு கப்பலும் மூழ்குவதைத் தடுக்கின்றன.

• உலகளாவிய பவுண்டரி: உங்கள் முழுச் செயலியையும் சுற்றிலும் குறைந்தது ஒரு உயர்-நிலை எர்ரர் பவுண்டரியையாவது வைத்திருப்பது நல்லது. இது உங்கள் கடைசி புகலிடம், பயங்கரமான வெள்ளைத் திரையைத் தடுப்பதற்கான ஒரு பிடிப்பு. இது ஒரு பொதுவான "ஒரு எதிர்பாராத பிழை ஏற்பட்டது. தயவுசெய்து பக்கத்தைப் புதுப்பிக்கவும்." செய்தியைக் காட்டலாம்.
• தளவமைப்பு பவுண்டரிகள்: நீங்கள் பக்கப்பட்டிகள், தலைப்புகள், அல்லது முக்கிய உள்ளடக்கப் பகுதிகள் போன்ற முக்கிய தளவமைப்பு காம்பொனென்ட்களைச் சுற்றிலும் வைக்கலாம். உங்கள் பக்கப்பட்டி வழிசெலுத்தல் செயலிழந்தால், பயனர் இன்னும் முக்கிய உள்ளடக்கத்துடன் தொடர்பு கொள்ளலாம்.
• விட்ஜெட்-நிலை பவுண்டரிகள்: இது மிகவும் நுணுக்கமான மற்றும் பெரும்பாலும் மிகவும் பயனுள்ள அணுகுமுறையாகும். சுயாதீனமான, தன்னிறைவான விட்ஜெட்டுகளை (ஒரு அரட்டை பெட்டி, ஒரு வானிலை விட்ஜெட், ஒரு பங்கு டிக்கர் போன்றவை) அவற்றின் சொந்த எர்ரர் பவுண்டரிகளில் சுற்றவும். ஒரு விட்ஜெட்டில் ஏற்படும் தோல்வி மற்றவற்றைப் பாதிக்காது, இது மிகவும் மீள்திறன் மற்றும் பிழை-சகிப்புத்தன்மை கொண்ட UI-க்கு வழிவகுக்கும்.

ஒரு உலகளாவிய பார்வையாளர்களுக்கு, இது மிகவும் முக்கியமானது. ஒரு தரவு காட்சிப்படுத்தல் விட்ஜெட் ஒரு வட்டார-குறிப்பிட்ட எண் வடிவமைப்பு சிக்கல் காரணமாக தோல்வியடையக்கூடும். அதை ஒரு எர்ரர் பவுண்டரி மூலம் தனிமைப்படுத்துவது, அந்தப் பகுதியில் உள்ள பயனர்கள் உங்கள் செயலியின் மற்ற பகுதிகளைப் பயன்படுத்த முடியும் என்பதை உறுதி செய்கிறது, முற்றிலும் வெளியேற்றப்படுவதற்குப் பதிலாக.

மீட்டெடுப்பது மட்டுமல்ல, புகாரளிக்கவும்: பிழைப் பதிவை ஒருங்கிணைத்தல்

ஒரு காம்பொனென்டை மறுதொடக்கம் செய்வது பயனருக்குச் சிறந்தது, ஆனால் பிழை ஏற்பட்டது என்பதை நீங்கள் முதலில் அறியவில்லை என்றால் டெவலப்பருக்குப் பயனற்றது. `componentDidCatch` முறை (அல்லது `react-error-boundary`-இல் உள்ள `onError` prop) பிழைகளைப் புரிந்துகொள்வதற்கும் சரிசெய்வதற்கும் உங்கள் நுழைவாயிலாகும்.

இந்த நடவடிக்கை ஒரு உற்பத்திச் செயலிக்கு விருப்பமானது அல்ல.

Sentry, Datadog, LogRocket, அல்லது Bugsnag போன்ற ஒரு தொழில்முறை பிழை கண்காணிப்புச் சேவையை ஒருங்கிணைக்கவும். இந்தப் தளங்கள் ஒவ்வொரு பிழைக்கும் விலைமதிப்பற்ற சூழலை வழங்குகின்றன:

• ஸ்டாக் ட்ரேஸ்: பிழையை எறிந்த சரியான குறியீட்டுக் கோடு.
• காம்பொனென்ட் ஸ்டாக்: பிழைக்கு வழிவகுக்கும் ரியாக்ட் காம்பொனென்ட் ட்ரீ, பொறுப்பான காம்பொனென்டைத் துல்லியமாகக் கண்டறிய உதவுகிறது.
• உலாவி/சாதனத் தகவல்: இயக்க முறைமை, உலாவி பதிப்பு, திரைத் தீர்மானம்.
• பயனர் சூழல்: அநாமதேயமாக்கப்பட்ட பயனர் ஐடி, இது ஒரு பிழை ஒரு பயனரை அல்லது பலரைப் பாதிக்கிறதா என்பதைப் பார்க்க உதவுகிறது.
• பிரெட்க்ரம்ப்ஸ்: பிழைக்கு வழிவகுக்கும் பயனர் செயல்களின் ஒரு தடம்.

            // Using Sentry as an example in componentDidCatch
import * as Sentry from "@sentry/react";

class ReportingErrorBoundary extends React.Component {
  // ... state and getDerivedStateFromError ...

  componentDidCatch(error, errorInfo) {
    Sentry.withScope((scope) => {
      scope.setExtras(errorInfo);
      Sentry.captureException(error);
    });
  }

  // ... render logic ...
}
            

              
                Copy
              
            
          

தானியங்கி மீட்பை வலுவான அறிக்கையிடலுடன் இணைப்பதன் மூலம், நீங்கள் ஒரு சக்திவாய்ந்த பின்னூட்ட வளையத்தை உருவாக்குகிறீர்கள்: பயனர் அனுபவம் பாதுகாக்கப்படுகிறது, மேலும் காலப்போக்கில் செயலியை மேலும் நிலையானதாக மாற்றுவதற்குத் தேவையான தரவைப் பெறுகிறீர்கள்.

ஒரு நிஜ உலக வழக்கு ஆய்வு: சுயமாக குணமாகும் தரவு விட்ஜெட்

ஒரு நடைமுறை எடுத்துக்காட்டுடன் அனைத்தையும் ஒன்றிணைப்போம். எங்களிடம் ஒரு `UserProfileCard` உள்ளது என்று கற்பனை செய்து கொள்ளுங்கள், அது ஒரு API-யிலிருந்து பயனர் தரவைப் பெறுகிறது. இந்த கார்டு இரண்டு வழிகளில் தோல்வியடையலாம்: பெறுதலின் போது ஒரு நெட்வொர்க் பிழை, அல்லது API ஒரு எதிர்பாராத தரவு வடிவத்தைத் திருப்பினால் (எ.கா., `user.profile` விடுபட்டிருந்தால்) ஒரு ரெண்டரிங் பிழை.

சாத்தியமான தோல்வியுறும் காம்பொனென்ட்

            import React, { useState, useEffect } from 'react';

// A mock fetch function that can fail
const fetchUser = async (userId) => {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  const data = await response.json();
  // Simulate a potential API contract issue
  if (Math.random() > 0.5) {
    delete data.profile;
  }
  return data;
};

const UserProfileCard = ({ userId }) => {
  const [user, setUser] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;
    const loadUser = async () => {
      try {
        const userData = await fetchUser(userId);
        if (isMounted) setUser(userData);
      } catch (err) {
        if (isMounted) setError(err);
      }
    };
    loadUser();
    return () => { isMounted = false; };
  }, [userId]);

  // We can use the useErrorHandler hook from react-error-boundary here
  // For simplicity, we'll let the render part fail.
  // if (error) { throw error; } // This would be the hook approach

  if (!user) {
    return <div>Loading profile...</div>;
  }

  // This line will throw a rendering error if user.profile is missing
  return (
    <div className="card">
      <img src={user.profile.avatarUrl} alt={user.name} />
      <h3>{user.name}</h3>
      <p>{user.profile.bio}</p>
    </div>
  );
};

export default UserProfileCard;
            

              
                Copy
              
            
          

பவுண்டரியுடன் சுற்றడం

இப்போது, நமது UI-ஐப் பாதுகாக்க `react-error-boundary` நூலகத்தைப் பயன்படுத்துவோம்.

            import React from 'react';
import { ErrorBoundary } from 'react-error-boundary';
import UserProfileCard from './UserProfileCard';

function ErrorFallbackUI({ error, resetErrorBoundary }) {
  return (
    <div role="alert" className="card-error">
      <p>Could not load user profile.</p>
      <button onClick={resetErrorBoundary}>Retry</button>
    </div>
  );
}

function App() {
  // This could be a state that changes, e.g., viewing different profiles
  const [currentUserId, setCurrentUserId] = React.useState('user-1');

  return (
    <div>
      <h1>User Profiles</h1>
      <ErrorBoundary
        FallbackComponent={ErrorFallbackUI}
        // We pass currentUserId to resetKeys.
        // If the user tries to view a DIFFERENT profile, the boundary will also reset.
        resetKeys={[currentUserId]}
      >
        <UserProfileCard userId={currentUserId} />
      </ErrorBoundary>
      <button onClick={() => setCurrentUserId('user-2')}>View Next User</button>
    </div>
  );
}

            

              
                Copy
              
            
          

பயனர் ஓட்டம்

1. `UserProfileCard` ஏற்றப்பட்டு, `user-1` க்கான தரவைப் பெறுகிறது.
2. நமது உருவகப்படுத்தப்பட்ட API தோராயமாக `profile` ஆப்ஜெக்ட் இல்லாமல் தரவைத் திருப்புகிறது.
3. ரெண்டரிங்கின் போது, `user.profile.avatarUrl` ஒரு `TypeError` ஐ எறிகிறது.
4. `ErrorBoundary` இந்த பிழையைப் பிடிக்கிறது. ஒரு வெள்ளைத் திரைக்கு பதிலாக, `ErrorFallbackUI` ரெண்டர் செய்யப்படுகிறது.
5. பயனர் "பயனர் சுயவிவரத்தை ஏற்ற முடியவில்லை." செய்தியையும் "மீண்டும் முயற்சிக்கவும்" பொத்தானையும் காண்கிறார்.
6. பயனர் "மீண்டும் முயற்சிக்கவும்" என்பதைக் கிளிக் செய்கிறார்.
7. `resetErrorBoundary` அழைக்கப்படுகிறது. நூலகம் உள்நாட்டில் அதன் நிலையை மீட்டமைக்கிறது. ஒரு கீ மறைமுகமாக நிர்வகிக்கப்படுவதால், `UserProfileCard` அவிழ்க்கப்பட்டு மீண்டும் ஏற்றப்படுகிறது.
8. புதிய `UserProfileCard` நிகழ்வில் உள்ள `useEffect` மீண்டும் இயங்குகிறது, தரவை மீண்டும் பெறுகிறது.
9. இந்த முறை, API சரியான தரவு வடிவத்தைத் திருப்புகிறது.
10. காம்பொனென்ட் வெற்றிகரமாக ரெண்டர் ஆகிறது, மேலும் பயனர் சுயவிவர அட்டையைக் காண்கிறார். UI ஒரே கிளிக்கில் தன்னைத்தானே குணப்படுத்திக் கொண்டது.

முடிவுரை: செயலிழப்பதைத் தாண்டி - UI மேம்பாட்டிற்கான ஒரு புதிய மனநிலை

எர்ரர் பவுண்டரிகள் மற்றும் `key` prop மூலம் இயக்கப்படும் தானியங்கி காம்பொனென்ட் மறுதொடக்க உத்தி, நாம் ஃபிரன்ட்எண்ட் மேம்பாட்டை அணுகும் முறையை அடிப்படையில் மாற்றுகிறது. இது ஒவ்வொரு சாத்தியமான பிழையையும் தடுக்க முயற்சிக்கும் ஒரு தற்காப்பு நிலையில் இருந்து, தோல்வியை எதிர்பார்த்து அதிலிருந்து நேர்த்தியாக மீளும் அமைப்புகளை உருவாக்கும் ஒரு தாக்குதல் நிலைக்கு நம்மை நகர்த்துகிறது.

இந்தப் பேட்டர்னைச் செயல்படுத்துவதன் மூலம், நீங்கள் குறிப்பிடத்தக்க சிறந்த பயனர் அனுபவத்தை வழங்குகிறீர்கள். நீங்கள் தோல்விகளைக் கட்டுப்படுத்துகிறீர்கள், விரக்தியைத் தடுக்கிறீர்கள், மேலும் முழுப் பக்க மறுஏற்றத்தின் மழுங்கிய கருவியை நாடாமல் பயனர்களுக்கு முன்னோக்கிச் செல்ல ஒரு பாதையை வழங்குகிறீர்கள். ஒரு உலகளாவிய செயலிக்கு, இந்த மீள்திறன் ஒரு ஆடம்பரம் அல்ல; இது உங்கள் மென்பொருள் சந்திக்கும் பல்வேறு சூழல்கள், நெட்வொர்க் நிலைமைகள், மற்றும் தரவு மாறுபாடுகளைக் கையாள வேண்டிய ஒரு தேவையாகும்.

முக்கியமான படிப்பினைகள் எளிமையானவை:

• சுற்றவும்: பிழைகளைக் கட்டுப்படுத்தவும் உங்கள் முழுச் செயலியும் செயலிழப்பதைத் தடுக்கவும் எர்ரர் பவுண்டரிகளைப் பயன்படுத்தவும்.
• கீ செய்யவும்: ஒரு தோல்விக்குப் பிறகு ஒரு காம்பொனென்டின் நிலையை முழுமையாக மீட்டமைக்கவும் மறுதொடக்கம் செய்யவும் `key` prop-ஐப் பயன்படுத்தவும்.
• கண்காணிக்கவும்: நீங்கள் மூல காரணத்தைக் கண்டறிந்து சரிசெய்ய முடியும் என்பதை உறுதிப்படுத்த, பிடிக்கப்பட்ட பிழைகளை எப்போதும் ஒரு கண்காணிப்புச் சேவைக்கு பதிவு செய்யவும்.

மீள்திறன் கொண்ட செயலிகளை உருவாக்குவது முதிர்ந்த பொறியியலின் ஒரு அடையாளம். இது பயனருக்கான ஆழ்ந்த பச்சாதாபத்தையும், இணைய மேம்பாட்டின் சிக்கலான உலகில், தோல்வி ஒரு சாத்தியக்கூறு மட்டுமல்ல—அது ஒரு தவிர்க்க முடியாதது என்பதையும் காட்டுகிறது. அதற்காகத் திட்டமிடுவதன் மூலம், நீங்கள் செயல்பாட்டுக்குரியவை மட்டுமல்ல, உண்மையான வலுவான மற்றும் நம்பகமான செயலிகளையும் உருவாக்க முடியும்.