M

MLOG

Tiếng Việt

Tìm hiểu sâu về giao thức React Flight. Khám phá cách định dạng tuần tự hóa này cho phép React Server Components (RSC), streaming, và tương lai của UI điều khiển bởi server.

Giải mã React Flight: Giao thức tuần tự hóa nền tảng của Server Components

Thế giới phát triển web đang trong trạng thái không ngừng phát triển. Trong nhiều năm, mô hình phổ biến là Ứng dụng Trang đơn (SPA), nơi một lớp vỏ HTML tối thiểu được gửi đến máy khách, sau đó máy khách sẽ tìm nạp dữ liệu và hiển thị toàn bộ giao diện người dùng bằng JavaScript. Mặc dù mạnh mẽ, mô hình này đã gây ra những thách thức như kích thước gói (bundle) lớn, các chuỗi yêu cầu dữ liệu máy khách-máy chủ (waterfalls), và quản lý trạng thái phức tạp. Để đối phó, cộng đồng đang chứng kiến một sự chuyển dịch đáng kể trở lại các kiến trúc lấy máy chủ làm trung tâm, nhưng với một sự thay đổi hiện đại. Đi đầu trong sự phát triển này là một tính năng đột phá từ đội ngũ React: React Server Components (RSC).

Nhưng làm thế nào mà các component này, vốn chỉ chạy trên máy chủ, lại có thể xuất hiện và tích hợp một cách liền mạch vào một ứng dụng phía máy khách? Câu trả lời nằm ở một công nghệ ít được biết đến nhưng cực kỳ quan trọng: React Flight. Đây không phải là một API mà bạn sẽ sử dụng trực tiếp hàng ngày, nhưng việc hiểu nó là chìa khóa để khai phá toàn bộ tiềm năng của hệ sinh thái React hiện đại. Bài viết này sẽ đưa bạn đi sâu vào giao thức React Flight, giải mã cỗ máy cung cấp năng lượng cho thế hệ ứng dụng web tiếp theo.

React Server Components là gì? Ôn tập nhanh

Trước khi chúng ta phân tích giao thức, hãy cùng tóm tắt nhanh React Server Components là gì và tại sao chúng lại quan trọng. Khác với các component React truyền thống chạy trong trình duyệt, RSC là một loại component mới được thiết kế để thực thi độc quyền trên máy chủ. Chúng không bao giờ gửi mã JavaScript của mình đến máy khách.

Việc thực thi chỉ trên máy chủ này mang lại một số lợi ích đột phá:

Điều quan trọng là phải phân biệt RSC với Server-Side Rendering (SSR). SSR tiền-render toàn bộ ứng dụng React của bạn thành một chuỗi HTML trên máy chủ. Máy khách nhận HTML này, hiển thị nó, sau đó tải xuống toàn bộ gói JavaScript để 'hydrate' trang và làm cho nó tương tác. Ngược lại, RSC render ra một mô tả trừu tượng đặc biệt của UI—không phải HTML—sau đó được truyền phát (stream) đến máy khách và hòa giải với cây component hiện có. Điều này cho phép một quá trình cập nhật chi tiết và hiệu quả hơn nhiều.

Giới thiệu React Flight: Giao thức cốt lõi

Vậy, nếu một Server Component không gửi HTML hay JavaScript của chính nó, thì nó đang gửi gì? Đây là lúc React Flight xuất hiện. React Flight là một giao thức tuần tự hóa được xây dựng có mục đích, được thiết kế để truyền tải một cây component React đã được render từ máy chủ đến máy khách.

Hãy coi nó như một phiên bản chuyên biệt, có thể truyền phát của JSON mà hiểu được các nguyên mẫu (primitives) của React. Nó là 'định dạng truyền tải' (wire format) bắc cầu giữa môi trường máy chủ của bạn và trình duyệt của người dùng. Khi bạn render một RSC, React không tạo ra HTML. Thay vào đó, nó tạo ra một luồng dữ liệu theo định dạng React Flight.

Tại sao không chỉ sử dụng HTML hoặc JSON?

Một câu hỏi tự nhiên là, tại sao phải phát minh ra một giao thức hoàn toàn mới? Tại sao chúng ta không thể sử dụng các tiêu chuẩn hiện có?

React Flight được tạo ra để giải quyết những vấn đề cụ thể này. Nó được thiết kế để:

  1. Có thể tuần tự hóa (Serializable): Có khả năng biểu diễn toàn bộ cây component, bao gồm cả props và trạng thái.
  2. Có thể truyền phát (Streamable): Giao diện người dùng có thể được gửi theo từng phần (chunk), cho phép máy khách bắt đầu render trước khi có phản hồi đầy đủ. Điều này là nền tảng cho việc tích hợp với Suspense.
  3. Hiểu về React (React-Aware): Nó có hỗ trợ hạng nhất cho các khái niệm của React như components, context, và tải chậm mã phía máy khách (lazy-loading).

React Flight hoạt động như thế nào: Phân tích từng bước

Quá trình sử dụng React Flight bao gồm một sự phối hợp nhịp nhàng giữa máy chủ và máy khách. Hãy cùng xem qua vòng đời của một yêu cầu trong một ứng dụng sử dụng RSC.

Trên máy chủ

  1. Khởi tạo yêu cầu: Một người dùng điều hướng đến một trang trong ứng dụng của bạn (ví dụ: một trang App Router của Next.js).
  2. Render Component: React bắt đầu render cây Server Component cho trang đó.
  3. Tìm nạp dữ liệu: Khi duyệt qua cây, nó gặp các component tìm nạp dữ liệu (ví dụ: `async function MyServerComponent() { ... }`). Nó chờ đợi các quá trình tìm nạp dữ liệu này.
  4. Tuần tự hóa thành luồng Flight: Thay vì tạo ra HTML, renderer của React tạo ra một luồng văn bản. Văn bản này là payload của React Flight. Mỗi phần của cây component—một `div`, một `p`, một chuỗi văn bản, một tham chiếu đến một Client Component—được mã hóa thành một định dạng cụ thể trong luồng này.
  5. Truyền phát phản hồi: Máy chủ không đợi toàn bộ cây được render xong. Ngay khi các phần đầu tiên của UI sẵn sàng, nó bắt đầu truyền phát payload Flight đến máy khách qua HTTP. Nếu gặp một ranh giới Suspense, nó sẽ gửi một placeholder và tiếp tục render nội dung bị tạm ngưng ở chế độ nền, gửi nó sau trong cùng một luồng khi nó sẵn sàng.

Trên máy khách

  1. Nhận luồng: Runtime của React trong trình duyệt nhận luồng Flight. Nó không phải là một tài liệu duy nhất mà là một dòng chảy liên tục của các chỉ thị.
  2. Phân tích và hòa giải (Parsing and Reconciliation): Mã React phía máy khách phân tích luồng Flight từng phần một. Giống như việc nhận một bộ bản thiết kế để xây dựng hoặc cập nhật UI.
  3. Tái tạo cây: Đối với mỗi chỉ thị, React cập nhật DOM ảo của nó. Nó có thể tạo một `div` mới, chèn một số văn bản, hoặc—quan trọng nhất—xác định một placeholder cho một Client Component.
  4. Tải Client Components: Khi luồng chứa một tham chiếu đến một Client Component (được đánh dấu bằng chỉ thị "use client"), payload Flight bao gồm thông tin về gói JavaScript nào cần tải xuống. React sau đó tìm nạp gói đó nếu nó chưa được lưu vào bộ nhớ đệm.
  5. Hydration và tính tương tác: Khi mã của Client Component được tải, React render nó vào vị trí được chỉ định và hydrate nó, gắn các trình lắng nghe sự kiện và làm cho nó hoàn toàn tương tác. Quá trình này được nhắm mục tiêu cao và chỉ xảy ra đối với các phần tương tác của trang.

Mô hình streaming và selective hydration này hiệu quả hơn rất nhiều so với mô hình SSR truyền thống, vốn thường yêu cầu quá trình hydration "tất cả hoặc không gì cả" cho toàn bộ trang.

Cấu trúc của một Payload React Flight

Để thực sự hiểu về React Flight, việc xem xét định dạng dữ liệu mà nó tạo ra sẽ rất hữu ích. Mặc dù bạn thường sẽ không tương tác trực tiếp với đầu ra thô này, việc nhìn thấy cấu trúc của nó sẽ tiết lộ cách nó hoạt động. Payload là một luồng các chuỗi giống JSON được phân tách bằng dòng mới. Mỗi dòng, hoặc chunk, đại diện cho một mẩu thông tin.

Hãy xem xét một ví dụ đơn giản. Tưởng tượng chúng ta có một Server Component như thế này:

app/page.js (Server Component)

<!-- Giả sử đây là một khối mã trong blog thật --> async function Page() { const userData = await fetchUser(); // Fetches { name: 'Alice' } return ( <div> <h1>Welcome, {userData.name}</h1> <p>Here is your dashboard.</p> <InteractiveButton text="Click Me" /> </div> ); }

Và một Client Component:

components/InteractiveButton.js (Client Component)

<!-- Giả sử đây là một khối mã trong blog thật --> 'use client'; import { useState } from 'react'; export default function InteractiveButton({ text }) { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> {text} ({count}) </button> ); }

Luồng React Flight được gửi từ máy chủ đến máy khách cho UI này có thể trông giống như sau (được đơn giản hóa để rõ ràng):

<!-- Ví dụ đơn giản hóa của một luồng Flight --> M1:{"id":"./components/InteractiveButton.js","chunks":["chunk-abcde.js"],"name":"default"} J0:["$","div",null,{"children":[["$","h1",null,{"children":["Welcome, ","Alice"]}],["$","p",null,{"children":"Here is your dashboard."}],["$","@1",null,{"text":"Click Me"}]]}]

Hãy cùng phân tích đầu ra khó hiểu này:

Payload này là một bộ chỉ thị hoàn chỉnh. Nó cho máy khách biết chính xác cách xây dựng UI, nội dung tĩnh nào cần hiển thị, nơi đặt các component tương tác, cách tải mã của chúng, và props nào cần truyền cho chúng. Tất cả điều này được thực hiện trong một định dạng nhỏ gọn, có thể truyền phát.

Những ưu điểm chính của giao thức React Flight

Thiết kế của giao thức Flight trực tiếp cho phép các lợi ích cốt lõi của mô hình RSC. Hiểu được giao thức làm rõ lý do tại sao những lợi thế này là khả thi.

Streaming và Suspense tích hợp

Bởi vì giao thức là một luồng được phân tách bằng dòng mới, máy chủ có thể gửi UI ngay khi nó đang được render. Nếu một component bị tạm ngưng (ví dụ, đang chờ dữ liệu), máy chủ có thể gửi một chỉ thị placeholder trong luồng, gửi phần còn lại của UI của trang, và sau đó, khi dữ liệu sẵn sàng, gửi một chỉ thị mới trong cùng luồng để thay thế placeholder bằng nội dung thực tế. Điều này cung cấp một trải nghiệm streaming hạng nhất mà không cần logic phức tạp phía máy khách.

Kích thước gói bằng không cho logic máy chủ

Nhìn vào payload, bạn có thể thấy rằng không có mã nào từ chính component `Page` hiện diện. Logic tìm nạp dữ liệu, bất kỳ tính toán nghiệp vụ phức tạp nào, hoặc các phụ thuộc như thư viện lớn chỉ được sử dụng trên máy chủ, đều hoàn toàn không có. Luồng chỉ chứa *đầu ra* của logic đó. Đây là cơ chế cơ bản đằng sau lời hứa "kích thước gói bằng không" của RSC.

Đồng vị trí (Colocation) của việc tìm nạp dữ liệu

Việc tìm nạp `userData` xảy ra trên máy chủ, và chỉ có kết quả của nó (`'Alice'`) được tuần tự hóa vào luồng. Điều này cho phép các nhà phát triển viết mã tìm nạp dữ liệu ngay bên trong component cần nó, một khái niệm được gọi là đồng vị trí (colocation). Mô hình này đơn giản hóa mã, cải thiện khả năng bảo trì và loại bỏ các chuỗi yêu cầu máy khách-máy chủ gây khó khăn cho nhiều SPA.

Hydration chọn lọc (Selective Hydration)

Sự phân biệt rõ ràng của giao thức giữa các phần tử HTML đã render và các tham chiếu Client Component (`@`) là điều cho phép hydration chọn lọc. Runtime của React phía máy khách biết rằng chỉ các component `@` mới cần JavaScript tương ứng của chúng để trở nên tương tác. Nó có thể bỏ qua các phần tĩnh của cây, tiết kiệm tài nguyên tính toán đáng kể khi tải trang ban đầu.

React Flight so với các giải pháp thay thế: Một góc nhìn tổng quan

Để đánh giá cao sự đổi mới của React Flight, việc so sánh nó với các phương pháp khác được sử dụng trong cộng đồng phát triển web toàn cầu là rất hữu ích.

so với SSR + Hydration truyền thống

Như đã đề cập, SSR truyền thống gửi một tài liệu HTML đầy đủ. Máy khách sau đó tải xuống một gói JavaScript lớn và "hydrate" toàn bộ tài liệu, gắn các trình lắng nghe sự kiện vào HTML tĩnh. Điều này có thể chậm và dễ vỡ. Một lỗi duy nhất có thể ngăn toàn bộ trang trở nên tương tác. Bản chất có thể truyền phát và chọn lọc của React Flight là một sự tiến hóa bền bỉ và hiệu năng hơn của khái niệm này.

so với API GraphQL/REST

Một điểm nhầm lẫn phổ biến là liệu RSC có thay thế các API dữ liệu như GraphQL hoặc REST hay không. Câu trả lời là không; chúng bổ sung cho nhau. React Flight là một giao thức để tuần tự hóa một cây UI, không phải là một ngôn ngữ truy vấn dữ liệu đa năng. Thực tế, một Server Component thường sẽ sử dụng GraphQL hoặc một API REST trên máy chủ để tìm nạp dữ liệu trước khi render. Sự khác biệt chính là cuộc gọi API này xảy ra từ máy chủ đến máy chủ, thường nhanh hơn và an toàn hơn nhiều so với cuộc gọi từ máy khách đến máy chủ. Máy khách nhận được UI cuối cùng thông qua luồng Flight, chứ không phải dữ liệu thô.

so với các Framework hiện đại khác

Các framework khác trong hệ sinh thái toàn cầu cũng đang giải quyết sự phân chia máy chủ-máy khách. Ví dụ:

Hàm ý thực tiễn và các phương pháp hay nhất cho nhà phát triển

Mặc dù bạn sẽ không viết payload React Flight bằng tay, việc hiểu giao thức sẽ cung cấp thông tin về cách bạn nên xây dựng các ứng dụng React hiện đại.

Nắm vững `"use server"` và `"use client"`

Trong các framework như Next.js, chỉ thị `"use client"` là công cụ chính của bạn để kiểm soát ranh giới giữa máy chủ và máy khách. Đó là tín hiệu cho hệ thống xây dựng rằng một component và các con của nó nên được coi là một hòn đảo tương tác. Mã của nó sẽ được đóng gói và gửi đến trình duyệt, và React Flight sẽ tuần tự hóa một tham chiếu đến nó. Ngược lại, việc không có chỉ thị này (hoặc sử dụng `"use server"` cho các server actions) giữ các component ở lại máy chủ. Hãy làm chủ ranh giới này để xây dựng các ứng dụng hiệu quả.

Suy nghĩ theo Components, không phải Endpoints

Với RSC, chính component có thể là nơi chứa dữ liệu. Thay vì tạo một API endpoint `/api/user` và một component phía máy khách tìm nạp từ nó, bạn có thể tạo một Server Component duy nhất `` tự tìm nạp dữ liệu bên trong. Điều này đơn giản hóa kiến trúc và khuyến khích các nhà phát triển suy nghĩ về UI và dữ liệu của nó như một đơn vị duy nhất, gắn kết.

Bảo mật là mối quan tâm phía máy chủ

Bởi vì RSC là mã máy chủ, chúng có các đặc quyền của máy chủ. Điều này rất mạnh mẽ nhưng đòi hỏi một cách tiếp cận kỷ luật về bảo mật. Tất cả việc truy cập dữ liệu, sử dụng biến môi trường, và tương tác với các dịch vụ nội bộ đều diễn ra ở đây. Hãy đối xử với mã này với sự nghiêm ngặt tương tự như bất kỳ API backend nào: làm sạch tất cả đầu vào, sử dụng các câu lệnh đã chuẩn bị sẵn cho các truy vấn cơ sở dữ liệu, và không bao giờ để lộ các khóa hoặc bí mật nhạy cảm có thể bị tuần tự hóa vào payload Flight.

Gỡ lỗi trong ngăn xếp mới

Việc gỡ lỗi thay đổi trong thế giới RSC. Một lỗi UI có thể bắt nguồn từ logic render phía máy chủ hoặc hydration phía máy khách. Bạn sẽ cần phải thoải mái kiểm tra cả log máy chủ (cho RSC) và console của nhà phát triển trong trình duyệt (cho Client Components). Tab Network cũng quan trọng hơn bao giờ hết. Bạn có thể kiểm tra luồng phản hồi Flight thô để xem chính xác những gì máy chủ đang gửi cho máy khách, điều này có thể vô giá để khắc phục sự cố.

Tương lai của phát triển Web với React Flight

React Flight và kiến trúc Server Components mà nó cho phép đại diện cho một sự suy nghĩ lại cơ bản về cách chúng ta xây dựng cho web. Mô hình này kết hợp những gì tốt nhất của cả hai thế giới: trải nghiệm phát triển đơn giản, mạnh mẽ của việc phát triển UI dựa trên component và hiệu năng, bảo mật của các ứng dụng render trên máy chủ truyền thống.

Khi công nghệ này trưởng thành, chúng ta có thể mong đợi thấy nhiều mô hình mạnh mẽ hơn nữa xuất hiện. Server Actions, cho phép các client components gọi các hàm an toàn trên máy chủ, là một ví dụ điển hình của một tính năng được xây dựng trên kênh giao tiếp máy chủ-máy khách này. Giao thức này có thể mở rộng, có nghĩa là đội ngũ React có thể thêm các khả năng mới trong tương lai mà không phá vỡ mô hình cốt lõi.

Kết luận

React Flight là xương sống vô hình nhưng không thể thiếu của mô hình React Server Components. Nó là một giao thức chuyên biệt cao, hiệu quả và có thể truyền phát, giúp dịch một cây component được render trên máy chủ thành một bộ chỉ thị mà một ứng dụng React phía máy khách có thể hiểu và sử dụng để xây dựng một giao diện người dùng phong phú, tương tác. Bằng cách chuyển các component và các phụ thuộc đắt đỏ của chúng ra khỏi máy khách và lên máy chủ, nó cho phép các ứng dụng web nhanh hơn, nhẹ hơn và mạnh mẽ hơn.

Đối với các nhà phát triển trên toàn thế giới, việc hiểu React Flight là gì và nó hoạt động như thế nào không chỉ là một bài tập học thuật. Nó cung cấp một mô hình tư duy quan trọng để kiến trúc các ứng dụng, đưa ra các đánh đổi về hiệu năng, và gỡ lỗi các vấn đề trong kỷ nguyên mới của UI điều khiển bởi máy chủ. Sự thay đổi đang diễn ra, và React Flight là giao thức đang mở đường phía trước.