Thư Viện Câu Hỏi Phỏng Vấn

computed() là cơ chế lazy evaluation, chỉ tính toán lại khi các dependency thay đổi và kết quả được cache. watch() là cơ chế thực thi side effects khi dữ liệu thay đổi. Trong Enterprise, ưu tiên dùng computed() cho các logic biến đổi dữ liệu để tận dụng caching, chỉ dùng watch() khi cần thực hiện các tác vụ bất đồng bộ hoặc tương tác với DOM/API bên ngoài.

Để an toàn với TypeScript, cần định nghĩa các InjectionKey. Điều này giúp định nghĩa kiểu dữ liệu của giá trị được inject ngay tại thời điểm compile, tránh lỗi runtime. Ví dụ: const UserKey: InjectionKey = Symbol(). Khi sử dụng, việc kiểm tra giá trị null/undefined là bắt buộc để đảm bảo ứng dụng không bị crash khi component cha chưa cung cấp giá trị.

defineModel giúp đơn giản hóa việc tạo two-way binding giữa component cha và con. Nó loại bỏ boilerplate code (props + emit update:modelValue). Nên sử dụng defineModel khi component con đóng vai trò là một input control hoặc một UI component cần đồng bộ state trực tiếp với cha. Điều này giúp code sạch hơn, dễ bảo trì hơn trong các hệ thống Design System phức tạp.

Server Components trong React 19 được thực thi hoàn toàn trên server trước khi gửi HTML về client. Điều này giúp giảm thiểu đáng kể JavaScript bundle size vì các thư viện nặng chỉ dùng ở server sẽ không được gửi xuống trình duyệt. Ngược lại, Client Components vẫn yêu cầu hydrate và thực thi trên trình duyệt. Sự khác biệt cốt lõi là Server Components không thể sử dụng các hooks như useState hay useEffect, nhưng có khả năng truy cập trực tiếp vào database hoặc file system. Khi truyền dữ liệu từ Server Component sang Client Component, dữ liệu đó phải được serialize thành JSON, do đó các hàm (functions) không thể truyền trực tiếp qua props.

Server Actions cho phép gọi trực tiếp các hàm phía server từ components mà không cần tạo các API endpoints trung gian. Về bảo mật, React 19 tự động tạo ra các secure tokens để ngăn chặn CSRF attacks. Thay vì viết fetch request thủ công, bạn chỉ cần đánh dấu hàm với 'use server'. Ví dụ: async function submitForm(formData) { 'use server'; await db.save(formData); }. Điều này giúp giảm boilerplate code, đảm bảo tính nhất quán giữa client và server, và cho phép thực hiện validation ngay tại server một cách tập trung.

Hook useOptimistic cho phép hiển thị trạng thái dự kiến của giao diện trước khi server phản hồi kết quả. Khi người dùng thực hiện hành động, bạn cập nhật trạng thái optimistic ngay lập tức. Nếu server trả về lỗi, React sẽ tự động revert về trạng thái trước đó. Ví dụ: const [optimisticState, addOptimistic] = useOptimistic(state, (currentState, newValue) => newValue);. Điều này tạo cảm giác ứng dụng phản hồi tức thì (instant feedback), giúp tăng trải nghiệm người dùng trong các hệ thống có độ trễ mạng cao.

Server Components giúp giảm thiểu số lượng component cần hydrate trên client. Khi một phần lớn giao diện được render ở server, trình duyệt không cần tải và thực thi code của các component đó, dẫn đến thời gian Time to Interactive (TTI) nhanh hơn. Ngoài ra, nó loại bỏ hiện tượng waterfall network requests vì các dữ liệu cần thiết đã được fetch trực tiếp tại server trước khi component được render, giúp tối ưu hóa băng thông và tài nguyên CPU trên phía client.

Server Actions nên được ưu tiên khi thực hiện các thao tác thay đổi dữ liệu (mutations) như tạo, cập nhật hoặc xóa dữ liệu trực tiếp từ form. Trong khi React Query/SWR mạnh mẽ trong việc caching và đồng bộ dữ liệu từ API endpoints, Server Actions đơn giản hóa luồng dữ liệu bằng cách loại bỏ nhu cầu quản lý các API route riêng biệt. Nếu ứng dụng của bạn dựa nhiều vào kiến trúc Server-Side Rendering (SSR) hoặc Next.js, Server Actions giúp code gọn gàng hơn và tận dụng được cơ chế revalidation tự động của framework.

Progressive Enhancement là khả năng ứng dụng vẫn hoạt động ngay cả khi JavaScript trên trình duyệt bị tắt hoặc chưa tải xong. Với Server Actions, bạn có thể sử dụng thẻ

Thách thức lớn nhất là việc duy trì kết nối với database hoặc các dịch vụ bên ngoài trong quá trình render. Vì Server Components render trên mỗi request, việc khởi tạo kết nối liên tục có thể gây quá tải. Cần sử dụng các kỹ thuật như connection pooling hoặc singleton pattern để tái sử dụng kết nối. Ngoài ra, cần cẩn trọng với việc truyền dữ liệu quá lớn từ server xuống client thông qua props, vì dữ liệu này sẽ được serialize và làm tăng kích thước payload, ảnh hưởng đến hiệu năng mạng.

Trong React 19, Server Actions có thể trả về các giá trị hoặc throw errors. Để xử lý, bạn nên sử dụng try-catch block bên trong Server Action và trả về một object chứa trạng thái lỗi. Ở phía client, bạn có thể sử dụng hook useActionState để theo dõi trạng thái của action (pending, data, error). Điều này giúp đồng bộ hóa thông báo lỗi từ server trực tiếp lên giao diện người dùng mà không cần thông qua các state management phức tạp.

useTransition dùng để đánh dấu các cập nhật state là không khẩn cấp (non-urgent), giúp giao diện không bị treo khi thực hiện các tác vụ nặng. Trong khi đó, useOptimistic tập trung vào việc hiển thị trạng thái tạm thời cho người dùng trong khi chờ đợi một tác vụ bất đồng bộ hoàn tất. Thông thường, bạn sẽ kết hợp cả hai: sử dụng useTransition để bắt đầu action và useOptimistic để cập nhật giao diện ngay lập tức trước khi action hoàn thành.

Lợi ích: Giảm thiểu sự phụ thuộc vào các thư viện client-side giữa các micro-apps, giúp cải thiện đáng kể tốc độ tải trang ban đầu. Rủi ro: Sự phức tạp trong việc chia sẻ context và state giữa các phần của ứng dụng nếu chúng được render từ các server khác nhau. Việc quản lý các shared components giữa các team cũng trở nên khó khăn hơn do sự khác biệt giữa Server và Client Components. Cần thiết lập một design system thống nhất và các contract chặt chẽ về dữ liệu giữa các micro-services để tránh lỗi runtime.

Khi triển khai Reverb trên môi trường Cluster, thách thức lớn nhất là đồng bộ hóa sự kiện giữa các Server Node. Để giải quyết, cần sử dụng Redis làm Pub/Sub backend cho Reverb. Cơ chế hoạt động: Khi một sự kiện được phát đi từ một Node, nó sẽ được đẩy vào Redis, sau đó Redis sẽ broadcast sự kiện đó đến tất cả các Node khác đang lắng nghe. Cấu hình cần thiết trong file .env: BROADCAST_CONNECTION=reverb và đảm bảo REDIS_CLIENT=phpredis để đạt hiệu suất cao nhất. Lưu ý: Cần cấu hình Load Balancer hỗ trợ Sticky Sessions nếu ứng dụng có sử dụng các tính năng liên quan đến stateful connection.

Laravel Reverb là một giải pháp WebSocket server được xây dựng trực tiếp trên nền tảng PHP (sử dụng Ratchet/ReactPHP), giúp loại bỏ sự phụ thuộc vào các dịch vụ bên thứ ba như Pusher. Ưu điểm: Giảm thiểu chi phí vận hành, độ trễ thấp hơn do không cần qua trung gian API của bên thứ ba, và khả năng tùy biến sâu vào core của ứng dụng. Tuy nhiên, Pusher cung cấp tính sẵn sàng cao (High Availability) và khả năng mở rộng tự động mà không cần quản lý hạ tầng. Trong hệ thống độ trễ thấp, Reverb chiếm ưu thế nhờ việc chạy nội bộ trong hạ tầng của bạn, giúp kiểm soát hoàn toàn luồng dữ liệu.