Có gì mới trong Next.js 13?

[theanh]

Tháng 10 đã đến và đi, và cùng với đó, Next.js đã phát hành một phiên bản chính mới được đóng gói (ý định chơi chữ) với hàng loạt tính năng mới — một số trong số đó có thể được áp dụng liền mạch từ ứng dụng Next.js 12 của bạn, trong khi một số khác thì không.

Nếu bạn chỉ mới tham gia, có thể bạn sẽ bối rối khi phân biệt giữa sự cường điệu, thông tin sai lệch và thông tin ổn định cho ứng dụng sản xuất của mình, nhưng đừng lo! Tôi ở đây để cung cấp cho bạn một bản tổng quan hay và giúp bạn bắt kịp.

Thông tin sai lệch nào?​

Cũng như tất cả các bản phát hành Next.js, có một số API được chuyển vào lõi ổn định và để sử dụng theo khuyến nghị, và một số API khác vẫn đang trong kênh thử nghiệm. Các API "thử nghiệm" vẫn đang được tranh luận. Chức năng chính vẫn còn đó, nhưng câu hỏi về cách các API này hoạt động và cách chúng có thể được sử dụng vẫn có thể thay đổi vì có thể có lỗi hoặc tác dụng phụ không mong muốn.

Trong phiên bản 13, các bản phát hành thử nghiệm rất lớn và chiếm hết sự chú ý. Điều này khiến nhiều người coi toàn bộ bản phát hành là không ổn định và mang tính thử nghiệm — nhưng không phải vậy. Next.js 13 thực sự khá ổn định và cho phép nâng cấp mượt mà từ phiên bản 12 nếu bạn không có ý định áp dụng bất kỳ API thử nghiệm nào. Hầu hết các thay đổi có thể được áp dụng dần dần, chúng tôi sẽ đi sâu vào chi tiết hơn trong bài đăng này.

Tóm tắt các bản phát hành​

Trước khi đi sâu hơn vào từng thông báo, chúng ta hãy kiểm tra danh sách nhanh và cân bằng các thử nghiệm và tính năng ổn định.

Thử nghiệm​

• Thư mục ứng dụng;
• Trình đóng gói mới (Turbopack);
• Tối ưu hóa phông chữ.

Ổn định​

• Thành phần hình ảnh "Mới" để thay thế thành phần Hình ảnh cũ theo mặc định;
• Hỗ trợ mô-đun ES cho next.config.mjs;
• Thành phần Liên kết "Mới".

Thư mục ứng dụng​

Tính năng này thực chất là một bản viết lại kiến trúc lớn. Nó đặt React Server Components lên hàng đầu và trung tâm, tận dụng toàn bộ hệ thống định tuyến và các móc định tuyến mới (trong next/navigation thay vì next/router) và đảo ngược toàn bộ câu chuyện tìm nạp dữ liệu.

Tất cả những điều này nhằm mục đích cho phép cải thiện hiệu suất lớn, chẳng hạn như hiển thị nhanh từng phần của chế độ xem không phụ thuộc vào dữ liệu trong khi tạm dừng (bạn đọc đúng rồi đấy!) các phần đang tìm nạp dữ liệu và được hiển thị trên máy chủ.

Do đó, điều này cũng mang lại sự thay đổi lớn về mô hình tinh thần đối với cách bạn thiết kế ứng dụng Next.js của mình.

Hãy so sánh mọi thứ đã diễn ra như thế nào so với cách chúng sẽ hoạt động trong thư mục App. Khi sử dụng thư mục /pages (kiến trúc mà chúng ta đã sử dụng cho đến nay), dữ liệu được lấy từ cấp độ trang và được chuyển xuống các thành phần lá.



Ngược lại, vì thư mục ứng dụng được cung cấp bởi Server Components, mỗi thành phần chịu trách nhiệm về dữ liệu riêng của nó, nghĩa là giờ đây bạn có thể lấy-rồi-kết xuất từng thành phần bạn cần và lưu trữ đệm từng thành phần riêng lẻ, thực hiện Tái tạo tĩnh gia tăng (ISR) ở mức chi tiết hơn nhiều.



Ngoài ra, Next.js sẽ tiếp tục tối ưu hóa: Các yêu cầu sẽ được loại bỏ trùng lặp (không cho phép các thành phần khác nhau gửi cùng một yêu cầu song song), nhờ vào sự thay đổi trong cách thức hoạt động của phương thức thời gian chạy fetch với bộ nhớ đệm. Theo mặc định, tất cả các yêu cầu sẽ sử dụng thuật toán tìm kiếm bộ nhớ đệm mạnh (“force-cache”), có thể được chọn không tham gia thông qua cấu hình.

Bạn đọc đúng rồi đấy. Next.js và React Server Components đều can thiệp vào tiêu chuẩn fetch để cung cấp khả năng tối ưu hóa việc truy xuất tài nguyên.

Bạn không cần phải "tất tay"​

Điều quan trọng cần lưu ý là quá trình chuyển đổi từ kiến trúc /pages sang /app có thể được thực hiện từng bước và cả hai giải pháp có thể cùng tồn tại miễn là các tuyến đường không chồng chéo. Hiện tại, không đề cập đến việc ngừng hỗ trợ cho /pages trong lộ trình của Next.js.

Đọc thêm: ISR so với DPR: Những từ ngữ to tát, Giải thích nhanh của Cassidy Williams

New Bundler And Benchmarks​

Kể từ lần phát hành đầu tiên, Next.js đã sử dụng webpack. Năm nay, chúng ta đã chứng kiến một thế hệ bundler mới, được viết bằng các ngôn ngữ cấp thấp, xuất hiện, chẳng hạn như ESBuild (cung cấp năng lượng cho Vite), Parcel 2 (Rust) và các bundler khác. Chúng tôi cũng đã theo dõi Vercel tạo tiền đề cho một thay đổi lớn trong Next.js. Trong phiên bản 12, họ đã thêm SWC vào quy trình xây dựng và biên dịch của họ như một bước để thay thế cả Babel và Terser.

Trong phiên bản 13, họ đã công bố Turbopack, một bundler mới được viết bằng Rust với tuyên bố về hiệu suất rất táo bạo. Đúng vậy, đã có tranh cãi trên Twitter về bundler nào là nhanh nhất nói chung và cách đo lường các điểm chuẩn đó. Tuy nhiên, vẫn không thể bàn cãi về việc Turbopack thực sự có thể giúp các dự án lớn được viết bằng Next.js tốt hơn nhiều so với bất kỳ công cụ nào khác (đối với người mới bắt đầu, với cấu hình tích hợp).

Tính năng này không chỉ mang tính thử nghiệm mà thực tế chỉ hoạt động với next dev. Bạn không nên (và hiện tại không thể) sử dụng nó cho bản dựng sản xuất.

Tối ưu hóa phông chữ​

Mô-đun @next/font mới cho phép tối ưu hóa hiệu suất cho Phông chữ web của bạn trong thời gian dựng. Nó sẽ tải xuống các tài sản phông chữ trong thời gian dựng và lưu trữ chúng trong thư mục /public của riêng bạn. Điều này sẽ tiết kiệm được một chuyến đi khứ hồi đến một máy chủ khác, tránh một lần bắt tay bổ sung và cuối cùng là phân phối phông chữ của bạn theo cách nhanh nhất có thể và lưu trữ đệm đúng cách với các tài nguyên còn lại của bạn.

Hãy nhớ rằng khi sử dụng gói này, điều quan trọng là phải có kết nối internet đang hoạt động khi bạn chạy bản dựng phát triển của mình lần đầu tiên để nó có thể lưu trữ đệm đúng cách, nếu không, nó sẽ chuyển sang phông chữ hệ thống nếu adjustFontFallback không được đặt.

Ngoài ra, @next/font có một mô-đun đặc biệt cho Phông chữ web của Google, có sẵn thuận tiện vì chúng được sử dụng rộng rãi:

import { Jost } from '@next/font/google';// lấy một đối tượng có kiểu phông chữ:const jost = Jost();// định nghĩa chúng trong thành phần của bạn:

Mô-đun này cũng sẽ hoạt động trong trường hợp bạn sử dụng phông chữ tùy chỉnh:

import localFont from '@next/font/local';

const myFont = localFont({ src: './my-font.woff2' });

Mặc dù tính năng này vẫn đang trong giai đoạn Beta, nhưng nó được coi là đủ ổn định để bạn sử dụng trong sản xuất.

Thành phần hình ảnh và liên kết mới​

Có thể nói rằng các thành phần quan trọng nhất trong gói Next.js đã được đại tu một chút. Image tiếp theo đã có cuộc sống kép kể từ Next.js 12 trong @next/image và @next/future/image. Trong Next.js 13, thành phần mặc định được chuyển đổi:

• next/image chuyển đến next/legacy/image;
• next/future/image chuyển đến next/image.

Thay đổi này đi kèm với codemod, một lệnh cố gắng tự động di chuyển mã trong ứng dụng của bạn. Điều này cho phép di chuyển trơn tru khi nâng cấp Next.js:

npx @next/codemod next-image-to-legacy-image ./pages

Nếu bạn thực hiện thay đổi này và không thiết lập các bài kiểm tra hồi quy trực quan, tôi khuyên bạn nên xem kỹ các trang của mình trên mọi trình duyệt chính để xem mọi thứ có chính xác không.

Đối với thành phần Liên kết mới, thay đổi cũng phải trơn tru. Phần tử trong không còn cần thiết cũng như không được khuyến nghị nữa. Codemod sẽ xóa nó hoặc thêm một legacyBehavior prop vào thành phần của bạn.

npx @next/codemod new-link ./pages

Trong trường hợp codemod không thành công, bạn sẽ nhận được cảnh báo kiểm tra lỗi trên dev, vì vậy hãy chú ý đến thiết bị đầu cuối của bạn!

ES Modules và Automatic Module Transpilation​

Có hai bản nâng cấp đã không được nhiều người để ý, nhưng tôi cho rằng chúng đặc biệt hữu ích cho những người làm việc với Monorepos. Cho đến nay, việc chia sẻ cấu hình giữa các tệp cấu hình và các tệp khác có thể được sử dụng trong thời gian chạy không phải là việc làm dễ dàng. Đó là vì next.config.js được viết bằng CommonJS làm hệ thống mô-đun, không thể nhập từ các tệp ESM. Bây giờ, Next.js hỗ trợ ESM chỉ bằng cách thêm type: "module" vào package.json và đổi tên next.config.js → next.config.mjs.

Lưu ý: Ký tự "m" là viết tắt của "module" và là một phần của thông số kỹ thuật Node.js để hỗ trợ ESM.

Đối với Monorepos sử dụng các gói nội bộ (các gói JavaScript không được xuất bản lên NPM mà thay vào đó được các ứng dụng anh chị em trong monorepo sử dụng từ nguồn), cần có một plugin đặc biệt để biên dịch các mô-đun đó vào thời điểm xây dựng khi sử dụng chúng. Từ Next.js 13 trở đi, điều này có thể được sắp xếp mà không cần plugin bằng cách chỉ cần truyền một thuộc tính (thử nghiệm) vào next.config.mjs của bạn:

const nextConfig = { experimental: { transpilePackages: ['@my-org/internal-package'], },};

Bạn có thể xem ví dụ trong mẫu Apex-Monorepo. Với các thiết lập này, bạn có thể phát triển cả thành phần phụ thuộc và ứng dụng của mình cùng lúc mà không cần bất kỳ giải pháp xuất bản hoặc giải pháp thay thế nào.

Tiếp theo là gì?​

Nếu bạn vẫn muốn tìm hiểu và thảo luận thêm về các tính năng này, tôi sẽ tổ chức Lớp học nâng cao về Next.js từ ngày 30 tháng 11 đến ngày 15 tháng 12 năm 2022 — Tôi rất vui được chào đón bạn đến đó và trả lời mọi câu hỏi của bạn!



Cho đến lúc đó, hãy cho tôi biết trong phần bình luận bên dưới hoặc tweet cho tôi theo địa chỉ @AtilaFassina về quá trình di chuyển của bạn và suy nghĩ của bạn về các tính năng thử nghiệm.