Từ Đơn Giản Đến Phức Tạp: Hành Trình Yêu-Ghét Với Next.js

Khi nhớ lại ngày đầu tiên tôi bắt đầu sử dụng Next.js, tôi cảm thấy như mới hôm qua. Đó là phiên bản 8, và thành thật mà nói? Đó là tình yêu từ cái nhìn đầu tiên. Tôi đã khởi động một dự án mới bằng Next.js bất chấp sự do dự của CTO và khiến các đồng đội chưa viết một dòng code nào trong React học Next.js và tự tin triển khai sản phẩm.

Tại Sao Chọn Next.js?

Next.js mang đến nhiều tính năng nổi bật:

• Routing dựa trên file: Bạn chỉ cần đặt một file vào thư mục pages/ và ngay lập tức có một route.
• SSR, SSG, ISR: Các phương thức render mạnh mẽ giúp tối ưu hóa hiệu suất.
• Zero config: Không cần cấu hình phức tạp, chỉ cần tập trung vào việc lập trình.

Ví dụ về một component đơn giản trong Next.js:

// pages/about.js
export default function About() {
  return <div>Về chúng tôi</div>
}

Việc triển khai trở nên nhanh chóng và dễ dàng hơn rất nhiều so với cách sử dụng React truyền thống.

Sự Thay Đổi: Next.js 13 và Cuộc Khủng Hoảng App Router

Khi Next.js 13 ra mắt, mọi thứ bắt đầu thay đổi. Đột nhiên, thư mục pages/ trở nên tùy chọn. Xuất hiện thư mục app/, cùng với các tính năng như layouts, templates, routing lồng nhau và các React Server Components. Điều này khiến tôi cảm thấy như bị phản bội.

// app/layout.js
export default function Layout({ children }) {
  return <div className="layout">{children}</div>
}

Mô hình tư duy đã chuyển từ “Page = Route” sang “Segment = Route + Layout + Data Layer + Responsibility Split.” Bây giờ tôi phải suy nghĩ về các segment route và nơi dữ liệu nên được lưu trữ: component server, component client, cache fetch, và nhiều vấn đề phức tạp khác.

Mô Hình Tư Duy Mới Ai Cũng Nói Đến

Trước đây, tôi chỉ cần nghĩ:
“Tôi thêm một file, xong.”
Giờ đây, tôi phải hỏi:

• Đây là component server hay client?
• Việc fetch dữ liệu nên được thực hiện trong generateStaticParams hay ngay trong component?
• Layout này nên ở đâu?
• Đây là template hay layout?

Việc phát triển không chỉ đơn thuần là viết code nữa. Nó đã trở thành kiến trúc cho hệ sinh thái mới của Next.js.

// app/products/[id]/page.js
export default function ProductPage({ params }) {
  const { id } = params;
  // Tôi có nên fetch ở đây không? Đây có nên là một component server?
}

Tình Yêu, Nhưng Có Điều Kiện

Mặc dù tôi yêu sức mạnh mà Next.js mang lại, nhưng cũng có những điều cần lưu ý:

• Server Components: Đây là một tính năng cực kỳ mạnh mẽ.
• Layouts lồng nhau: Giúp mã nguồn trở nên sạch sẽ hơn.
• Tối ưu hóa hiệu suất: Cuối cùng cũng được tích hợp.

Nhưng… tôi cảm thấy nó đang trở nên quá phức tạp. Mỗi trường hợp sử dụng đơn giản giờ đây yêu cầu đọc ba RFC khác nhau. Liệu tôi có đang thực hiện “the Next Way™” hay chỉ đang tạo ra một giải pháp tạm thời có thể bị hỏng trong phiên bản tiếp theo?

Bạn Có Nên Quan Tâm?

Nếu bạn đang xây dựng các ứng dụng lớn, có khả năng mở rộng và rất chú trọng đến hiệu suất, câu trả lời là có. App Router của Next.js thực sự tuyệt vời khi bạn có thời gian để hiểu rõ nó.

Nếu bạn chỉ muốn triển khai nhanh chóng và đơn giản…
Hãy giữ lại pages/. Quên đi Server Components. Quên đi các layouts phức tạp. Sử dụng Next.js như một framework mà nó từng là.

Kết Luận

Next.js thực sự tuyệt vời khi được áp dụng quy mô lớn. Nhưng nó lại tệ khi bạn chỉ muốn sự đơn giản. Đó giống như việc yêu một chiếc dao Swiss Army, nhưng đôi khi bạn chỉ cần một cái tua vít đơn giản. Và giờ đây, chiếc tua vít lại có hàng tá phụ kiện mà bạn không cần đến.

Dù sao đi nữa, tôi vẫn tiếp tục sử dụng. Bởi vì tôi biết rằng phần thưởng sẽ xứng đáng… nếu tôi vượt qua được đường cong học tập.