ரியாக்ட்-இன் experimental_postpone: நிபந்தனைக்குட்பட்ட செயல்பாட்டை தள்ளிவைப்பதில் ஒரு ஆழமான பார்வை

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

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

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

சவால்: ஒரு கன்கரன்ட் உலகில் அனைத்தையும் அல்லது ஒன்றுமில்லாத ரெண்டரிங்

postpone ஐ முழுமையாகப் பாராட்ட, நாம் முதலில் ரியாக்ட் சர்வர் காம்போனென்ட்களின் சூழலைப் புரிந்து கொள்ள வேண்டும். RSCs தரவுகளைப் பெற்று, சர்வரில் காம்போனென்ட்களை ரெண்டர் செய்ய அனுமதிக்கின்றன, முழுமையாக உருவாக்கப்பட்ட HTML-ஐ கிளையண்டிற்கு அனுப்புகின்றன. இது ஆரம்ப பக்க ஏற்றுதல் நேரங்களை கணிசமாக மேம்படுத்துகிறது மற்றும் உலாவியில் அனுப்பப்படும் ஜாவாஸ்கிரிப்ட் அளவைக் குறைக்கிறது.

RSCs-உடன் ஒரு பொதுவான முறை ஒரு காம்போனென்ட்டிற்குள் நேரடியாக தரவு மீட்டெடுப்பிற்கு async/await ஐப் பயன்படுத்துவதாகும். ஒரு பயனர் சுயவிவரப் பக்கத்தைக் கவனியுங்கள்:

            async function ProfilePage({ userId }) {
  const user = await db.users.fetch(userId);
  const posts = await db.posts.fetchByUser(userId);
  const recentActivity = await api.activity.fetch(userId); // This one can be slow

  return (
    <div>
      <UserInfo user={user} />
      <UserPosts posts={posts} />
      <RecentActivity data={recentActivity} />
    </div>
  );
}
            

              
                Copy
              
            
          

இந்த சூழ்நிலையில், ரியாக்ட் ProfilePage-ஐ ரெண்டர் செய்து கிளையண்டிற்கு ஒரு பதிலை அனுப்புவதற்கு முன்பு அனைத்து மூன்று தரவு மீட்டெடுப்புகளும் முடிவடையும் வரை காத்திருக்க வேண்டும். api.activity.fetch() மெதுவாக இருந்தால், முழு பக்கமும் தடுக்கப்படுகிறது. மெதுவான கோரிக்கை முடியும் வரை பயனர் வெற்றுத் திரையைத் தவிர வேறு எதையும் பார்க்க மாட்டார். இது பெரும்பாலும் "அனைத்தையும் அல்லது ஒன்றுமில்லாத" ரெண்டர் அல்லது தரவு-மீட்டெடுப்பு நீர்வீழ்ச்சி என்று குறிப்பிடப்படுகிறது.

இதற்கான நிறுவப்பட்ட தீர்வு ரியாக்ட் <Suspense> ஆகும். மெதுவான காம்போனென்ட்களை ஒரு <Suspense> எல்லையில் வைப்பதன் மூலம், ஆரம்ப UI-ஐ பயனருக்கு உடனடியாக ஸ்ட்ரீம் செய்யலாம் மற்றும் இன்னும் ஏற்றப்படும் பகுதிகளுக்கு ஒரு ஃபால்பேக்கைக் (ஒரு லோடிங் ஸ்பின்னர் போன்றவை) காட்டலாம்.

            async function ProfilePage({ userId }) {
  const user = await db.users.fetch(userId);
  const posts = await db.posts.fetchByUser(userId);

  return (
    <div>
      <UserInfo user={user} />
      <UserPosts posts={posts} />
      <Suspense fallback={<ActivitySkeleton />}>
        <RecentActivityLoader userId={userId} />
      </Suspense>
    </div>
  );
}

// RecentActivityLoader.js
async function RecentActivityLoader({ userId }) {
  const recentActivity = await api.activity.fetch(userId);
  return <RecentActivity data={recentActivity} />;
}
            

              
                Copy
              
            
          

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

இதுவே experimental_postpone தீர்க்க வடிவமைக்கப்பட்ட சரியான இக்கட்டான நிலை. இது எல்லாவற்றிற்கும் காத்திருப்பதற்கும் உடனடியாக ஒரு ஃபால்பேக்கைக் காட்டுவதற்கும் இடையில் ஒரு நடுநிலையை வழங்குகிறது.

`experimental_postpone`-ஐ உள்ளிடவும்: அருமையான இடைநிறுத்தம்

postpone API, 'react'-இலிருந்து experimental_postpone ஐ இறக்குமதி செய்வதன் மூலம் கிடைக்கிறது, இது அழைக்கப்படும்போது, ரியாக்ட் ரெண்டரருக்கு ஒரு சிறப்பு சிக்னலை வீசும் ஒரு செயல்பாடு ஆகும். இந்த சிக்னல் ஒரு உத்தரவு: "இந்த சர்வர் ரெண்டரை முழுமையாக இடைநிறுத்து. இன்னும் ஒரு ஃபால்பேக்கிற்கு உறுதியளிக்க வேண்டாம். தேவையான தரவு விரைவில் வரும் என்று நான் எதிர்பார்க்கிறேன். எனக்கு இன்னும் கொஞ்சம் நேரம் கொடு."

ஒரு ப்ராமிஸை வீசுவதைப் போலல்லாமல், இது ரியாக்ட்டிடம் அருகிலுள்ள <Suspense> எல்லையைக் கண்டுபிடித்து அதன் ஃபால்பேக்கை ரெண்டர் செய்யச் சொல்கிறது, postpone ரெண்டரை ஒரு உயர் மட்டத்தில் நிறுத்துகிறது. சர்வர் வெறுமனே இணைப்பைத் திறந்து வைத்திருக்கிறது, தரவு கிடைக்கும் வரை ரெண்டரைத் தொடரக் காத்திருக்கிறது.

postpone ஐப் பயன்படுத்தி நமது மெதுவான காம்போனென்ட்டை மீண்டும் எழுதுவோம்:

            import { experimental_postpone as postpone } from 'react';

function RecentActivity({ userId }) {
  // Using a data cache that supports this pattern
  const recentActivity = api.activity.read(userId);

  if (!recentActivity) {
    // Data is not ready yet. Instead of showing a spinner,
    // we postpone the entire render.
    postpone('Recent activity data is not yet available.');
  }

  return <RenderActivity data={recentActivity} />;
}

            

              
                Copy
              
            
          

முக்கிய கருத்துக்கள்:

• இது ஒரு Throw: சஸ்பென்ஸ் போலவே, இது ரெண்டரிங் ஓட்டத்தை குறுக்கிட `throw` பொறிமுறையைப் பயன்படுத்துகிறது. இது ரியாக்டில் உள்ளூர் அல்லாத நிலை மாற்றங்களைக் கையாள ஒரு சக்திவாய்ந்த முறை.
• சர்வர்-மட்டும்: இந்த API பிரத்தியேகமாக ரியாக்ட் சர்வர் காம்போனென்ட்களுக்குள் பயன்படுத்த வடிவமைக்கப்பட்டுள்ளது. கிளையன்ட்-பக்க குறியீட்டில் இதற்கு எந்த விளைவும் இல்லை.
• காரண சரம்: `postpone` க்கு அனுப்பப்பட்ட சரம் (எ.கா., 'Recent activity data...') பிழைத்திருத்த நோக்கங்களுக்காகவாகும். பதிவுகளை ஆய்வு செய்யும்போது அல்லது டெவலப்பர் கருவிகளைப் பயன்படுத்தும்போது ஒரு ரெண்டர் ஏன் ஒத்திவைக்கப்பட்டது என்பதைக் கண்டறிய இது உங்களுக்கு உதவும்.

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

இது எப்படி வேலை செய்கிறது: `postpone` மற்றும் ரியாக்ட் ஷெட்யூலர்

postpone-இன் பின்னணியில் உள்ள மாயம், ரியாக்டின் கன்கரன்ட் ஷெட்யூலருடனான அதன் தொடர்பு மற்றும் ஸ்ட்ரீமிங் பதில்களை ஆதரிக்கும் நவீன ஹோஸ்டிங் உள்கட்டமைப்புடன் அதன் ஒருங்கிணைப்பில் உள்ளது.

1. ரெண்டர் தொடங்கப்பட்டது: ஒரு பயனர் ஒரு பக்கத்தைக் கோருகிறார். ரியாக்ட் சர்வர் ரெண்டரர் அதன் வேலையைத் தொடங்குகிறது, காம்போனென்ட்களை மேலிருந்து கீழாக ரெண்டர் செய்கிறது.
2. `postpone` அழைக்கப்படுகிறது: ரெண்டரர் `postpone` ஐ அழைக்கும் ஒரு காம்போனென்ட்டை எதிர்கொள்கிறது.
3. ரெண்டர் இடைநிறுத்தப்பட்டது: ரெண்டரர் இந்த சிறப்பு `postpone` சிக்னலைப் பிடிக்கிறது. ஒரு <Suspense> எல்லையைத் தேடுவதற்குப் பதிலாக, அது அந்தக் கோரிக்கைக்கான முழு ரெண்டரிங் பணியையும் நிறுத்துகிறது. இது ஷெட்யூலரிடம், "இந்த பணி முடிக்கத் தயாராக இல்லை" என்று திறம்படச் சொல்கிறது.
4. இணைப்பு திறந்திருக்கிறது: சர்வர் ஒரு முழுமையற்ற HTML ஆவணத்தையோ அல்லது ஒரு ஃபால்பேக்கையோ திருப்பி அனுப்பாது. அது HTTP கோரிக்கையைத் திறந்து வைத்திருக்கிறது, காத்திருக்கிறது.
5. தரவு வருகிறது: (`postpone`-ஐத் தூண்டிய) அடிப்படை தரவு-மீட்டெடுப்பு பொறிமுறை இறுதியில் தேவையான தரவுகளுடன் தீர்க்கிறது.
6. ரெண்டர் மீண்டும் தொடங்கப்பட்டது: தரவு கேஷ் இப்போது நிரப்பப்பட்டுள்ளது. பணி மீண்டும் முயற்சிக்கப்படலாம் என்று ரியாக்ட் ஷெட்யூலருக்கு அறிவிக்கப்படுகிறது. அது மேலிருந்து ரெண்டரை மீண்டும் இயக்குகிறது.
7. வெற்றிகரமான ரெண்டர்: இந்த முறை, ரெண்டரர் RecentActivity காம்போனென்ட்டை அடையும்போது, தரவு கேஷில் கிடைக்கிறது. `postpone` அழைப்பு தவிர்க்கப்படுகிறது, காம்போனென்ட் வெற்றிகரமாக ரெண்டர் செய்யப்படுகிறது, மற்றும் முழுமையான HTML பதில் கிளையண்டிற்கு ஸ்ட்ரீம் செய்யப்படுகிறது.

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

சரியான கூட்டாண்மை: `postpone` உடன் ஒரு `Suspense` காலக்கெடு

ஒத்திவைக்கப்பட்ட தரவு வருவதற்கு அதிக நேரம் எடுத்தால் என்ன செய்வது? பயனர் காலவரையின்றி வெற்றுத் திரையைப் பார்ப்பதை நாங்கள் விரும்பவில்லை. இங்குதான் `postpone` மற்றும் `Suspense` அழகாக ஒன்றாக வேலை செய்கின்றன.

`postpone` ஐப் பயன்படுத்தும் ஒரு காம்போனென்ட்டை நீங்கள் ஒரு <Suspense> எல்லையில் வைக்கலாம். இது ஒரு இரு-அடுக்கு மீட்பு உத்தியை உருவாக்குகிறது:

• அடுக்கு 1 (நம்பிக்கையான பாதை): காம்போனென்ட் `postpone`-ஐ அழைக்கிறது. ரியாக்ட் ஒரு குறுகிய, கட்டமைப்பு-வரையறுக்கப்பட்ட காலத்திற்கு ரெண்டரை இடைநிறுத்துகிறது, தரவு வரும் என்று நம்புகிறது.
• அடுக்கு 2 (நடைமுறைப் பாதை): அந்த காலக்கெடுவுக்குள் தரவு வரவில்லை என்றால், ரியாக்ட் ஒத்திவைக்கப்பட்ட ரெண்டரைக் கைவிடுகிறது. பின்னர் அது நிலையான Suspense பொறிமுறைக்குத் திரும்புகிறது, fallback UI-ஐ ரெண்டர் செய்து ஆரம்ப ஷெல்லை கிளையண்டிற்கு அனுப்புகிறது. ஒத்திவைக்கப்பட்ட காம்போனென்ட் பின்னர் ஒரு வழக்கமான சஸ்பென்ஸ்-இயக்கப்பட்ட காம்போனென்ட்டைப் போலவே ஏற்றப்படும்.

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

            // In ProfilePage.js
<Suspense fallback={<ActivitySkeleton />}>
  <RecentActivity userId={userId} /> <!-- This component uses postpone internally -->
</Suspense>
            

              
                Copy
              
            
          

முக்கிய வேறுபாடுகள்: `postpone` எதிராக ஒரு ப்ராமிஸை வீசுதல் (`Suspense`)

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

மேம்பட்ட பயன்பாட்டு வழக்குகள் மற்றும் உலகளாவிய பரிசீலனைகள்

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

1. டைனமிக் தனிப்பயனாக்கம் மற்றும் A/B சோதனை

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

• postpone இல்லாமல்: நீங்கள் இந்தத் தரவுக்காக முழு பக்கத்தையும் தடுக்க வேண்டும் (மோசமானது) அல்லது ஒரு பொதுவான பேனரைக் காட்டி, அது பின்னர் மின்னிமினுக்கி தனிப்பயனாக்கப்பட்ட ஒன்றுக்கு மாறும் (இதுவும் மோசமானது, தளவமைப்பு மாற்றத்தை ஏற்படுத்துகிறது).
• postpone உடன்: நீங்கள் ஒரு <PersonalizedBanner /> காம்போனென்ட்டை உருவாக்கலாம், அது தனிப்பயனாக்கத் தரவைப் பெறுகிறது. தரவு உடனடியாகக் கிடைக்கவில்லை என்றால், அது postpone-ஐ அழைக்கிறது. 99% பயனர்களுக்கு, இந்தத் தரவு மில்லி விநாடிகளில் கிடைக்கும், மற்றும் பக்கம் சரியான பேனருடன் தடையின்றி ஏற்றப்படும். தனிப்பயனாக்க இயந்திரம் மெதுவாக இருக்கும் சிறிய பகுதிக்கு, ரெண்டர் சுருக்கமாக இடைநிறுத்தப்படுகிறது, இது இன்னும் ஒரு சரியான, மின்னிமினுப்பற்ற ஆரம்ப பார்வையை விளைவிக்கிறது.

2. ஷெல் ரெண்டரிங்கிற்கான முக்கியமான பயனர் தரவு

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

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

            import { experimental_postpone as postpone } from 'react';
import { readUserSession } from './auth';

export default function RootLayout({ children }) {
  const session = readUserSession(); // Attempt to read from a cache

  if (!session) {
    postpone('User session not yet available.');
  }

  return (
    <html>
      <body>
        {session.user.isAdmin ? <AdminNavbar /> : <UserNavbar />}
        {children}
      </body>
    </html>
  );
}
            

              
                Copy
              
            
          

3. நம்பகத்தன்மையற்ற API-களை அருமையாக கையாளுதல்

பல பயன்பாடுகள் மைக்ரோ சர்வீஸ்கள் மற்றும் மூன்றாம் தரப்பு API-களின் ஒரு வலையமைப்பை நம்பியுள்ளன. இவற்றில் சில மாறுபட்ட செயல்திறனைக் கொண்டிருக்கலாம். ஒரு செய்தி முகப்புப் பக்கத்தில் உள்ள வானிலை விட்ஜெட்டிற்கு, வானிலை API பொதுவாக வேகமாக இருக்கும். ஒவ்வொரு முறையும் ஒரு லோடிங் ஸ்கெலிட்டனுடன் பயனர்களைத் தண்டிக்க நீங்கள் விரும்ப மாட்டீர்கள். வானிலை விட்ஜெட்டிற்குள் postpone ஐப் பயன்படுத்துவதன் மூலம், நீங்கள் மகிழ்ச்சியான பாதையில் பந்தயம் கட்டுகிறீர்கள். API மெதுவாக இருந்தால், அதைச் சுற்றியுள்ள ஒரு <Suspense> எல்லை இறுதியில் ஒரு ஃபால்பேக்கைக் காட்டலாம், ஆனால் உலகெங்கிலும் உள்ள உங்கள் பெரும்பான்மையான பயனர்களுக்கு லோடிங் உள்ளடக்கத்தின் மின்னிமினுப்பை நீங்கள் தவிர்த்துவிட்டீர்கள்.

எச்சரிக்கைகள்: ஒரு எச்சரிக்கை வார்த்தை

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

• இது ஒரு நிலையற்ற API: experimental_postpone என்ற பெயர் ரியாக்ட் குழுவிலிருந்து ஒரு தெளிவான சமிக்ஞையாகும். API மாறலாம், மறுபெயரிடப்படலாம், அல்லது ரியாக்டின் எதிர்கால பதிப்புகளில் அகற்றப்படலாம். சாத்தியமான மாற்றங்களுக்கு ஏற்ப ஒரு தெளிவான திட்டம் இல்லாமல் அதைச் சுற்றி முக்கிய உற்பத்தி அமைப்புகளை உருவாக்க வேண்டாம்.
• TTFB-இல் தாக்கம்: அதன் இயல்பாலேயே, postpone வேண்டுமென்றே முதல் பைட்டிற்கான நேரத்தை (Time to First Byte) அதிகரிக்கிறது. இது ஒரு சமரசம். நீங்கள் ஒரு வேகமான TTFB-ஐ (லோடிங் நிலைகளுடன்) ஒரு சாத்தியமான மெதுவான, ஆனால் முழுமையான, ஆரம்ப ரெண்டருக்காக வர்த்தகம் செய்கிறீர்கள். இந்த சமரசம் ஒவ்வொரு வழக்கிற்கும் தனித்தனியாக மதிப்பீடு செய்யப்பட வேண்டும். SEO-முக்கியமான லேண்டிங் பக்கங்களுக்கு, ஒரு வேகமான TTFB முக்கியமானது, எனவே கிட்டத்தட்ட உடனடி தரவு மீட்டெடுப்பைத் தவிர வேறு எதற்கும் postpone ஐப் பயன்படுத்துவது தீங்கு விளைவிக்கும்.
• உள்கட்டமைப்பு ஆதரவு: இந்த முறை ஸ்ட்ரீமிங் சர்வர் பதில்களை ஆதரிக்கும் மற்றும் ஒத்திவைக்கப்பட்ட ரெண்டர் மீண்டும் தொடங்கும் வரை இணைப்புகளைத் திறந்து வைத்திருக்கக்கூடிய ஹோஸ்டிங் தளங்கள் மற்றும் கட்டமைப்புகளை (Next.js உடன் Vercel போன்றவை) நம்பியுள்ளது.
• அதிகப்படியான பயன்பாடு தீங்கு விளைவிக்கும்: ஒரு பக்கத்தில் பல வேறுபட்ட தரவு மூலங்களுக்கு நீங்கள் ஒத்திவைத்தால், நீங்கள் தீர்க்க முயன்ற அதே நீர்வீழ்ச்சி சிக்கலை மீண்டும் உருவாக்கக்கூடும், ஒரு பகுதி UI-க்கு பதிலாக நீண்ட வெற்றுத் திரையுடன். குறிப்பிட்ட, நன்கு புரிந்துகொள்ளப்பட்ட சூழ்நிலைகளுக்கு இதை அறுவை சிகிச்சை போலப் பயன்படுத்துங்கள்.

முடிவுரை: சிறுமணி ரெண்டர் கட்டுப்பாட்டின் ஒரு புதிய சகாப்தம்

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

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

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

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

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