ரியாக்ட்டின் `use` ஹூக்கைப் புரிந்துகொள்ளுதல்: Promises, Context, மற்றும் வள மேலாண்மை குறித்த ஒரு ஆழமான பார்வை

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

பல ஆண்டுகளாக, டெவலப்பர்கள் ஒத்திசைவற்ற செயல்பாடுகள் மற்றும் நிலை மேலாண்மையின் சிக்கல்களுடன் போராடி வருகின்றனர். தரவைப் பெறுவது என்பது பெரும்பாலும் `useEffect`, `useState`, மற்றும் loading/error நிலைகளின் சிக்கலான வலையமைப்பைக் குறிக்கிறது. Context-ஐப் பயன்படுத்துவது சக்தி வாய்ந்ததாக இருந்தாலும், ஒவ்வொரு நுகர்வோரிலும் மறு-ரெண்டர்களைத் தூண்டும் குறிப்பிடத்தக்க செயல்திறன் குறைபாட்டுடன் வந்தது. இந்த நீண்டகால சவால்களுக்கு ரியாக்ட்டின் நேர்த்தியான பதில் தான் `use` ஹூக்.

இந்த விரிவான வழிகாட்டி தொழில்முறை ரியாக்ட் டெவலப்பர்களின் உலகளாவிய பார்வையாளர்களுக்காக வடிவமைக்கப்பட்டுள்ளது. நாம் `use` ஹூக்கிற்குள் ஆழமாகப் பயணித்து, அதன் இயக்கவியலைப் பிரித்து, அதன் இரண்டு முதன்மை ஆரம்ப பயன்பாட்டு நிகழ்வுகளை ஆராய்வோம்: Promises-ஐ வெளிக்கொணர்தல் மற்றும் Context-இலிருந்து படித்தல். மிக முக்கியமாக, வளப் பயன்பாடு, செயல்திறன் மற்றும் பயன்பாட்டுக் கட்டமைப்பிற்கான ஆழ்ந்த தாக்கங்களை நாம் பகுப்பாய்வு செய்வோம். உங்கள் ரியாக்ட் பயன்பாடுகளில் நீங்கள் ασύγχρονο தர்க்கம் மற்றும் நிலையை எவ்வாறு கையாளுகிறீர்கள் என்பதை மறுபரிசீலனை செய்யத் தயாராகுங்கள்.

ஒரு அடிப்படை மாற்றம்: `use` ஹூக்கை வேறுபடுத்துவது எது?

Promises மற்றும் Context-க்குள் மூழ்குவதற்கு முன், `use` ஏன் இவ்வளவு புரட்சிகரமானது என்பதைப் புரிந்துகொள்வது அவசியம். பல ஆண்டுகளாக, ரியாக்ட் டெவலப்பர்கள் கடுமையான ஹூக்ஸ் விதிகளின் (Rules of Hooks) கீழ் செயல்பட்டு வருகின்றனர்:

உங்கள் காம்போனென்ட்டின் மேல் மட்டத்தில் மட்டுமே ஹூக்ஸை அழைக்கவும்.
Loops, conditions, அல்லது nested functions உள்ளே ஹூக்ஸை அழைக்க வேண்டாம்.

இந்த விதிகள் உள்ளன, ஏனெனில் `useState` மற்றும் `useEffect` போன்ற பாரம்பரிய ஹூக்ஸ் ஒவ்வொரு ரெண்டரின் போதும் தங்கள் நிலையை பராமரிக்க ஒரு நிலையான அழைப்பு வரிசையை நம்பியுள்ளன. `use` ஹூக் இந்த முன்னுதாரணத்தை உடைக்கிறது. நீங்கள் `use`-ஐ conditions (`if`/`else`), loops (`for`/`map`), மற்றும் முன்கூட்டிய `return` கூற்றுகளுக்குள்ளும் அழைக்கலாம்.

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

முக்கிய கருத்து: மதிப்புகளை வெளிக்கொணர்தல்

அதன் மையத்தில், `use` ஹூக் ஒரு வளத்திலிருந்து ஒரு மதிப்பை "வெளிக்கொணர" வடிவமைக்கப்பட்டுள்ளது. இதை இப்படி நினைத்துப் பாருங்கள்:

நீங்கள் அதற்கு ஒரு Promise-ஐ அனுப்பினால், அது தீர்க்கப்பட்ட மதிப்பை வெளிக்கொணர்கிறது. Promise நிலுவையில் இருந்தால், ரெண்டரிங்கை இடைநிறுத்துமாறு ரியாக்டிற்கு சமிக்ஞை செய்கிறது. அது நிராகரிக்கப்பட்டால், ஒரு Error Boundary மூலம் பிடிக்கப்பட வேண்டிய பிழையை அது வீசுகிறது.
நீங்கள் அதற்கு React Context-ஐ அனுப்பினால், அது தற்போதைய context மதிப்பை வெளிக்கொணர்கிறது, `useContext` போலவே. இருப்பினும், அதன் நிபந்தனைக்குட்பட்ட தன்மை, காம்போனென்ட்கள் context புதுப்பிப்புகளுக்கு எவ்வாறு சந்தா செலுத்துகின்றன என்பதைப் பற்றிய அனைத்தையும் மாற்றுகிறது.

இந்த இரண்டு சக்திவாய்ந்த திறன்களை விரிவாக ஆராய்வோம்.

ஒத்திசைவற்ற செயல்பாடுகளில் தேர்ச்சி: `use` உடன் Promises

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

பழைய வழி: `useEffect` மற்றும் `useState` இன் சிக்கல்

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


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

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;
    const fetchUser = async () => {
      try {
        setIsLoading(true);
        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();
        if (isMounted) {
          setUser(data);
        }
      } catch (err) {
        if (isMounted) {
          setError(err);
        }
      } finally {
        if (isMounted) {
          setIsLoading(false);
        }
      }
    };

    fetchUser();

    return () => {
      isMounted = false;
    };
  }, [userId]);

  if (isLoading) {
    return <p>Loading profile...</p>;
  }

  if (error) {
    return <p>Error: {error.message}</p>;
  }

  return (
    <div>
      <h1>{user.name}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
}

இந்தக் குறியீடு மிகவும் பாய்லர்பிளேட்-கனமானது. நாம் மூன்று தனித்தனி நிலைகளை (`user`, `isLoading`, `error`) கைமுறையாக நிர்வகிக்க வேண்டும், மேலும் ஒரு மவுண்டட் கொடியைப் பயன்படுத்தி ரேஸ் நிலைமைகள் மற்றும் சுத்தப்படுத்துதல் பற்றி கவனமாக இருக்க வேண்டும். தனிப்பயன் ஹூக்குகள் இதை சுருக்கினாலும், அடிப்படை சிக்கல் அப்படியே உள்ளது.

புதிய வழி: `use` உடன் நேர்த்தியான ஒத்திசைவு

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

அதே காம்போனென்ட் `use` உடன் எவ்வாறு எழுதப்படலாம் என்பது இங்கே:


// You must wrap this component in <Suspense> and an <ErrorBoundary>
import { use } from 'react';
import { fetchUser } from './api'; // Assume this returns a cached promise

function UserProfile({ userId }) {
  // `use` will suspend the component until the promise resolves
  const user = use(fetchUser(userId));

  // When execution reaches here, the promise is resolved and `user` has data.
  // No need for isLoading or error states in the component itself.
  return (
    <div>
      <h1>{user.name}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
}

வித்தியாசம் திகைப்பூட்டுகிறது. loading மற்றும் error நிலைகள் நமது காம்போனென்ட் தர்க்கத்திலிருந்து மறைந்துவிட்டன. திரைக்குப் பின்னால் என்ன நடக்கிறது?

`UserProfile` முதல் முறையாக ரெண்டர் ஆகும்போது, அது `use(fetchUser(userId))` ஐ அழைக்கிறது.
`fetchUser` செயல்பாடு ஒரு நெட்வொர்க் கோரிக்கையைத் தொடங்கி ஒரு Promise-ஐத் திருப்புகிறது.
`use` ஹூக் இந்த நிலுவையில் உள்ள Promise-ஐப் பெற்று, இந்த காம்போனென்ட்டின் ரெண்டரிங்கை இடைநிறுத்த ரியாக்ட்டின் ரெண்டரருடன் தொடர்பு கொள்கிறது.
ரியாக்ட், காம்போனென்ட் மரத்தில் மேலே சென்று அருகிலுள்ள `` எல்லையைக் கண்டறிந்து, அதன் `fallback` UI-ஐ (எ.கா., ஒரு ஸ்பின்னர்) காட்டுகிறது.
Promise தீர்க்கப்பட்டதும், ரியாக்ட் `UserProfile`-ஐ மீண்டும் ரெண்டர் செய்கிறது. இந்த முறை, அதே Promise உடன் `use` அழைக்கப்படும்போது, Promise-க்கு தீர்க்கப்பட்ட மதிப்பு இருக்கும். `use` இந்த மதிப்பைத் திருப்புகிறது.
காம்போனென்ட் ரெண்டரிங் தொடர்கிறது, மற்றும் பயனரின் சுயவிவரம் காட்டப்படுகிறது.
Promise நிராகரிக்கப்பட்டால், `use` பிழையை வீசுகிறது. ரியாக்ட் இதைப் பிடித்து, மரத்தில் மேலே சென்று அருகிலுள்ள ``-க்குச் சென்று ஒரு ஃபால்பேக் பிழை UI-ஐக் காட்டுகிறது.

வளப் பயன்பாடு குறித்த ஆழமான பார்வை: கேச்சிங் (Caching) கட்டாயம்

`use(fetchUser(userId))` இன் எளிமை ஒரு முக்கியமான விவரத்தை மறைக்கிறது: நீங்கள் ஒவ்வொரு ரெண்டரிலும் ஒரு புதிய Promise-ஐ உருவாக்கக்கூடாது. நமது `fetchUser` செயல்பாடு வெறுமனே `() => fetch(...)` ஆக இருந்து, அதை காம்போனென்ட்டிற்குள் நேரடியாக அழைத்தால், ஒவ்வொரு ரெண்டர் முயற்சியிலும் ஒரு புதிய நெட்வொர்க் கோரிக்கையை உருவாக்குவோம், இது ஒரு முடிவற்ற வளையத்திற்கு வழிவகுக்கும். காம்போனென்ட் இடைநிறுத்தப்படும், ப்ராமிஸ் தீர்க்கப்படும், ரியாக்ட் மீண்டும் ரெண்டர் செய்யும், ஒரு புதிய ப்ராமிஸ் உருவாக்கப்படும், அது மீண்டும் இடைநிறுத்தப்படும்.

ப்ராமிஸ்களுடன் `use` ஐப் பயன்படுத்தும்போது புரிந்துகொள்ள வேண்டிய மிக முக்கியமான வள மேலாண்மைக் கருத்து இதுவாகும். Promise நிலையானதாகவும், மறு-ரெண்டர்கள் முழுவதும் கேச் செய்யப்பட்டதாகவும் இருக்க வேண்டும்.

ரியாக்ட் இதற்கு உதவ ஒரு புதிய `cache` செயல்பாட்டை வழங்குகிறது. ஒரு வலுவான தரவுப் பெறும் பயன்பாட்டை உருவாக்குவோம்:


// api.js
import { cache } from 'react';

export const fetchUser = cache(async (userId) => {
  console.log(`Fetching data for user: ${userId}`);
  const response = await fetch(`https://api.example.com/users/${userId}`);
  if (!response.ok) {
    throw new Error('Failed to fetch user data.');
  }
  return response.json();
});

ரியாக்ட்டில் இருந்து `cache` செயல்பாடு ஒத்திசைவற்ற செயல்பாட்டை மெமோயிஸ் செய்கிறது. `fetchUser(1)` அழைக்கப்படும்போது, அது fetch-ஐத் தொடங்கி, விளைந்த Promise-ஐ சேமிக்கிறது. மற்றொரு காம்போனென்ட் (அல்லது அதே காம்போனென்ட் ஒரு அடுத்தடுத்த ரெண்டரில்) மீண்டும் `fetchUser(1)`-ஐ அதே ரெண்டர் பாஸில் அழைத்தால், `cache` அதே Promise ஆப்ஜெக்ட்டைத் திருப்பித் தரும், தேவையற்ற நெட்வொர்க் கோரிக்கைகளைத் தடுக்கும். இது தரவுப் பெறுதலை ஐடெம்பொடன்ட் மற்றும் `use` ஹூக்குடன் பயன்படுத்த பாதுகாப்பானதாக ஆக்குகிறது.

இது வள மேலாண்மையில் ஒரு அடிப்படை மாற்றமாகும். காம்போனென்ட்டிற்குள் fetch நிலையை நிர்வகிப்பதற்குப் பதிலாக, நாம் வளத்தை (தரவு ப்ராமிஸ்) அதற்கு வெளியே நிர்வகிக்கிறோம், மற்றும் காம்போனென்ட் அதை வெறுமனே பயன்படுத்துகிறது.

நிலை மேலாண்மையில் புரட்சி: `use` உடன் Context

ரியாக்ட் Context என்பது "prop drilling"-ஐத் தவிர்ப்பதற்கான ஒரு சக்திவாய்ந்த கருவியாகும்—பல அடுக்கு காம்போனென்ட்கள் வழியாக ப்ராப்ஸை அனுப்புவது. இருப்பினும், அதன் பாரம்பரிய செயலாக்கத்தில் ஒரு குறிப்பிடத்தக்க செயல்திறன் குறைபாடு உள்ளது.

`useContext` இன் புதிர்

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

பயனர் தகவல் மற்றும் தற்போதைய தீம் இரண்டையும் வைத்திருக்கும் ஒரு `SessionContext`-ஐக் கவனியுங்கள்:


// SessionContext.js
const SessionContext = createContext({
  user: null,
  theme: 'light',
  updateTheme: () => {},
});

// Component that only cares about the user
function WelcomeMessage() {
  const { user } = useContext(SessionContext);
  console.log('Rendering WelcomeMessage');
  return <p>Welcome, {user?.name}!</p>;
}

// Component that only cares about the theme
function ThemeToggleButton() {
  const { theme, updateTheme } = useContext(SessionContext);
  console.log('Rendering ThemeToggleButton');
  return <button onClick={updateTheme}>Switch to {theme === 'light' ? 'dark' : 'light'} theme</button>;
}

இந்த சூழ்நிலையில், பயனர் `ThemeToggleButton`-ஐ கிளிக் செய்து `updateTheme` அழைக்கப்படும்போது, முழு `SessionContext` மதிப்பு ஆப்ஜெக்ட்டும் மாற்றப்படுகிறது. இது `ThemeToggleButton` மற்றும் `WelcomeMessage` இரண்டையும் மீண்டும் ரெண்டர் செய்ய வைக்கிறது, `user` ஆப்ஜெக்ட் மாறாவிட்டாலும் கூட. நூற்றுக்கணக்கான context நுகர்வோருடன் ஒரு பெரிய பயன்பாட்டில், இது கடுமையான செயல்திறன் சிக்கல்களுக்கு வழிவகுக்கும்.

`use(Context)` அறிமுகம்: நிபந்தனைக்குட்பட்ட பயன்பாடு

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

இந்த சக்தியை வெளிப்படுத்த ஒரு காம்போனென்ட்டை மறுசீரமைப்போம்:


function UserSettings({ userId }) {
  const { user, theme } = useContext(SessionContext); // Traditional way: always subscribes

  // Let's imagine we only show theme settings for the currently logged-in user
  if (user?.id !== userId) {
    return <p>You can only view your own settings.</p>;
  }

  // This part only runs if the user ID matches
  return <div>Current theme: {theme}</div>;
}

`useContext` உடன், இந்த `UserSettings` காம்போனென்ட் தீம் மாறும் ஒவ்வொரு முறையும் மீண்டும் ரெண்டர் ஆகும், `user.id !== userId` ஆக இருந்தாலும் மற்றும் தீம் தகவல் ஒருபோதும் காட்டப்படாவிட்டாலும் கூட. சந்தா மேல் மட்டத்தில் நிபந்தனையின்றி நிறுவப்படுகிறது.

இப்போது, `use` பதிப்பைப் பார்ப்போம்:


import { use } from 'react';

function UserSettings({ userId }) {
  // Read the user first. Let's assume this part is cheap or necessary.
  const user = use(SessionContext).user;

  // If the condition is not met, we return early.
  // CRUCIALLY, we haven't read the theme yet.
  if (user?.id !== userId) {
    return <p>You can only view your own settings.</p>;
  }

  // ONLY if the condition is met, we read the theme from the context.
  // The subscription to context changes is established here, conditionally.
  const theme = use(SessionContext).theme;

  return <div>Current theme: {theme}</div>;
}

இது ஒரு கேம்-சேஞ்சர். இந்த பதிப்பில், `user.id` ஆனது `userId` உடன் பொருந்தவில்லை என்றால், காம்போனென்ட் முன்கூட்டியே திரும்பும். `const theme = use(SessionContext).theme;` என்ற வரி ஒருபோதும் செயல்படுத்தப்படாது. எனவே, இந்த காம்போனென்ட் நிகழ்வு `SessionContext`-க்கு சந்தா செலுத்தாது. பயன்பாட்டில் வேறு எங்கேனும் தீம் மாற்றப்பட்டால், இந்த காம்போனென்ட் தேவையற்ற முறையில் மீண்டும் ரெண்டர் ஆகாது. இது நிபந்தனையுடன் context-இலிருந்து படிப்பதன் மூலம் அதன் சொந்த வளப் பயன்பாட்டை திறம்பட மேம்படுத்தியுள்ளது.

வளப் பயன்பாட்டுப் பகுப்பாய்வு: சந்தா மாதிரிகள்

context நுகர்வுக்கான மன மாதிரி வியத்தகு முறையில் மாறுகிறது:

`useContext`: ஒரு ஆர்வமுள்ள, மேல்-நிலை சந்தா. காம்போனென்ட் அதன் சார்புநிலையை முன்கூட்டியே அறிவித்து, எந்தவொரு context மாற்றத்திலும் மீண்டும் ரெண்டர் ஆகிறது.
`use(Context)`: ஒரு சோம்பேறி, தேவைக்கேற்ப வாசிப்பு. காம்போனென்ட் அதிலிருந்து படிக்கும் தருணத்தில் மட்டுமே context-க்கு சந்தா செலுத்துகிறது. அந்த வாசிப்பு நிபந்தனைக்குட்பட்டதாக இருந்தால், சந்தாவும் நிபந்தனைக்குட்பட்டது.

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

சந்திப்பு புள்ளி: `use` உடன் Context-இல் Promises

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


// DataContext.js
import { createContext } from 'react';
import { fetchSomeGlobalData } from './api'; // Returns a cached promise

// The context provides a promise, not the data itself.
export const GlobalDataContext = createContext(fetchSomeGlobalData());

// App.js
function App() {
  return (
    <GlobalDataContext.Provider value={fetchSomeGlobalData()}>
      <Suspense fallback={<h1>Loading application...</h1>}>
        <Dashboard />
      </Suspense>
    </GlobalDataContext.Provider>
  );
}

// Dashboard.js
import { use } from 'react';
import { GlobalDataContext } from './DataContext';

function Dashboard() {
  // First `use` reads the promise from the context.
  const dataPromise = use(GlobalDataContext);

  // Second `use` unwraps the promise, suspending if necessary.
  const globalData = use(dataPromise);

  // A more concise way to write the above two lines:
  // const globalData = use(use(GlobalDataContext));

  return <h1>Welcome, {globalData.userName}!</h1>;
}

`const globalData = use(use(GlobalDataContext));` என்பதைப் பிரித்துப் பார்ப்போம்:

`use(GlobalDataContext)`: உள் அழைப்பு முதலில் செயல்படுத்தப்படுகிறது. இது `GlobalDataContext`-இலிருந்து மதிப்பை படிக்கிறது. நமது அமைப்பில், இந்த மதிப்பு `fetchSomeGlobalData()` மூலம் திருப்பப்படும் ஒரு promise ஆகும்.
`use(dataPromise)`: வெளி அழைப்பு பின்னர் இந்த promise-ஐப் பெறுகிறது. இது முதல் பகுதியில் நாம் பார்த்ததைப் போலவே செயல்படுகிறது: promise நிலுவையில் இருந்தால் `Dashboard` காம்போனென்ட்டை இடைநிறுத்துகிறது, நிராகரிக்கப்பட்டால் பிழையை வீசுகிறது, அல்லது தீர்க்கப்பட்ட தரவைத் திருப்புகிறது.

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

செயல்திறன், இடர்ப்பாடுகள், மற்றும் சிறந்த நடைமுறைகள்

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

செயல்திறன் சுருக்கம்

பலன்கள்: நிபந்தனைக்குட்பட்ட சந்தாக்கள் காரணமாக context புதுப்பிப்புகளிலிருந்து மறு-ரெண்டர்கள் வியத்தகு முறையில் குறைக்கப்படுகின்றன. காம்போனென்ட்-நிலை நிலை மேலாண்மையைக் குறைக்கும் சுத்தமான, மேலும் படிக்கக்கூடிய ασύγχρονο தர்க்கம்.
செலவுகள்: சஸ்பென்ஸ் மற்றும் எரர் பவுண்டரிகளைப் பற்றிய திடமான புரிதல் தேவைப்படுகிறது, இது உங்கள் பயன்பாட்டுக் கட்டமைப்பின் பேச்சுவார்த்தைக்குட்படாத பகுதிகளாக மாறும். உங்கள் பயன்பாட்டின் செயல்திறன் சரியான promise கேச்சிங் உத்தியைச் சார்ந்து இருக்கும்.

தவிர்க்க வேண்டிய பொதுவான தவறுகள்

கேச் செய்யப்படாத Promises: முதல் எண் தவறு. ஒரு காம்போனென்ட்டில் நேரடியாக `use(fetch(...))` ஐ அழைப்பது ஒரு முடிவற்ற வளையத்தை ஏற்படுத்தும். எப்போதும் ரியாக்ட்டின் `cache` அல்லது SWR/React Query போன்ற லைப்ரரிகளைப் போன்ற ஒரு கேச்சிங் பொறிமுறையைப் பயன்படுத்தவும்.
காணாமல் போன எல்லைகள்: ஒரு பெற்றோர் `` எல்லை இல்லாமல் `use(Promise)` ஐப் பயன்படுத்துவது உங்கள் பயன்பாட்டை செயலிழக்கச் செய்யும். இதேபோல், ஒரு பெற்றோர் `` இல்லாத நிராகரிக்கப்பட்ட promise-ம் பயன்பாட்டை செயலிழக்கச் செய்யும். இந்த எல்லைகளை மனதில் கொண்டு உங்கள் காம்போனென்ட் மரத்தை வடிவமைக்க வேண்டும்.
முன்கூட்டிய மேம்படுத்தல்: `use(Context)` செயல்திறனுக்கு சிறந்தது என்றாலும், அது எப்போதும் அவசியமில்லை. எளிமையான, அரிதாக மாறும், அல்லது நுகர்வோர் மீண்டும் ரெண்டர் செய்ய மலிவான context-களுக்கு, பாரம்பரிய `useContext` முற்றிலும் சரியானது மற்றும் சற்று நேரடியானது. தெளிவான செயல்திறன் காரணம் இல்லாமல் உங்கள் குறியீட்டை மிகைப்படுத்த வேண்டாம்.
`cache`-ஐ தவறாகப் புரிந்துகொள்வது: ரியாக்ட்டின் `cache` செயல்பாடு அதன் ஆர்குமென்ட்களின் அடிப்படையில் மெமோயிஸ் செய்கிறது, ஆனால் இந்த கேச் பொதுவாக சர்வர் கோரிக்கைகளுக்கு இடையில் அல்லது கிளையண்டில் ஒரு முழுப் பக்க மறுஏற்றத்தின்போது அழிக்கப்படுகிறது. இது கோரிக்கை-நிலை கேச்சிங்கிற்காக வடிவமைக்கப்பட்டுள்ளது, நீண்ட கால கிளையன்ட்-பக்க நிலைக்கு அல்ல. சிக்கலான கிளையன்ட்-பக்க கேச்சிங், செல்லாததாக்குதல் மற்றும் மாற்றத்திற்கு, ஒரு பிரத்யேக தரவுப் பெறும் லைப்ரரி இன்னும் ஒரு மிக வலுவான தேர்வாகும்.

சிறந்த நடைமுறைகள் சரிபார்ப்புப் பட்டியல்

✅ எல்லைகளைத் தழுவுங்கள்: நன்கு வைக்கப்பட்ட `` மற்றும் `` காம்போனென்ட்களுடன் உங்கள் பயன்பாட்டைக் கட்டமைக்கவும். முழு துணை மரங்களுக்கும் ஏற்றுதல் மற்றும் பிழை நிலைகளைக் கையாள்வதற்கான அறிவிப்பு வலைகளாக அவற்றைக் கருதுங்கள்.
✅ தரவுப் பெறுதலை மையப்படுத்துங்கள்: உங்கள் கேச் செய்யப்பட்ட தரவுப் பெறும் செயல்பாடுகளை வரையறுக்கும் ஒரு பிரத்யேக `api.js` அல்லது ஒத்த மாட்யூலை உருவாக்கவும். இது உங்கள் காம்போனென்ட்களை சுத்தமாகவும், உங்கள் கேச்சிங் தர்க்கத்தை சீராகவும் வைத்திருக்கும்.
✅ `use(Context)`-ஐ தந்திரோபாயமாகப் பயன்படுத்துங்கள்: அடிக்கடி context புதுப்பிப்புகளுக்கு உணர்திறன் கொண்ட ஆனால் நிபந்தனையுடன் மட்டுமே தரவு தேவைப்படும் காம்போனென்ட்களை அடையாளம் காணவும். இவை `useContext`-இலிருந்து `use`-க்கு மறுசீரமைக்க முதன்மை வேட்பாளர்கள்.
✅ வளங்களில் சிந்தியுங்கள்: உங்கள் மன மாதிரியை நிலையை (`isLoading`, `data`, `error`) நிர்வகிப்பதிலிருந்து வளங்களை (Promises, Context) நுகர்வதற்கு மாற்றவும். ரியாக்ட் மற்றும் `use` ஹூக் ஏற்றுதல் மற்றும் பிழை கையாளுதலில் ஈடுபட்டுள்ள சிக்கலான நிலை மாற்றங்களைக் கையாளட்டும்.
✅ விதிகளை நினைவில் கொள்ளுங்கள் (மற்ற ஹூக்ஸிற்காக): `use` ஹூக் விதிவிலக்கு. ஹூக்ஸின் அசல் விதிகள் இன்னும் `useState`, `useEffect`, `useMemo` போன்றவற்றிற்கு பொருந்தும். அவற்றை `if` கூற்றுகளுக்குள் வைக்கத் தொடங்க வேண்டாம்.

எதிர்காலம் `use` தான்: சர்வர் காம்போனென்ட்ஸ் மற்றும் அதற்கு அப்பால்

`use` ஹூக் ஒரு கிளையன்ட்-பக்க வசதி மட்டுமல்ல; இது ரியாக்ட் சர்வர் காம்போனென்ட்களின் (RSCs) ஒரு அடிப்படைக் தூணாகும். ஒரு RSC சூழலில், ஒரு காம்போனென்ட் சர்வரில் செயல்படுத்தப்படலாம். அது `use(fetch(...))` ஐ அழைக்கும்போது, சர்வர் அந்த காம்போனென்ட்டின் ரெண்டரிங்கை உண்மையில் இடைநிறுத்தி, தரவுத்தள வினவல் அல்லது API அழைப்பு முடிவடையும் வரை காத்திருந்து, பின்னர் தரவுடன் ரெண்டரிங்கைத் தொடரலாம், இறுதி HTML-ஐ கிளையண்டிற்கு ஸ்ட்ரீம் செய்யலாம்.

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

`use` API நீட்டிக்கக்கூடியதும் கூட. எதிர்காலத்தில், இது Observables (எ.கா., RxJS-இலிருந்து) அல்லது பிற தனிப்பயன் "thenable" ஆப்ஜெக்ட்கள் போன்ற பிற ஒத்திசைவற்ற மூலங்களிலிருந்து மதிப்புகளை வெளிக்கொணரப் பயன்படுத்தப்படலாம், ரியாக்ட் காம்போனென்ட்கள் வெளிப்புற தரவு மற்றும் நிகழ்வுகளுடன் எவ்வாறு தொடர்பு கொள்கின்றன என்பதை மேலும் ஒருங்கிணைக்கிறது.

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

`use` ஹூக் ஒரு புதிய API-ஐ விட மேலானது; இது சுத்தமான, மேலும் அறிவிப்பு, மற்றும் அதிக செயல்திறன் கொண்ட ரியாக்ட் பயன்பாடுகளை எழுதுவதற்கான ஒரு அழைப்பாகும். ஒத்திசைவற்ற செயல்பாடுகள் மற்றும் context நுகர்வை ரெண்டரிங் ஓட்டத்தில் நேரடியாக ஒருங்கிணைப்பதன் மூலம், இது பல ஆண்டுகளாக சிக்கலான முறைகள் மற்றும் பாய்லர்பிளேட் தேவைப்பட்ட சிக்கல்களை நேர்த்தியாக தீர்க்கிறது.

ஒவ்வொரு உலகளாவிய டெவலப்பருக்குமான முக்கிய படிப்பினைகள்:

Promises-க்கு: `use` தரவுப் பெறுதலை மிகவும் எளிதாக்குகிறது, ஆனால் அது ஒரு வலுவான கேச்சிங் உத்தி மற்றும் சஸ்பென்ஸ் மற்றும் எரர் பவுண்டரிகளின் சரியான பயன்பாட்டைக் கட்டாயப்படுத்துகிறது.
Context-க்கு: `use` நிபந்தனைக்குட்பட்ட சந்தாக்களை இயக்குவதன் மூலம் ஒரு சக்திவாய்ந்த செயல்திறன் மேம்படுத்தலை வழங்குகிறது, `useContext`-ஐப் பயன்படுத்தும் பெரிய பயன்பாடுகளை பாதிக்கும் தேவையற்ற மறு-ரெண்டர்களைத் தடுக்கிறது.
கட்டமைப்புக்கு: இது காம்போனென்ட்களை வளங்களின் நுகர்வோராக நினைப்பதைப் நோக்கிய ஒரு மாற்றத்தை ஊக்குவிக்கிறது, ஏற்றுதல் மற்றும் பிழை கையாளுதலில் ஈடுபட்டுள்ள சிக்கலான நிலை மாற்றங்களை ரியாக்ட் நிர்வகிக்க அனுமதிக்கிறது.

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

`use` ஹூக் பற்றிய உங்கள் எண்ணங்கள் என்ன? நீங்கள் அதை பரிசோதிக்கத் தொடங்கிவிட்டீர்களா? உங்கள் அனுபவங்கள், கேள்விகள் மற்றும் நுண்ணறிவுகளை கீழே உள்ள கருத்துகளில் பகிர்ந்து கொள்ளுங்கள்!