M

MLOG

Tiếng Việt

Hướng dẫn toàn diện về hook `use` mang tính cách mạng của React. Khám phá tác động của nó đối với việc xử lý Promises và Context, cùng phân tích sâu về tiêu thụ tài nguyên, hiệu suất và các phương pháp hay nhất cho lập trình viên toàn cầu.

Giải mã Hook `use` của React: Phân tích sâu về Promises, Context và Quản lý Tài nguyên

Hệ sinh thái của React đang trong trạng thái phát triển không ngừng, liên tục tinh chỉnh trải nghiệm của lập trình viên và đẩy xa các giới hạn của những gì có thể trên web. Từ classes đến Hooks, mỗi sự thay đổi lớn đều đã làm thay đổi cơ bản cách chúng ta xây dựng giao diện người dùng. Hôm nay, chúng ta đang đứng trước một sự chuyển đổi tương tự khác, được báo hiệu bởi một hàm trông có vẻ đơn giản một cách tinh vi: hook `use`.

Trong nhiều năm, các lập trình viên đã phải vật lộn với sự phức tạp của các hoạt động bất đồng bộ và quản lý trạng thái. Việc lấy dữ liệu thường có nghĩa là một mớ bòng bong của `useEffect`, `useState`, và các trạng thái loading/error. Việc sử dụng context, dù mạnh mẽ, lại đi kèm với một nhược điểm lớn về hiệu suất là kích hoạt re-render ở mọi consumer. Hook `use` là câu trả lời tinh tế của React cho những thách thức tồn tại đã lâu này.

Hướng dẫn toàn diện này được thiết kế cho đối tượng toàn cầu là các lập trình viên React chuyên nghiệp. Chúng ta sẽ đi sâu vào hook `use`, mổ xẻ cơ chế hoạt động của nó và khám phá hai trường hợp sử dụng ban đầu chính: "mở gói" Promises và đọc từ Context. Quan trọng hơn, chúng ta sẽ phân tích những tác động sâu sắc đối với việc tiêu thụ tài nguyên, hiệu suất và kiến trúc ứng dụng. Hãy sẵn sàng để suy nghĩ lại cách bạn xử lý logic bất đồng bộ và trạng thái trong các ứng dụng React của mình.

Một sự thay đổi cơ bản: Điều gì làm cho Hook `use` trở nên khác biệt?

Trước khi chúng ta đi sâu vào Promises và Context, điều quan trọng là phải hiểu tại sao `use` lại mang tính cách mạng đến vậy. Trong nhiều năm, các lập trình viên React đã hoạt động dưới Quy tắc của Hooks nghiêm ngặt:

Những quy tắc này tồn tại bởi vì các Hook truyền thống như `useState` và `useEffect` dựa vào một thứ tự gọi nhất quán trong mỗi lần render để duy trì trạng thái của chúng. Hook `use` phá vỡ tiền lệ này. Bạn có thể gọi `use` bên trong các câu lệnh điều kiện (`if`/`else`), vòng lặp (`for`/`map`), và thậm chí cả các câu lệnh `return` sớm.

Đây không chỉ là một sự điều chỉnh nhỏ; đó là một sự thay đổi mô hình. Nó cho phép một cách tiêu thụ tài nguyên linh hoạt và trực quan hơn, chuyển từ mô hình đăng ký tĩnh ở cấp cao nhất sang mô hình tiêu thụ động, theo yêu cầu. Mặc dù về mặt lý thuyết nó có thể hoạt động với nhiều loại tài nguyên khác nhau, việc triển khai ban đầu của nó tập trung vào hai trong số những điểm nhức nhối phổ biến nhất trong phát triển React: Promises và Context.

Khái niệm cốt lõi: "Mở gói" giá trị

Về cơ bản, hook `use` được thiết kế để "mở gói" (unwrap) một giá trị từ một tài nguyên. Hãy nghĩ về nó như thế này:

Hãy cùng khám phá chi tiết hai khả năng mạnh mẽ này.

Làm chủ các thao tác bất đồng bộ: `use` với Promises

Lấy dữ liệu (data fetching) là huyết mạch của các ứng dụng web hiện đại. Cách tiếp cận truyền thống trong React tuy hoạt động được nhưng thường dài dòng và dễ mắc phải các lỗi tinh vi.

Cách cũ: "Vũ điệu" của `useEffect` và `useState`

Hãy xem xét một component đơn giản lấy dữ liệu người dùng. Mẫu chuẩn trông giống như thế này:


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>Đang tải hồ sơ...</p>;
  }

  if (error) {
    return <p>Lỗi: {error.message}</p>;
  }

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

Đoạn mã này khá nhiều boilerplate. Chúng ta cần quản lý thủ công ba trạng thái riêng biệt (`user`, `isLoading`, `error`), và chúng ta phải cẩn thận về các điều kiện race (race conditions) và dọn dẹp bằng cách sử dụng một cờ báo đã mounted. Mặc dù các hook tùy chỉnh có thể trừu tượng hóa điều này, sự phức tạp cơ bản vẫn còn.

Cách mới: Sự bất đồng bộ thanh lịch với `use`

Hook `use`, kết hợp với React Suspense, đơn giản hóa đáng kể toàn bộ quá trình này. Nó cho phép chúng ta viết mã bất đồng bộ mà đọc như mã đồng bộ.

Đây là cách component tương tự có thể được viết với `use`:


// Bạn phải bọc component này trong <Suspense> và <ErrorBoundary>
import { use } from 'react';
import { fetchUser } from './api'; // Giả sử hàm này trả về một promise đã được cache

function UserProfile({ userId }) {
  // `use` sẽ tạm dừng component cho đến khi promise được giải quyết
  const user = use(fetchUser(userId));

  // Khi thực thi đến đây, promise đã được giải quyết và `user` có dữ liệu.
  // Không cần các trạng thái isLoading hay error trong chính component.
  return (
    <div>
      <h1>{user.name}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
}

Sự khác biệt thật đáng kinh ngạc. Các trạng thái loading và error đã biến mất khỏi logic component của chúng ta. Điều gì đang xảy ra phía sau?

  1. Khi `UserProfile` render lần đầu tiên, nó gọi `use(fetchUser(userId))`.
  2. Hàm `fetchUser` khởi tạo một yêu cầu mạng và trả về một Promise.
  3. Hook `use` nhận Promise đang chờ xử lý này và giao tiếp với trình renderer của React để tạm dừng việc render của component này.
  4. React đi lên cây component để tìm ranh giới `` gần nhất và hiển thị UI `fallback` của nó (ví dụ: một spinner).
  5. Khi Promise được giải quyết, React render lại `UserProfile`. Lần này, khi `use` được gọi với cùng một Promise, Promise đó đã có một giá trị đã được giải quyết. `use` trả về giá trị này.
  6. Việc render component tiếp tục, và hồ sơ người dùng được hiển thị.
  7. Nếu Promise bị từ chối, `use` sẽ ném lỗi. React bắt lỗi này và đi lên cây đến `` gần nhất để hiển thị một UI lỗi dự phòng.

Phân tích sâu về tiêu thụ tài nguyên: Yêu cầu bắt buộc về Caching

Sự đơn giản của `use(fetchUser(userId))` che giấu một chi tiết quan trọng: bạn không được tạo một Promise mới trên mỗi lần render. Nếu hàm `fetchUser` của chúng ta chỉ đơn giản là `() => fetch(...)`, và chúng ta gọi nó trực tiếp bên trong component, chúng ta sẽ tạo một yêu cầu mạng mới trên mỗi lần cố gắng render, dẫn đến một vòng lặp vô hạn. Component sẽ tạm dừng, promise sẽ giải quyết, React sẽ render lại, một promise mới sẽ được tạo ra, và nó sẽ lại tạm dừng.

Đây là khái niệm quản lý tài nguyên quan trọng nhất cần nắm vững khi sử dụng `use` với promises. Promise phải ổn định và được cache qua các lần re-render.

React cung cấp một hàm `cache` mới để giúp việc này. Hãy tạo một tiện ích lấy dữ liệu mạnh mẽ:


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

export const fetchUser = cache(async (userId) => {
  console.log(`Đang lấy dữ liệu cho người dùng: ${userId}`);
  const response = await fetch(`https://api.example.com/users/${userId}`);
  if (!response.ok) {
    throw new Error('Không thể lấy dữ liệu người dùng.');
  }
  return response.json();
});

Hàm `cache` từ React ghi nhớ (memoize) hàm bất đồng bộ. Khi `fetchUser(1)` được gọi, nó khởi tạo việc fetch và lưu trữ Promise kết quả. Nếu một component khác (hoặc cùng một component trong một lần render tiếp theo) gọi lại `fetchUser(1)` trong cùng một lượt render, `cache` sẽ trả về chính xác cùng một đối tượng Promise, ngăn chặn các yêu cầu mạng dư thừa. Điều này làm cho việc lấy dữ liệu trở nên lũy đẳng (idempotent) và an toàn để sử dụng với hook `use`.

Đây là một sự thay đổi cơ bản trong quản lý tài nguyên. Thay vì quản lý trạng thái fetch bên trong component, chúng ta quản lý tài nguyên (promise dữ liệu) bên ngoài nó, và component chỉ đơn giản là tiêu thụ nó.

Cách mạng hóa việc quản lý trạng thái: `use` với Context

React Context là một công cụ mạnh mẽ để tránh "prop drilling"—truyền props xuống qua nhiều lớp component. Tuy nhiên, việc triển khai truyền thống của nó có một nhược điểm lớn về hiệu suất.

Vấn đề nan giải của `useContext`

Hook `useContext` đăng ký một component vào một context. Điều này có nghĩa là bất cứ khi nào giá trị của context thay đổi, mọi component sử dụng `useContext` cho context đó sẽ re-render. Điều này đúng ngay cả khi component chỉ quan tâm đến một phần nhỏ, không thay đổi của giá trị context.

Hãy xem xét một `SessionContext` chứa cả thông tin người dùng và theme hiện tại:


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

// Component chỉ quan tâm đến người dùng
function WelcomeMessage() {
  const { user } = useContext(SessionContext);
  console.log('Rendering WelcomeMessage');
  return <p>Chào mừng, {user?.name}!</p>;
}

// Component chỉ quan tâm đến theme
function ThemeToggleButton() {
  const { theme, updateTheme } = useContext(SessionContext);
  console.log('Rendering ThemeToggleButton');
  return <button onClick={updateTheme}>Chuyển sang theme {theme === 'light' ? 'tối' : 'sáng'}</button>;
}

Trong kịch bản này, khi người dùng nhấp vào `ThemeToggleButton` và `updateTheme` được gọi, toàn bộ đối tượng giá trị `SessionContext` sẽ được thay thế. Điều này khiến cả `ThemeToggleButton` VÀ `WelcomeMessage` re-render, mặc dù đối tượng `user` không hề thay đổi. Trong một ứng dụng lớn với hàng trăm consumer của context, điều này có thể dẫn đến các vấn đề hiệu suất nghiêm trọng.

Sự xuất hiện của `use(Context)`: Tiêu thụ có điều kiện

Hook `use` cung cấp một giải pháp đột phá cho vấn đề này. Bởi vì nó có thể được gọi một cách có điều kiện, một component chỉ thiết lập một đăng ký với context nếu và khi nó thực sự đọc giá trị đó.

Hãy tái cấu trúc một component để minh họa sức mạnh này:


function UserSettings({ userId }) {
  const { user, theme } = useContext(SessionContext); // Cách truyền thống: luôn đăng ký

  // Hãy tưởng tượng chúng ta chỉ hiển thị cài đặt theme cho người dùng đang đăng nhập
  if (user?.id !== userId) {
    return <p>Bạn chỉ có thể xem cài đặt của riêng mình.</p>;
  }

  // Phần này chỉ chạy nếu ID người dùng khớp
  return <div>Theme hiện tại: {theme}</div>;
}

Với `useContext`, component `UserSettings` này sẽ re-render mỗi khi theme thay đổi, ngay cả khi `user.id !== userId` và thông tin theme không bao giờ được hiển thị. Việc đăng ký được thiết lập vô điều kiện ở cấp cao nhất.

Bây giờ, hãy xem phiên bản `use`:


import { use } from 'react';

function UserSettings({ userId }) {
  // Đọc thông tin người dùng trước. Giả sử phần này tốn ít chi phí hoặc cần thiết.
  const user = use(SessionContext).user;

  // Nếu điều kiện không được đáp ứng, chúng ta return sớm.
  // ĐIỀU QUAN TRỌNG là chúng ta chưa đọc theme.
  if (user?.id !== userId) {
    return <p>Bạn chỉ có thể xem cài đặt của riêng mình.</p>;
  }

  // CHỈ khi điều kiện được đáp ứng, chúng ta mới đọc theme từ context.
  // Việc đăng ký theo dõi thay đổi của context được thiết lập ở đây, một cách có điều kiện.
  const theme = use(SessionContext).theme;

  return <div>Theme hiện tại: {theme}</div>;
}

Đây là một yếu tố thay đổi cuộc chơi. Trong phiên bản này, nếu `user.id` không khớp với `userId`, component sẽ return sớm. Dòng `const theme = use(SessionContext).theme;` không bao giờ được thực thi. Do đó, instance của component này không đăng ký theo dõi `SessionContext`. Nếu theme được thay đổi ở nơi khác trong ứng dụng, component này sẽ không re-render một cách không cần thiết. Nó đã tự tối ưu hóa việc tiêu thụ tài nguyên của mình bằng cách đọc từ context một cách có điều kiện.

Phân tích tiêu thụ tài nguyên: Các mô hình đăng ký

Mô hình tư duy cho việc tiêu thụ context thay đổi đáng kể:

Sự kiểm soát chi tiết này đối với việc re-render là một công cụ mạnh mẽ để tối ưu hóa hiệu suất trong các ứng dụng quy mô lớn. Nó cho phép các lập trình viên xây dựng các component thực sự bị cô lập khỏi các cập nhật trạng thái không liên quan, dẫn đến giao diện người dùng hiệu quả và phản hồi nhanh hơn mà không cần dùng đến các mẫu memoization phức tạp (`React.memo`) hoặc state selector.

Sự giao thoa: `use` với Promises trong Context

Sức mạnh thực sự của `use` trở nên rõ ràng khi chúng ta kết hợp hai khái niệm này. Điều gì sẽ xảy ra nếu một context provider không cung cấp dữ liệu trực tiếp, mà là một promise cho dữ liệu đó? Mẫu này cực kỳ hữu ích để quản lý các nguồn dữ liệu trên toàn ứng dụng.


// DataContext.js
import { createContext } from 'react';
import { fetchSomeGlobalData } from './api'; // Trả về một promise đã được cache

// Context cung cấp một promise, không phải chính dữ liệu.
export const GlobalDataContext = createContext(fetchSomeGlobalData());

// App.js
function App() {
  return (
    <GlobalDataContext.Provider value={fetchSomeGlobalData()}>
      <Suspense fallback={<h1>Đang tải ứng dụng...</h1>}>
        <Dashboard />
      </Suspense>
    </GlobalDataContext.Provider>
  );
}

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

function Dashboard() {
  // Lệnh `use` đầu tiên đọc promise từ context.
  const dataPromise = use(GlobalDataContext);

  // Lệnh `use` thứ hai "mở gói" promise, tạm dừng nếu cần thiết.
  const globalData = use(dataPromise);

  // Một cách viết ngắn gọn hơn cho hai dòng trên:
  // const globalData = use(use(GlobalDataContext));

  return <h1>Chào mừng, {globalData.userName}!</h1>;
}

Hãy phân tích `const globalData = use(use(GlobalDataContext));`:

  1. `use(GlobalDataContext)`: Lệnh gọi bên trong thực thi trước. Nó đọc giá trị từ `GlobalDataContext`. Trong thiết lập của chúng ta, giá trị này là một promise được trả về bởi `fetchSomeGlobalData()`.
  2. `use(dataPromise)`: Lệnh gọi bên ngoài sau đó nhận promise này. Nó hoạt động chính xác như chúng ta đã thấy trong phần đầu tiên: nó tạm dừng component `Dashboard` nếu promise đang chờ xử lý, ném lỗi nếu nó bị từ chối, hoặc trả về dữ liệu đã được giải quyết.

Mẫu này đặc biệt mạnh mẽ. Nó tách rời logic lấy dữ liệu khỏi các component tiêu thụ dữ liệu, đồng thời tận dụng cơ chế Suspense tích hợp sẵn của React để có trải nghiệm tải liền mạch. Các component không cần biết dữ liệu được lấy *như thế nào* hoặc *khi nào*; chúng chỉ đơn giản yêu cầu nó, và React sẽ điều phối phần còn lại.

Hiệu suất, Cạm bẫy và Các phương pháp hay nhất

Giống như bất kỳ công cụ mạnh mẽ nào, hook `use` đòi hỏi sự hiểu biết và kỷ luật để được sử dụng một cách hiệu quả. Dưới đây là một số cân nhắc chính cho các ứng dụng sản phẩm.

Tóm tắt hiệu suất

Những cạm bẫy phổ biến cần tránh

  1. Promise không được cache: Sai lầm số một. Gọi `use(fetch(...))` trực tiếp trong một component sẽ gây ra một vòng lặp vô hạn. Luôn luôn sử dụng một cơ chế caching như `cache` của React hoặc các thư viện như SWR/React Query.
  2. Thiếu Boundaries: Sử dụng `use(Promise)` mà không có một `` boundary cha sẽ làm sập ứng dụng của bạn. Tương tự, một promise bị từ chối mà không có một `` cha cũng sẽ làm sập ứng dụng. Bạn phải thiết kế cây component của mình với những ranh giới này trong tâm trí.
  3. Tối ưu hóa sớm: Mặc dù `use(Context)` rất tốt cho hiệu suất, nó không phải lúc nào cũng cần thiết. Đối với các context đơn giản, thay đổi không thường xuyên, hoặc nơi các consumer rẻ để re-render, `useContext` truyền thống hoàn toàn ổn và đơn giản hơn một chút. Đừng làm phức tạp mã của bạn mà không có lý do hiệu suất rõ ràng.
  4. Hiểu sai về `cache`: Hàm `cache` của React ghi nhớ dựa trên các đối số của nó, nhưng cache này thường được xóa giữa các yêu cầu máy chủ hoặc khi tải lại toàn bộ trang trên client. Nó được thiết kế để caching ở cấp độ yêu cầu, không phải trạng thái phía client lâu dài. Đối với việc caching, vô hiệu hóa và biến đổi phức tạp phía client, một thư viện lấy dữ liệu chuyên dụng vẫn là một lựa chọn rất mạnh mẽ.

Danh sách kiểm tra các phương pháp hay nhất

Tương lai là `use`: Server Components và hơn thế nữa

Hook `use` không chỉ là một tiện ích phía client; nó là một trụ cột nền tảng của React Server Components (RSCs). Trong một môi trường RSC, một component có thể thực thi trên máy chủ. Khi nó gọi `use(fetch(...))`, máy chủ có thể tạm dừng việc render của component đó, chờ cho truy vấn cơ sở dữ liệu hoặc cuộc gọi API hoàn tất, và sau đó tiếp tục render với dữ liệu, truyền (stream) HTML cuối cùng đến client.

Điều này tạo ra một mô hình liền mạch nơi việc lấy dữ liệu là một công dân hạng nhất của quá trình render, xóa nhòa ranh giới giữa việc truy xuất dữ liệu phía máy chủ và việc soạn thảo UI phía client. Cùng một component `UserProfile` mà chúng ta đã viết trước đó có thể, với những thay đổi tối thiểu, chạy trên máy chủ, lấy dữ liệu của nó, và gửi HTML đã được định dạng đầy đủ đến trình duyệt, dẫn đến thời gian tải trang ban đầu nhanh hơn và trải nghiệm người dùng tốt hơn.

API `use` cũng có thể mở rộng. Trong tương lai, nó có thể được sử dụng để mở gói các giá trị từ các nguồn bất đồng bộ khác như Observables (ví dụ: từ RxJS) hoặc các đối tượng "thenable" tùy chỉnh khác, thống nhất hơn nữa cách các component React tương tác với dữ liệu và sự kiện bên ngoài.

Kết luận: Một kỷ nguyên mới của phát triển React

Hook `use` không chỉ là một API mới; nó là một lời mời để viết các ứng dụng React sạch sẽ hơn, khai báo hơn và hiệu quả hơn. Bằng cách tích hợp các hoạt động bất đồng bộ và tiêu thụ context trực tiếp vào luồng render, nó giải quyết một cách tinh tế các vấn đề đã đòi hỏi các mẫu phức tạp và boilerplate trong nhiều năm.

Những điểm chính cần rút ra cho mọi lập trình viên toàn cầu là:

Khi chúng ta bước vào kỷ nguyên của React 19 và xa hơn nữa, việc làm chủ hook `use` sẽ là điều cần thiết. Nó mở ra một cách trực quan và mạnh mẽ hơn để xây dựng các giao diện người dùng động, bắc cầu khoảng cách giữa client và server và mở đường cho thế hệ tiếp theo của các ứng dụng web.

Bạn nghĩ gì về hook `use`? Bạn đã bắt đầu thử nghiệm với nó chưa? Hãy chia sẻ kinh nghiệm, câu hỏi và những hiểu biết của bạn trong phần bình luận bên dưới!