ರಿಯಾಕ್ಟ್‌ನ `use` ಹುಕ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು: ಪ್ರಾಮಿಸಸ್, ಕಾಂಟೆಕ್ಸ್ಟ್, ಮತ್ತು ರಿಸೋರ್ಸ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ನ ಆಳವಾದ ವಿಶ್ಲೇಷಣೆ

ರಿಯಾಕ್ಟ್‌ನ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ನಿರಂತರವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿದ್ದು, ಡೆವಲಪರ್‌ಗಳ ಅನುಭವವನ್ನು ಸುಧಾರಿಸುತ್ತಿದೆ ಮತ್ತು ವೆಬ್‌ನಲ್ಲಿ ಸಾಧ್ಯವಿರುವುದರ ಗಡಿಗಳನ್ನು ವಿಸ್ತರಿಸುತ್ತಿದೆ. ಕ್ಲಾಸ್‌ಗಳಿಂದ ಹಿಡಿದು ಹುಕ್ಸ್‌ವರೆಗೆ, ಪ್ರತಿಯೊಂದು ಪ್ರಮುಖ ಬದಲಾವಣೆಯು ನಾವು ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ರೀತಿಯನ್ನು ಮೂಲಭೂತವಾಗಿ ಬದಲಾಯಿಸಿದೆ. ಇಂದು, ನಾವು ಅಂತಹ ಮತ್ತೊಂದು ಪರಿವರ್ತನೆಯ ಹೊಸ್ತಿಲಲ್ಲಿದ್ದೇವೆ, ಇದನ್ನು ಸರಳವಾಗಿ ಕಾಣುವ ಒಂದು ಫಂಕ್ಷನ್ ಘೋಷಿಸಿದೆ: `use` ಹುಕ್.

ವರ್ಷಗಳಿಂದ, ಡೆವಲಪರ್‌ಗಳು ಅಸಿಂಕ್ರೋನಸ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಮತ್ತು ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ನ ಸಂಕೀರ್ಣತೆಗಳೊಂದಿಗೆ ಹೋರಾಡಿದ್ದಾರೆ. ಡೇಟಾ ತರುವುದು ಎಂದರೆ ಹೆಚ್ಚಾಗಿ `useEffect`, `useState`, ಮತ್ತು ಲೋಡಿಂಗ್/ಎರರ್ ಸ್ಟೇಟ್‌ಗಳ ಗೋಜಲಿನ ಜಾಲ. ಕಾಂಟೆಕ್ಸ್ಟ್ ಬಳಸುವುದು ಶಕ್ತಿಯುತವಾಗಿದ್ದರೂ, ಪ್ರತಿಯೊಬ್ಬ ಗ್ರಾಹಕನಲ್ಲಿ ರೀ-ರೆಂಡರ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸುವ ಗಮನಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆಯ ನ್ಯೂನತೆಯೊಂದಿಗೆ ಬರುತ್ತಿತ್ತು. `use` ಹುಕ್ ಈ ದೀರ್ಘಕಾಲದ ಸವಾಲುಗಳಿಗೆ ರಿಯಾಕ್ಟ್‌ನ ಸೊಗಸಾದ ಉತ್ತರವಾಗಿದೆ.

ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ ವೃತ್ತಿಪರ ರಿಯಾಕ್ಟ್ ಡೆವಲಪರ್‌ಗಳ ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ನಾವು `use` ಹುಕ್‌ನ ಆಳಕ್ಕೆ ಇಳಿದು, ಅದರ ಕಾರ್ಯವಿಧಾನವನ್ನು ವಿಭಜಿಸಿ, ಮತ್ತು ಅದರ ಎರಡು ಪ್ರಾಥಮಿಕ ಆರಂಭಿಕ ಬಳಕೆಯ ಪ್ರಕರಣಗಳನ್ನು ಅನ್ವೇಷಿಸುತ್ತೇವೆ: ಪ್ರಾಮಿಸಸ್‌ಗಳನ್ನು ಅನ್‌ವ್ರ್ಯಾಪ್ ಮಾಡುವುದು ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಿಂದ ಓದುವುದು. ಮುಖ್ಯವಾಗಿ, ನಾವು ರಿಸೋರ್ಸ್ ಬಳಕೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮೇಲೆ ಅದರ ಆಳವಾದ ಪರಿಣಾಮಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ. ನಿಮ್ಮ ರಿಯಾಕ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಅಸಿಂಕ್ ಲಾಜಿಕ್ ಮತ್ತು ಸ್ಟೇಟ್ ಅನ್ನು ನಿಭಾಯಿಸುವ ನಿಮ್ಮ ರೀತಿಯನ್ನು ಮರುಚಿಂತನೆ ಮಾಡಲು ಸಿದ್ಧರಾಗಿ.

ಒಂದು ಮೂಲಭೂತ ಬದಲಾವಣೆ: `use` ಹುಕ್ ಅನ್ನು ಯಾವುದು ವಿಭಿನ್ನವಾಗಿಸುತ್ತದೆ?

ನಾವು ಪ್ರಾಮಿಸಸ್ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್‌ನ ಬಗ್ಗೆ ಆಳವಾಗಿ ಚರ್ಚಿಸುವ ಮೊದಲು, `use` ಏಕೆ ಇಷ್ಟು ಕ್ರಾಂತಿಕಾರಕವಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ವರ್ಷಗಳಿಂದ, ರಿಯಾಕ್ಟ್ ಡೆವಲಪರ್‌ಗಳು ಕಟ್ಟುನಿಟ್ಟಾದ ಹುಕ್ಸ್ ನಿಯಮಗಳ (Rules of Hooks) ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದ್ದಾರೆ:

• ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್‌ನ ಟಾಪ್ ಲೆವೆಲ್‌ನಲ್ಲಿ ಮಾತ್ರ ಹುಕ್ಸ್‌ಗಳನ್ನು ಕಾಲ್ ಮಾಡಿ.
• ಲೂಪ್‌ಗಳು, ಕಂಡೀಶನ್‌ಗಳು, ಅಥವಾ ನೆಸ್ಟೆಡ್ ಫಂಕ್ಷನ್‌ಗಳ ಒಳಗೆ ಹುಕ್ಸ್‌ಗಳನ್ನು ಕಾಲ್ ಮಾಡಬೇಡಿ.

ಈ ನಿಯಮಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಏಕೆಂದರೆ `useState` ಮತ್ತು `useEffect` ನಂತಹ ಸಾಂಪ್ರದಾಯಿಕ ಹುಕ್ಸ್‌ಗಳು ತಮ್ಮ ಸ್ಟೇಟ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರತಿ ರೆಂಡರ್ ಸಮಯದಲ್ಲಿ ಸ್ಥಿರವಾದ ಕಾಲ್ ಆರ್ಡರ್ ಅನ್ನು ಅವಲಂಬಿಸಿವೆ. `use` ಹುಕ್ ಈ ಪದ್ಧತಿಯನ್ನು ಮುರಿಯುತ್ತದೆ. ನೀವು `use` ಅನ್ನು ಕಂಡೀಶನ್‌ಗಳ (`if`/`else`), ಲೂಪ್‌ಗಳ (`for`/`map`), ಮತ್ತು ಬೇಗನೆ `return` ಮಾಡುವ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳ ಒಳಗೆ ಕೂಡ ಕಾಲ್ ಮಾಡಬಹುದು.

ಇದು ಕೇವಲ ಒಂದು ಸಣ್ಣ ಹೊಂದಾಣಿಕೆಯಲ್ಲ; ಇದು ಒಂದು ಮಾದರಿ ಬದಲಾವಣೆ. ಇದು ರಿಸೋರ್ಸ್‌ಗಳನ್ನು ಬಳಸಲು ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಸಹಜವಾದ ಮಾರ್ಗವನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಸ್ಥಿರವಾದ, ಟಾಪ್-ಲೆವೆಲ್ ಚಂದಾದಾರಿಕೆ ಮಾದರಿಯಿಂದ ಕ್ರಿಯಾತ್ಮಕ, ಬೇಡಿಕೆಯ ಮೇರೆಗೆ ಬಳಸುವ ಮಾದರಿಗೆ ಚಲಿಸುತ್ತದೆ. ಇದು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ವಿವಿಧ ರಿಸೋರ್ಸ್ ಪ್ರಕಾರಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದಾದರೂ, ಅದರ ಆರಂಭಿಕ ಅನುಷ್ಠಾನವು ರಿಯಾಕ್ಟ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಲ್ಲಿನ ಎರಡು ಸಾಮಾನ್ಯ ನೋವಿನ ಬಿಂದುಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ: ಪ್ರಾಮಿಸಸ್ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್.

ಮೂಲ ಪರಿಕಲ್ಪನೆ: ಮೌಲ್ಯಗಳನ್ನು ಅನ್‌ವ್ರ್ಯಾಪ್ ಮಾಡುವುದು

ಅದರ ಹೃದಯಭಾಗದಲ್ಲಿ, `use` ಹುಕ್ ಒಂದು ರಿಸೋರ್ಸ್‌ನಿಂದ ಮೌಲ್ಯವನ್ನು "ಅನ್‌ವ್ರ್ಯಾಪ್" ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇದನ್ನು ಈ ರೀತಿ ಯೋಚಿಸಿ:

• ನೀವು ಅದಕ್ಕೆ ಪ್ರಾಮಿಸ್ (Promise) ಅನ್ನು ಪಾಸ್ ಮಾಡಿದರೆ, ಅದು ರಿಸಾಲ್ವ್ ಆದ ಮೌಲ್ಯವನ್ನು ಅನ್‌ವ್ರ್ಯಾಪ್ ಮಾಡುತ್ತದೆ. ಪ್ರಾಮಿಸ್ ಪೆಂಡಿಂಗ್‌ನಲ್ಲಿದ್ದರೆ, ಅದು ರಿಯಾಕ್ಟ್‌ಗೆ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಸಸ್ಪೆಂಡ್ ಮಾಡಲು ಸಂಕೇತಿಸುತ್ತದೆ. ಅದು ರಿಜೆಕ್ಟ್ ಆಗಿದ್ದರೆ, ಅದು ಎರರ್ ಅನ್ನು ಎರರ್ ಬೌಂಡರಿಯಿಂದ ಹಿಡಿಯಲು ಎಸೆಯುತ್ತದೆ.
• ನೀವು ಅದಕ್ಕೆ ರಿಯಾಕ್ಟ್ ಕಾಂಟೆಕ್ಸ್ಟ್ (React Context) ಅನ್ನು ಪಾಸ್ ಮಾಡಿದರೆ, ಅದು `useContext` ನಂತೆ ಪ್ರಸ್ತುತ ಕಾಂಟೆಕ್ಸ್ಟ್ ಮೌಲ್ಯವನ್ನು ಅನ್‌ವ್ರ್ಯಾಪ್ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅದರ ಷರತ್ತುಬದ್ಧ ಸ್ವಭಾವವು ಕಾಂಪೊನೆಂಟ್‌ಗಳು ಕಾಂಟೆಕ್ಸ್ಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗೆ ಹೇಗೆ ಚಂದಾದಾರರಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ.

ಈ ಎರಡು ಶಕ್ತಿಯುತ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವಿವರವಾಗಿ ಅನ್ವೇಷಿಸೋಣ.

ಅಸಿಂಕ್ರೋನಸ್ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಪ್ರಾವೀಣ್ಯತೆ: ಪ್ರಾಮಿಸಸ್‌ಗಳೊಂದಿಗೆ `use`

ಡೇಟಾ ಫೆಚಿಂಗ್ ಆಧುನಿಕ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಜೀವನಾಡಿಯಾಗಿದೆ. ರಿಯಾಕ್ಟ್‌ನಲ್ಲಿನ ಸಾಂಪ್ರದಾಯಿಕ ವಿಧಾನವು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿದ್ದರೂ, ಸಾಮಾನ್ಯವಾಗಿ ಅದು ಹೆಚ್ಚು ಪದಬಾಹುಳ್ಯ ಮತ್ತು ಸೂಕ್ಷ್ಮ ದೋಷಗಳಿಗೆ ಗುರಿಯಾಗುತ್ತಿತ್ತು.

ಹಳೆಯ ವಿಧಾನ: `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` ನೊಂದಿಗೆ ಹೇಗೆ ಬರೆಯಬಹುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:

// ನೀವು ಈ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು <Suspense> ಮತ್ತು <ErrorBoundary> ನಲ್ಲಿ ಸುತ್ತಬೇಕು
import { use } from 'react';
import { fetchUser } from './api'; // ಇದು ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ

function UserProfile({ userId }) {
  // ಪ್ರಾಮಿಸ್ ರಿಸಾಲ್ವ್ ಆಗುವವರೆಗೆ `use` ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಸಸ್ಪೆಂಡ್ ಮಾಡುತ್ತದೆ
  const user = use(fetchUser(userId));

  // ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಇಲ್ಲಿಗೆ ತಲುಪಿದಾಗ, ಪ್ರಾಮಿಸ್ ರಿಸಾಲ್ವ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು `user` ನಲ್ಲಿ ಡೇಟಾ ಇರುತ್ತದೆ.
  // ಕಾಂಪೊನೆಂಟ್‌ನಲ್ಲಿ isLoading ಅಥವಾ error ಸ್ಟೇಟ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲ.
  return (
    <div>
      <h1>{user.name}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
}

ವ್ಯತ್ಯಾಸವು ದಿಗ್ಭ್ರಮೆಗೊಳಿಸುವಂತಿದೆ. ಲೋಡಿಂಗ್ ಮತ್ತು ಎರರ್ ಸ್ಟೇಟ್‌ಗಳು ನಮ್ಮ ಕಾಂಪೊನೆಂಟ್ ಲಾಜಿಕ್‌ನಿಂದ ಕಣ್ಮರೆಯಾಗಿವೆ. ತೆರೆಮರೆಯಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ?

1. `UserProfile` ಮೊದಲ ಬಾರಿಗೆ ರೆಂಡರ್ ಆದಾಗ, ಅದು `use(fetchUser(userId))` ಅನ್ನು ಕಾಲ್ ಮಾಡುತ್ತದೆ.
2. `fetchUser` ಫಂಕ್ಷನ್ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಾಮಿಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
3. `use` ಹುಕ್ ಈ ಪೆಂಡಿಂಗ್ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಕಾಂಪೊನೆಂಟ್‌ನ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಸಸ್ಪೆಂಡ್ (suspend) ಮಾಡಲು ರಿಯಾಕ್ಟ್‌ನ ರೆಂಡರರ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.
4. ರಿಯಾಕ್ಟ್ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯನ್ನು ಹತ್ತಿ ಹತ್ತಿರದ `<Suspense>` ಬೌಂಡರಿಯನ್ನು ಹುಡುಕುತ್ತದೆ ಮತ್ತು ಅದರ `fallback` UI ಅನ್ನು (ಉದಾ., ಸ್ಪಿನ್ನರ್) ಪ್ರದರ್ಶಿಸುತ್ತದೆ.
5. ಪ್ರಾಮಿಸ್ ರಿಸಾಲ್ವ್ ಆದ ನಂತರ, ರಿಯಾಕ್ಟ್ `UserProfile` ಅನ್ನು ಮರು-ರೆಂಡರ್ ಮಾಡುತ್ತದೆ. ಈ ಬಾರಿ, ಅದೇ ಪ್ರಾಮಿಸ್‌ನೊಂದಿಗೆ `use` ಅನ್ನು ಕಾಲ್ ಮಾಡಿದಾಗ, ಪ್ರಾಮಿಸ್‌ಗೆ ರಿಸಾಲ್ವ್ ಆದ ಮೌಲ್ಯವಿರುತ್ತದೆ. `use` ಈ ಮೌಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
6. ಕಾಂಪೊನೆಂಟ್ ರೆಂಡರಿಂಗ್ ಮುಂದುವರಿಯುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ.
7. ಪ್ರಾಮಿಸ್ ರಿಜೆಕ್ಟ್ ಆದರೆ, `use` ಎರರ್ ಅನ್ನು ಎಸೆಯುತ್ತದೆ. ರಿಯಾಕ್ಟ್ ಇದನ್ನು ಹಿಡಿಯುತ್ತದೆ ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್ ಎರರ್ UI ಅನ್ನು ಪ್ರದರ್ಶಿಸಲು ಹತ್ತಿರದ `<ErrorBoundary>` ಗೆ ಮರಳಿ ಹೋಗುತ್ತದೆ.

ರಿಸೋರ್ಸ್ ಬಳಕೆಯ ಆಳವಾದ ವಿಶ್ಲೇಷಣೆ: ಕ್ಯಾಶಿಂಗ್‌ನ ಅನಿವಾರ್ಯತೆ

`use(fetchUser(userId))` ನ ಸರಳತೆಯು ಒಂದು ನಿರ್ಣಾಯಕ ವಿವರವನ್ನು ಮರೆಮಾಡುತ್ತದೆ: ನೀವು ಪ್ರತಿ ರೆಂಡರ್‌ನಲ್ಲಿ ಹೊಸ ಪ್ರಾಮಿಸ್ ಅನ್ನು ರಚಿಸಬಾರದು. ನಮ್ಮ `fetchUser` ಫಂಕ್ಷನ್ ಕೇವಲ `() => fetch(...)` ಆಗಿದ್ದರೆ, ಮತ್ತು ನಾವು ಅದನ್ನು ನೇರವಾಗಿ ಕಾಂಪೊನೆಂಟ್‌ನೊಳಗೆ ಕಾಲ್ ಮಾಡಿದರೆ, ನಾವು ಪ್ರತಿ ರೆಂಡರ್ ಪ್ರಯತ್ನದಲ್ಲಿ ಹೊಸ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ, ಇದು ಅನಂತ ಲೂಪ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಕಾಂಪೊನೆಂಟ್ ಸಸ್ಪೆಂಡ್ ಆಗುತ್ತದೆ, ಪ್ರಾಮಿಸ್ ರಿಸಾಲ್ವ್ ಆಗುತ್ತದೆ, ರಿಯಾಕ್ಟ್ ಮರು-ರೆಂಡರ್ ಮಾಡುತ್ತದೆ, ಒಂದು ಹೊಸ ಪ್ರಾಮಿಸ್ ರಚನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ಮತ್ತೆ ಸಸ್ಪೆಂಡ್ ಆಗುತ್ತದೆ.

ಪ್ರಾಮಿಸಸ್‌ಗಳೊಂದಿಗೆ `use` ಬಳಸುವಾಗ ಗ್ರಹಿಸಬೇಕಾದ ಪ್ರಮುಖ ರಿಸೋರ್ಸ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪರಿಕಲ್ಪನೆ ಇದಾಗಿದೆ. ಪ್ರಾಮಿಸ್ ಸ್ಥಿರವಾಗಿರಬೇಕು ಮತ್ತು ಮರು-ರೆಂಡರ್‌ಗಳಾದ್ಯಂತ ಕ್ಯಾಶ್ ಆಗಿರಬೇಕು.

ರಿಯಾಕ್ಟ್ ಇದಕ್ಕೆ ಸಹಾಯ ಮಾಡಲು ಹೊಸ `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)` ಅನ್ನು ಕಾಲ್ ಮಾಡಿದಾಗ, ಅದು ಫೆಚ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ ಬರುವ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಮತ್ತೊಂದು ಕಾಂಪೊನೆಂಟ್ (ಅಥವಾ ನಂತರದ ರೆಂಡರ್‌ನಲ್ಲಿ ಅದೇ ಕಾಂಪೊನೆಂಟ್) ಅದೇ ರೆಂಡರ್ ಪಾಸ್‌ನಲ್ಲಿ ಮತ್ತೆ `fetchUser(1)` ಅನ್ನು ಕಾಲ್ ಮಾಡಿದರೆ, `cache` ಅದೇ ಪ್ರಾಮಿಸ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅನಗತ್ಯ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ಇದು ಡೇಟಾ ಫೆಚಿಂಗ್ ಅನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ (idempotent) ಮತ್ತು `use` ಹುಕ್‌ನೊಂದಿಗೆ ಬಳಸಲು ಸುರಕ್ಷಿತವಾಗಿಸುತ್ತದೆ.

ಇದು ರಿಸೋರ್ಸ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಒಂದು ಮೂಲಭೂತ ಬದಲಾವಣೆಯಾಗಿದೆ. ಕಾಂಪೊನೆಂಟ್‌ನೊಳಗೆ ಫೆಚ್ ಸ್ಟೇಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಬದಲು, ನಾವು ರಿಸೋರ್ಸ್ ಅನ್ನು (ಡೇಟಾ ಪ್ರಾಮಿಸ್) ಅದರ ಹೊರಗೆ ನಿರ್ವಹಿಸುತ್ತೇವೆ, ಮತ್ತು ಕಾಂಪೊನೆಂಟ್ ಅದನ್ನು ಸರಳವಾಗಿ ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ.

ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಕ್ರಾಂತಿ: ಕಾಂಟೆಕ್ಸ್ಟ್‌ನೊಂದಿಗೆ `use`

ರಿಯಾಕ್ಟ್ ಕಾಂಟೆಕ್ಸ್ಟ್ "ಪ್ರಾಪ್ ಡ್ರಿಲ್ಲಿಂಗ್" (prop drilling)—ಅನೇಕ ಕಾಂಪೊನೆಂಟ್‌ಗಳ ಪದರಗಳ ಮೂಲಕ ಪ್ರಾಪ್ಸ್‌ಗಳನ್ನು ರವಾನಿಸುವುದನ್ನು—ತಪ್ಪಿಸಲು ಒಂದು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಅದರ ಸಾಂಪ್ರದಾಯಿಕ ಅನುಷ್ಠಾನವು ಒಂದು ಗಮನಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆಯ ನ್ಯೂನತೆಯನ್ನು ಹೊಂದಿದೆ.

`useContext` ಗೊಂದಲ

`useContext` ಹುಕ್ ಒಂದು ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗೆ ಚಂದಾದಾರರಾಗುವಂತೆ ಮಾಡುತ್ತದೆ. ಇದರರ್ಥ, ಕಾಂಟೆಕ್ಸ್ಟ್‌ನ ಮೌಲ್ಯವು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಬದಲಾದಾಗ, ಆ ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗಾಗಿ `useContext` ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಕಾಂಪೊನೆಂಟ್ ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ. ಕಾಂಪೊನೆಂಟ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ಮೌಲ್ಯದ ಒಂದು ಸಣ್ಣ, ಬದಲಾಗದ ಭಾಗದ ಬಗ್ಗೆ ಮಾತ್ರ ಕಾಳಜಿ ವಹಿಸಿದರೂ ಇದು ಸತ್ಯ.

ಬಳಕೆದಾರರ ಮಾಹಿತಿ ಮತ್ತು ಪ್ರಸ್ತುತ ಥೀಮ್ ಎರಡನ್ನೂ ಹೊಂದಿರುವ `SessionContext` ಅನ್ನು ಪರಿಗಣಿಸಿ:

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

// ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಮಾತ್ರ ಕಾಳಜಿವಹಿಸುವ ಕಾಂಪೊನೆಂಟ್
function WelcomeMessage() {
  const { user } = useContext(SessionContext);
  console.log('Rendering WelcomeMessage');
  return <p>Welcome, {user?.name}!</p>;
}

// ಥೀಮ್ ಬಗ್ಗೆ ಮಾತ್ರ ಕಾಳಜಿವಹಿಸುವ ಕಾಂಪೊನೆಂಟ್
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` ಮೌಲ್ಯದ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ. ಇದು `user` ಆಬ್ಜೆಕ್ಟ್ ಬದಲಾಗದಿದ್ದರೂ, `ThemeToggleButton` ಮತ್ತು `WelcomeMessage` ಎರಡೂ ಮರು-ರೆಂಡರ್ ಆಗಲು ಕಾರಣವಾಗುತ್ತದೆ. ನೂರಾರು ಕಾಂಟೆಕ್ಸ್ಟ್ ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿರುವ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಇದು ಗಂಭೀರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

`use(Context)` ಪ್ರವೇಶ: ಷರತ್ತುಬದ್ಧ ಬಳಕೆ

`use` ಹುಕ್ ಈ ಸಮಸ್ಯೆಗೆ ಒಂದು ಕ್ರಾಂತಿಕಾರಿ ಪರಿಹಾರವನ್ನು ನೀಡುತ್ತದೆ. ಇದನ್ನು ಷರತ್ತುಬದ್ಧವಾಗಿ ಕಾಲ್ ಮಾಡಬಹುದಾದ್ದರಿಂದ, ಒಂದು ಕಾಂಪೊನೆಂಟ್ ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗೆ ಚಂದಾದಾರಿಕೆಯನ್ನು ಸ್ಥಾಪಿಸುವುದು ಅದು ನಿಜವಾಗಿಯೂ ಮೌಲ್ಯವನ್ನು ಓದಿದಾಗ ಮಾತ್ರ.

ಈ ಶಕ್ತಿಯನ್ನು ಪ್ರದರ್ಶಿಸಲು ಒಂದು ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಮರುರೂಪಿಸೋಣ:

function UserSettings({ userId }) {
  const { user, theme } = useContext(SessionContext); // ಸಾಂಪ್ರದಾಯಿಕ ವಿಧಾನ: ಯಾವಾಗಲೂ ಚಂದಾದಾರರಾಗುತ್ತದೆ

  // ನಾವು ಪ್ರಸ್ತುತ ಲಾಗಿನ್ ಆಗಿರುವ ಬಳಕೆದಾರರಿಗೆ ಮಾತ್ರ ಥೀಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತೇವೆ ಎಂದು ಭಾವಿಸೋಣ
  if (user?.id !== userId) {
    return <p>You can only view your own settings.</p>;
  }

  // ಈ ಭಾಗವು ಬಳಕೆದಾರರ ID ಹೊಂದಾಣಿಕೆಯಾದರೆ ಮಾತ್ರ ಚಲಿಸುತ್ತದೆ
  return <div>Current theme: {theme}</div>;
}

`useContext` ನೊಂದಿಗೆ, `user.id !== userId` ಆಗಿದ್ದರೂ ಮತ್ತು ಥೀಮ್ ಮಾಹಿತಿಯನ್ನು ಎಂದಿಗೂ ಪ್ರದರ್ಶಿಸದಿದ್ದರೂ, ಥೀಮ್ ಬದಲಾದಾಗಲೆಲ್ಲಾ ಈ `UserSettings` ಕಾಂಪೊನೆಂಟ್ ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ. ಚಂದಾದಾರಿಕೆಯನ್ನು ಟಾಪ್ ಲೆವೆಲ್‌ನಲ್ಲಿ ಬೇಷರತ್ತಾಗಿ ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ.

ಈಗ, `use` ಆವೃತ್ತಿಯನ್ನು ನೋಡೋಣ:

import { use } from 'react';

function UserSettings({ userId }) {
  // ಮೊದಲು ಬಳಕೆದಾರರನ್ನು ಓದಿ. ಈ ಭಾಗ ಅಗ್ಗ ಅಥವಾ ಅವಶ್ಯಕ ಎಂದು ಭಾವಿಸೋಣ.
  const user = use(SessionContext).user;

  // ಷರತ್ತು ಪೂರೈಸದಿದ್ದರೆ, ನಾವು ಬೇಗನೆ ಹಿಂತಿರುಗುತ್ತೇವೆ.
  // ನಿರ್ಣಾಯಕವಾಗಿ, ನಾವು ಇನ್ನೂ ಥೀಮ್ ಅನ್ನು ಓದಿಲ್ಲ.
  if (user?.id !== userId) {
    return <p>You can only view your own settings.</p>;
  }

  // ಷರತ್ತು ಪೂರೈಸಿದರೆ ಮಾತ್ರ, ನಾವು ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಿಂದ ಥೀಮ್ ಅನ್ನು ಓದುತ್ತೇವೆ.
  // ಕಾಂಟೆಕ್ಸ್ಟ್ ಬದಲಾವಣೆಗಳಿಗೆ ಚಂದಾದಾರಿಕೆಯನ್ನು ಇಲ್ಲಿ, ಷರತ್ತುಬದ್ಧವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ.
  const theme = use(SessionContext).theme;

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

ಇದು ಗೇಮ್-ಚೇಂಜರ್ ಆಗಿದೆ. ಈ ಆವೃತ್ತಿಯಲ್ಲಿ, `user.id` `userId` ಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಕಾಂಪೊನೆಂಟ್ ಬೇಗನೆ ಹಿಂತಿರುಗುತ್ತದೆ. `const theme = use(SessionContext).theme;` ಸಾಲು ಎಂದಿಗೂ ಕಾರ್ಯಗತಗೊಳ್ಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಈ ಕಾಂಪೊನೆಂಟ್ ಇನ್‌ಸ್ಟೆನ್ಸ್ `SessionContext` ಗೆ ಚಂದಾದಾರರಾಗುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಬೇರೆಡೆ ಥೀಮ್ ಬದಲಾದರೆ, ಈ ಕಾಂಪೊನೆಂಟ್ ಅನಗತ್ಯವಾಗಿ ಮರು-ರೆಂಡರ್ ಆಗುವುದಿಲ್ಲ. ಇದು ಷರತ್ತುಬದ್ಧವಾಗಿ ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಿಂದ ಓದುವ ಮೂಲಕ ತನ್ನದೇ ಆದ ರಿಸೋರ್ಸ್ ಬಳಕೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಿದೆ.

ರಿಸೋರ್ಸ್ ಬಳಕೆಯ ವಿಶ್ಲೇಷಣೆ: ಚಂದಾದಾರಿಕೆ ಮಾದರಿಗಳು

ಕಾಂಟೆಕ್ಸ್ಟ್ ಬಳಕೆಯ ಮಾನಸಿಕ ಮಾದರಿಯು ನಾಟಕೀಯವಾಗಿ ಬದಲಾಗುತ್ತದೆ:

• `useContext`: ಒಂದು ಆತುರದ, ಟಾಪ್-ಲೆವೆಲ್ ಚಂದಾದಾರಿಕೆ. ಕಾಂಪೊನೆಂಟ್ ತನ್ನ ಅವಲಂಬನೆಯನ್ನು ಮುಂಚಿತವಾಗಿ ಘೋಷಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಕಾಂಟೆಕ್ಸ್ಟ್ ಬದಲಾವಣೆಯ ಮೇಲೆ ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ.
• `use(Context)`: ಒಂದು ಸೋಮಾರಿಯಾದ, ಬೇಡಿಕೆಯ ಮೇರೆಗಿನ ಓದುವಿಕೆ. ಕಾಂಪೊನೆಂಟ್ ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಿಂದ ಓದುವ ಕ್ಷಣದಲ್ಲಿ ಮಾತ್ರ ಚಂದಾದಾರರಾಗುತ್ತದೆ. ಆ ಓದುವಿಕೆ ಷರತ್ತುಬದ್ಧವಾಗಿದ್ದರೆ, ಚಂದಾದಾರಿಕೆಯೂ ಷರತ್ತುಬದ್ಧವಾಗಿರುತ್ತದೆ.

ಮರು-ರೆಂಡರ್‌ಗಳ ಮೇಲಿನ ಈ ಸೂಕ್ಷ್ಮ-ಧಾನ್ಯದ ನಿಯಂತ್ರಣವು ದೊಡ್ಡ-ಪ್ರಮಾಣದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಾಗಿ ಒಂದು ಶಕ್ತಿಯುತ ಸಾಧನವಾಗಿದೆ. ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಪ್ರಸ್ತುತ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಂದ ನಿಜವಾಗಿಯೂ ಪ್ರತ್ಯೇಕವಾಗಿರುವ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಸಂಕೀರ್ಣ ಮೆಮೋಯಿಝೇಶನ್ (`React.memo`) ಅಥವಾ ಸ್ಟೇಟ್ ಸೆಲೆಕ್ಟರ್ ಮಾದರಿಗಳನ್ನು ಆಶ್ರಯಿಸದೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಮತ್ತು ಸ್ಪಂದಿಸುವ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಛೇದನ: ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಲ್ಲಿ ಪ್ರಾಮಿಸಸ್‌ಗಳೊಂದಿಗೆ `use`

ನಾವು ಈ ಎರಡು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸಂಯೋಜಿಸಿದಾಗ `use` ನ ನಿಜವಾದ ಶಕ್ತಿಯು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಕಾಂಟೆಕ್ಸ್ಟ್ ಪ್ರೊವೈಡರ್ ನೇರವಾಗಿ ಡೇಟಾವನ್ನು ಒದಗಿಸದಿದ್ದರೆ, ಆದರೆ ಆ ಡೇಟಾಕ್ಕಾಗಿ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಒದಗಿಸಿದರೆ ಏನು? ಈ ಮಾದರಿಯು ಅಪ್ಲಿಕೇಶನ್-ವ್ಯಾಪಿ ಡೇಟಾ ಮೂಲಗಳನ್ನು ನಿರ್ವಹಿಸಲು ನಂಬಲಾಗದಷ್ಟು ಉಪಯುಕ್ತವಾಗಿದೆ.

// DataContext.js
import { createContext } from 'react';
import { fetchSomeGlobalData } from './api'; // ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ

// ಕಾಂಟೆಕ್ಸ್ಟ್ ಡೇಟಾವನ್ನಲ್ಲ, ಪ್ರಾಮಿಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
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() {
  // ಮೊದಲ `use` ಕಾಂಟೆಕ್ಸ್ಟ್‌ನಿಂದ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಓದುತ್ತದೆ.
  const dataPromise = use(GlobalDataContext);

  // ಎರಡನೇ `use` ಪ್ರಾಮಿಸ್ ಅನ್ನು ಅನ್‌ವ್ರ್ಯಾಪ್ ಮಾಡುತ್ತದೆ, ಅಗತ್ಯವಿದ್ದರೆ ಸಸ್ಪೆಂಡ್ ಮಾಡುತ್ತದೆ.
  const globalData = use(dataPromise);

  // ಮೇಲಿನ ಎರಡು ಸಾಲುಗಳನ್ನು ಬರೆಯಲು ಹೆಚ್ಚು ಸಂಕ್ಷಿಪ್ತ ಮಾರ್ಗ:
  // const globalData = use(use(GlobalDataContext));

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

`const globalData = use(use(GlobalDataContext));` ಅನ್ನು ವಿಭಜಿಸೋಣ:

1. `use(GlobalDataContext)`: ಒಳಗಿನ ಕಾಲ್ ಮೊದಲು ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ. ಇದು `GlobalDataContext` ನಿಂದ ಮೌಲ್ಯವನ್ನು ಓದುತ್ತದೆ. ನಮ್ಮ ಸೆಟಪ್‌ನಲ್ಲಿ, ಈ ಮೌಲ್ಯವು `fetchSomeGlobalData()` ನಿಂದ ಹಿಂತಿರುಗಿಸಲ್ಪಟ್ಟ ಪ್ರಾಮಿಸ್ ಆಗಿದೆ.
2. `use(dataPromise)`: ಹೊರಗಿನ ಕಾಲ್ ನಂತರ ಈ ಪ್ರಾಮಿಸ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಇದು ನಾವು ಮೊದಲ ವಿಭಾಗದಲ್ಲಿ ನೋಡಿದಂತೆಯೇ ವರ್ತಿಸುತ್ತದೆ: ಪ್ರಾಮಿಸ್ ಪೆಂಡಿಂಗ್‌ನಲ್ಲಿದ್ದರೆ ಅದು `Dashboard` ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಸಸ್ಪೆಂಡ್ ಮಾಡುತ್ತದೆ, ರಿಜೆಕ್ಟ್ ಆಗಿದ್ದರೆ ಎಸೆಯುತ್ತದೆ, ಅಥವಾ ರಿಸಾಲ್ವ್ ಆದ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಈ ಮಾದರಿಯು ಅಸಾಧಾರಣವಾಗಿ ಶಕ್ತಿಯುತವಾಗಿದೆ. ಇದು ಡೇಟಾ-ಫೆಚಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ಡೇಟಾವನ್ನು ಬಳಸುವ ಕಾಂಪೊನೆಂಟ್‌ಗಳಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ತಡೆರಹಿತ ಲೋಡಿಂಗ್ ಅನುಭವಕ್ಕಾಗಿ ರಿಯಾಕ್ಟ್‌ನ ಅಂತರ್ನಿರ್ಮಿತ ಸಸ್ಪೆನ್ಸ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ. ಕಾಂಪೊನೆಂಟ್‌ಗಳು ಡೇಟಾವನ್ನು *ಹೇಗೆ* ಅಥವಾ *ಯಾವಾಗ* ಪಡೆಯಲಾಗುತ್ತದೆ ಎಂದು ತಿಳಿಯಬೇಕಾಗಿಲ್ಲ; ಅವು ಸರಳವಾಗಿ ಅದನ್ನು ಕೇಳುತ್ತವೆ, ಮತ್ತು ರಿಯಾಕ್ಟ್ ಉಳಿದದ್ದನ್ನು ಸಂಘಟಿಸುತ್ತದೆ.

ಕಾರ್ಯಕ್ಷಮತೆ, ಅಪಾಯಗಳು, ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

ಯಾವುದೇ ಶಕ್ತಿಯುತ ಸಾಧನದಂತೆ, `use` ಹುಕ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಲು ತಿಳುವಳಿಕೆ ಮತ್ತು ಶಿಸ್ತು ಬೇಕಾಗುತ್ತದೆ. ಉತ್ಪಾದನಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಕೆಲವು ಪ್ರಮುಖ ಪರಿಗಣನೆಗಳು ಇಲ್ಲಿವೆ.

ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಾರಾಂಶ

• ಲಾಭಗಳು: ಷರತ್ತುಬದ್ಧ ಚಂದಾದಾರಿಕೆಗಳಿಂದಾಗಿ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಂದ ಉಂಟಾಗುವ ಮರು-ರೆಂಡರ್‌ಗಳ ಸಂಖ್ಯೆ ತೀವ್ರವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಸ್ವಚ್ಛ, ಹೆಚ್ಚು ಓದಬಲ್ಲ ಅಸಿಂಕ್ ಲಾಜಿಕ್, ಇದು ಕಾಂಪೊನೆಂಟ್-ಮಟ್ಟದ ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ವೆಚ್ಚಗಳು: ಸಸ್ಪೆನ್ಸ್ ಮತ್ತು ಎರರ್ ಬೌಂಡರಿಗಳ ಬಗ್ಗೆ ದೃಢವಾದ ತಿಳುವಳಿಕೆ ಅಗತ್ಯವಿದೆ, ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಚರ್ಚಿಸಲಾಗದ ಭಾಗಗಳಾಗುತ್ತವೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ಸರಿಯಾದ ಪ್ರಾಮಿಸ್ ಕ್ಯಾಶಿಂಗ್ ತಂತ್ರದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.

ತಪ್ಪಿಸಬೇಕಾದ ಸಾಮಾನ್ಯ ಅಪಾಯಗಳು

1. ಕ್ಯಾಶ್ ಮಾಡದ ಪ್ರಾಮಿಸಸ್‌ಗಳು: ನಂಬರ್ ಒನ್ ತಪ್ಪು. ಕಾಂಪೊನೆಂಟ್‌ನಲ್ಲಿ ನೇರವಾಗಿ `use(fetch(...))` ಅನ್ನು ಕಾಲ್ ಮಾಡುವುದು ಅನಂತ ಲೂಪ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಯಾವಾಗಲೂ ರಿಯಾಕ್ಟ್‌ನ `cache` ಅಥವಾ SWR/React Query ನಂತಹ ಲೈಬ್ರರಿಗಳಂತಹ ಕ್ಯಾಶಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿ.
2. ಕಾಣೆಯಾದ ಬೌಂಡರಿಗಳು: ಪೋಷಕ `<Suspense>` ಬೌಂಡರಿ ಇಲ್ಲದೆ `use(Promise)` ಬಳಸುವುದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಅಂತೆಯೇ, ಪೋಷಕ `<ErrorBoundary>` ಇಲ್ಲದೆ ತಿರಸ್ಕರಿಸಿದ ಪ್ರಾಮಿಸ್ ಸಹ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡುತ್ತದೆ. ನೀವು ಈ ಬೌಂಡರಿಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕು.
3. ಅಕಾಲಿಕ ಆಪ್ಟಿಮೈಸೇಶನ್: `use(Context)` ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಉತ್ತಮವಾಗಿದ್ದರೂ, ಅದು ಯಾವಾಗಲೂ ಅಗತ್ಯವಿಲ್ಲ. ಸರಳವಾದ, ವಿರಳವಾಗಿ ಬದಲಾಗುವ, ಅಥವಾ ಗ್ರಾಹಕರು ಮರು-ರೆಂಡರ್ ಮಾಡಲು ಅಗ್ಗವಾಗಿರುವ ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗಳಿಗೆ, ಸಾಂಪ್ರದಾಯಿಕ `useContext` ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ನೇರವಾಗಿರುತ್ತದೆ. ಸ್ಪಷ್ಟವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕಾರಣವಿಲ್ಲದೆ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಹೆಚ್ಚು ಸಂಕೀರ್ಣಗೊಳಿಸಬೇಡಿ.
4. `cache` ಅನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದು: ರಿಯಾಕ್ಟ್‌ನ `cache` ಫಂಕ್ಷನ್ ಅದರ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಮೆಮೋಯಿಜ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಈ ಕ್ಯಾಶ್ ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ವಿನಂತಿಗಳ ನಡುವೆ ಅಥವಾ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಪೂರ್ಣ ಪುಟ ಮರುಲೋಡ್‌ನಲ್ಲಿ ತೆರವುಗೊಳಿಸಲಾಗುತ್ತದೆ. ಇದನ್ನು ವಿನಂತಿ-ಮಟ್ಟದ ಕ್ಯಾಶಿಂಗ್‌ಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ದೀರ್ಘಾವಧಿಯ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸ್ಟೇಟ್‌ಗಾಗಿ ಅಲ್ಲ. ಸಂಕೀರ್ಣ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಕ್ಯಾಶಿಂಗ್, ಅಮಾನ್ಯಗೊಳಿಸುವಿಕೆ, ಮತ್ತು ರೂಪಾಂತರಕ್ಕಾಗಿ, ಒಂದು ಮೀಸಲಾದ ಡೇಟಾ-ಫೆಚಿಂಗ್ ಲೈಬ್ರರಿಯು ಇನ್ನೂ ಬಹಳ ಪ್ರಬಲ ಆಯ್ಕೆಯಾಗಿದೆ.

ಉತ್ತಮ ಅಭ್ಯಾಸಗಳ ಪರಿಶೀಲನಾಪಟ್ಟಿ

• ✅ ಬೌಂಡರಿಗಳನ್ನು ಅಪ್ಪಿಕೊಳ್ಳಿ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸುಸ್ಥಾಪಿತ `<Suspense>` ಮತ್ತು `<ErrorBoundary>` ಕಾಂಪೊನೆಂಟ್‌ಗಳೊಂದಿಗೆ ರಚಿಸಿ. ಇಡೀ ಸಬ್‌ಟ್ರೀಗಳಿಗಾಗಿ ಲೋಡಿಂಗ್ ಮತ್ತು ಎರರ್ ಸ್ಟೇಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಅವುಗಳನ್ನು ಘೋಷಣಾತ್ಮಕ ಜಾಲಗಳೆಂದು ಯೋಚಿಸಿ.
• ✅ ಡೇಟಾ ಫೆಚಿಂಗ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ: ನಿಮ್ಮ ಕ್ಯಾಶ್ ಮಾಡಿದ ಡೇಟಾ-ಫೆಚಿಂಗ್ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ನೀವು ವ್ಯಾಖ್ಯಾನಿಸುವ `api.js` ಅಥವಾ ಅಂತಹುದೇ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರಚಿಸಿ. ಇದು ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಸ್ವಚ್ಛವಾಗಿಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಕ್ಯಾಶಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿಡುತ್ತದೆ.
• ✅ `use(Context)` ಅನ್ನು ಕಾರ್ಯತಂತ್ರವಾಗಿ ಬಳಸಿ: ಆಗಾಗ್ಗೆ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗೆ ಸಂವೇದನಾಶೀಲವಾಗಿರುವ ಆದರೆ ಡೇಟಾ ಷರತ್ತುಬದ್ಧವಾಗಿ ಮಾತ್ರ ಅಗತ್ಯವಿರುವ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಗುರುತಿಸಿ. ಇವು `useContext` ನಿಂದ `use` ಗೆ ಮರುರೂಪಿಸಲು ಪ್ರಮುಖ ಅಭ್ಯರ್ಥಿಗಳಾಗಿವೆ.
• ✅ ರಿಸೋರ್ಸ್‌ಗಳಲ್ಲಿ ಯೋಚಿಸಿ: ನಿಮ್ಮ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು ಸ್ಟೇಟ್ ನಿರ್ವಹಿಸುವುದರಿಂದ (`isLoading`, `data`, `error`) ರಿಸೋರ್ಸ್‌ಗಳನ್ನು ಬಳಸುವುದಕ್ಕೆ (ಪ್ರಾಮಿಸಸ್, ಕಾಂಟೆಕ್ಸ್ಟ್) ಬದಲಾಯಿಸಿ. ರಿಯಾಕ್ಟ್ ಮತ್ತು `use` ಹುಕ್ ಲೋಡಿಂಗ್ ಮತ್ತು ಎರರ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಸಂಕೀರ್ಣ ಸ್ಟೇಟ್ ಪರಿವರ್ತನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲಿ.
• ✅ ನಿಯಮಗಳನ್ನು ನೆನಪಿಡಿ (ಇತರ ಹುಕ್ಸ್‌ಗಳಿಗಾಗಿ): `use` ಹುಕ್ ಒಂದು ಅಪವಾದ. ಮೂಲ ಹುಕ್ಸ್ ನಿಯಮಗಳು `useState`, `useEffect`, `useMemo` ಇತ್ಯಾದಿಗಳಿಗೆ ಇನ್ನೂ ಅನ್ವಯಿಸುತ್ತವೆ. ಅವುಗಳನ್ನು `if` ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳ ಒಳಗೆ ಹಾಕುವುದನ್ನು ಪ್ರಾರಂಭಿಸಬೇಡಿ.

ಭವಿಷ್ಯವು `use` ಆಗಿದೆ: ಸರ್ವರ್ ಕಾಂಪೊನೆಂಟ್ಸ್ ಮತ್ತು ಅದರಾಚೆ

`use` ಹುಕ್ ಕೇವಲ ಒಂದು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಅನುಕೂಲವಲ್ಲ; ಇದು ರಿಯಾಕ್ಟ್ ಸರ್ವರ್ ಕಾಂಪೊನೆಂಟ್ಸ್ (RSCs) ನ ಒಂದು ಮೂಲಭೂತ ಆಧಾರಸ್ತಂಭವಾಗಿದೆ. ಒಂದು RSC ಪರಿಸರದಲ್ಲಿ, ಒಂದು ಕಾಂಪೊನೆಂಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳ್ಳಬಹುದು. ಅದು `use(fetch(...))` ಅನ್ನು ಕಾಲ್ ಮಾಡಿದಾಗ, ಸರ್ವರ್ ಆ ಕಾಂಪೊನೆಂಟ್‌ನ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಅಕ್ಷರಶಃ ವಿರಾಮಗೊಳಿಸಬಹುದು, ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆ ಅಥವಾ API ಕಾಲ್ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯಬಹುದು, ಮತ್ತು ನಂತರ ಡೇಟಾದೊಂದಿಗೆ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಪುನರಾರಂಭಿಸಬಹುದು, ಅಂತಿಮ HTML ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡಬಹುದು.

ಇದು ಒಂದು ತಡೆರಹಿತ ಮಾದರಿಯನ್ನು ರಚಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಡೇಟಾ ಫೆಚಿಂಗ್ ರೆಂಡರಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯ ಪ್ರಥಮ ದರ್ಜೆಯ ನಾಗರಿಕನಾಗಿರುತ್ತದೆ, ಸರ್ವರ್-ಸೈಡ್ ಡೇಟಾ ಮರುಪಡೆಯುವಿಕೆ ಮತ್ತು ಕ್ಲೈಂಟ್-ಸೈಡ್ UI ಸಂಯೋಜನೆಯ ನಡುವಿನ ಗಡಿಯನ್ನು ಅಳಿಸಿಹಾಕುತ್ತದೆ. ನಾವು ಮೊದಲು ಬರೆದ ಅದೇ `UserProfile` ಕಾಂಪೊನೆಂಟ್, ಕನಿಷ್ಠ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ, ಸರ್ವರ್‌ನಲ್ಲಿ ಚಲಿಸಬಹುದು, ಅದರ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು, ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ರೂಪುಗೊಂಡ HTML ಅನ್ನು ಬ್ರೌಸರ್‌ಗೆ ಕಳುಹಿಸಬಹುದು, ಇದು ವೇಗವಾದ ಆರಂಭಿಕ ಪುಟ ಲೋಡ್‌ಗಳು ಮತ್ತು ಉತ್ತಮ ಬಳಕೆದಾರ ಅನುಭವಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

`use` API ಸಹ ವಿಸ್ತರಿಸಬಲ್ಲದು. ಭವಿಷ್ಯದಲ್ಲಿ, ಇದನ್ನು ಅಬ್ಸರ್ವೇಬಲ್ಸ್ (ಉದಾ., RxJS ನಿಂದ) ಅಥವಾ ಇತರ ಕಸ್ಟಮ್ "thenable" ಆಬ್ಜೆಕ್ಟ್‌ಗಳಂತಹ ಇತರ ಅಸಿಂಕ್ರೋನಸ್ ಮೂಲಗಳಿಂದ ಮೌಲ್ಯಗಳನ್ನು ಅನ್‌ವ್ರ್ಯಾಪ್ ಮಾಡಲು ಬಳಸಬಹುದು, ರಿಯಾಕ್ಟ್ ಕಾಂಪೊನೆಂಟ್‌ಗಳು ಬಾಹ್ಯ ಡೇಟಾ ಮತ್ತು ಈವೆಂಟ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಎಂಬುದನ್ನು ಮತ್ತಷ್ಟು ಏಕೀಕರಿಸುತ್ತದೆ.

ತೀರ್ಮಾನ: ರಿಯಾಕ್ಟ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ನ ಹೊಸ ಯುಗ

`use` ಹುಕ್ ಕೇವಲ ಒಂದು ಹೊಸ API ಗಿಂತ ಹೆಚ್ಚಾಗಿದೆ; ಇದು ಸ್ವಚ್ಛ, ಹೆಚ್ಚು ಘೋಷಣಾತ್ಮಕ, ಮತ್ತು ಹೆಚ್ಚು ಕಾರ್ಯಕ್ಷಮತೆಯ ರಿಯಾಕ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬರೆಯಲು ಒಂದು ಆಹ್ವಾನವಾಗಿದೆ. ಅಸಿಂಕ್ರೋನಸ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್ ಬಳಕೆಯನ್ನು ನೇರವಾಗಿ ರೆಂಡರಿಂಗ್ ಹರಿವಿಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ಇದು ವರ್ಷಗಳಿಂದ ಸಂಕೀರ್ಣ ಮಾದರಿಗಳು ಮತ್ತು ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ ಅಗತ್ಯವಿದ್ದ ಸಮಸ್ಯೆಗಳನ್ನು ಸೊಗಸಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ.

ಪ್ರತಿಯೊಬ್ಬ ಜಾಗತಿಕ ಡೆವಲಪರ್‌ಗೆ ಪ್ರಮುಖ ಅಂಶಗಳು:

• ಪ್ರಾಮಿಸಸ್‌ಗಳಿಗಾಗಿ: `use` ಡೇಟಾ ಫೆಚಿಂಗ್ ಅನ್ನು ಅಪಾರವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಇದು ಒಂದು ದೃಢವಾದ ಕ್ಯಾಶಿಂಗ್ ತಂತ್ರ ಮತ್ತು ಸಸ್ಪೆನ್ಸ್ ಮತ್ತು ಎರರ್ ಬೌಂಡರಿಗಳ ಸರಿಯಾದ ಬಳಕೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುತ್ತದೆ.
• ಕಾಂಟೆಕ್ಸ್ಟ್‌ಗಾಗಿ: `use` ಷರತ್ತುಬದ್ಧ ಚಂದಾದಾರಿಕೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಕ ಶಕ್ತಿಯುತ ಕಾರ್ಯಕ್ಷಮತೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, `useContext` ಬಳಸುವ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕಾಡುವ ಅನಗತ್ಯ ಮರು-ರೆಂಡರ್‌ಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
• ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ: ಇದು ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ರಿಸೋರ್ಸ್‌ಗಳ ಗ್ರಾಹಕರೆಂದು ಯೋಚಿಸುವತ್ತ ಬದಲಾವಣೆಯನ್ನು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ, ರಿಯಾಕ್ಟ್ ಲೋಡಿಂಗ್ ಮತ್ತು ಎರರ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಸಂಕೀರ್ಣ ಸ್ಟೇಟ್ ಪರಿವರ್ತನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಬಿಡುತ್ತದೆ.

ನಾವು ರಿಯಾಕ್ಟ್ 19 ಮತ್ತು ಅದರಾಚೆಯ ಯುಗಕ್ಕೆ ಸಾಗುತ್ತಿರುವಾಗ, `use` ಹುಕ್‌ನಲ್ಲಿ ಪ್ರಾವೀಣ್ಯತೆ ಪಡೆಯುವುದು ಅತ್ಯಗತ್ಯವಾಗಿರುತ್ತದೆ. ಇದು ಡೈನಾಮಿಕ್ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಹೆಚ್ಚು ಸಹಜವಾದ ಮತ್ತು ಶಕ್ತಿಯುತವಾದ ಮಾರ್ಗವನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪೀಳಿಗೆಯ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡುತ್ತದೆ.

`use` ಹುಕ್ ಬಗ್ಗೆ ನಿಮ್ಮ ಅಭಿಪ್ರಾಯಗಳೇನು? ನೀವು ಅದರೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೀರಾ? ನಿಮ್ಮ ಅನುಭವಗಳು, ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಒಳನೋಟಗಳನ್ನು ಕೆಳಗಿನ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಿ!