Nếu bạn từng làm việc với các nền tảng CMS doanh nghiệp như Optimizely (trước đây là Episerver), bạn có lẽ đã quen với "trò chơi chờ đợi" mỗi khi xây dựng dự án. Quy trình làm việc frontend đôi khi vẫn còn bị mắc kẹt ở năm 2015, dựa vào Gulp, Grunt, hoặc các cấu hình Webpack dài hàng dặm.
Gần đây, nhóm chúng tôi đã quyết định phá bỏ và xây dựng lại hệ thống build cho dự án CMS Iv. Mục tiêu rất đơn giản: Nhanh hơn, Sạch hơn, và Chính xác hơn.
Đây là những gì chúng tôi đã học được từ hành trình nâng cấp lên Vite 4.0.
Tạm biệt "Loading...", Chào mừng Vite!
Sự thay đổi lớn nhất và thỏa mãn nhất là chuyển từ các bundler cũ sang Vite.
Trước đây, mỗi khi chúng tôi điều chỉnh một tệp SCSS hoặc JS, chúng tôi phải chờ vài giây (đôi khi là mười giây!) để thấy thay đổi. Với Vite, con số đó giảm xuống còn... vài trăm mili giây. Hot Module Replacement (HMR) của Vite thực sự là cứu cánh. Bạn chỉnh sửa kiểu dáng, lưu, và bùm, trình duyệt cập nhật ngay lập tức mà không cần tải lại trang. Quy trình lập trình trở nên mượt mà hơn đáng kể.
Một Theme Thống Trị Tất Cả
Chúng tôi từng duy trì ba theme khác nhau (Classic, Modern, Luxury). Nghe có vẻ hay, nhưng trên thực tế, đó là một cơn ác mộng bảo trì. Các style code bị trùng lặp, và việc sửa lỗi ở một theme thường dẫn đến việc quên sửa ở theme khác.
Lần này, chúng tôi đã đưa ra một quyết định táo bạo: Chỉ giữ lại theme Modern.
Tập trung tài nguyên vào một nơi giúp codebase sạch sẽ hơn bao giờ hết. Chúng tôi áp dụng kiến trúc ITCSS (Inverted Triangle CSS) để tổ chức SCSS. Không còn những tệp style.css dài 5000 dòng; mọi thứ được chia nhỏ thành các lớp base, components, và layout, cực kỳ dễ quản lý. Và tất nhiên, chúng tôi đã nói lời tạm biệt với cú pháp @import cũ để chuyển sang Sass @use hiện đại.
Khả năng tiếp cận không chỉ là "Nên có"
Một trong những ưu tiên hàng đầu cho Phiên bản 2.0 là đạt được sự tuân thủ WCAG 2.1 AA.
Thành thật mà nói, ban đầu nhóm nghĩ rằng, "chúng tôi chỉ cần thêm một vài thẻ alt là xong." Nhưng làm đúng thì khó hơn nhiều. Chúng tôi phải kiểm tra mọi thứ:
- Thêm
aria-labelvào các nút biểu tượng (như menu hamburger). - Đảm bảo người dùng chỉ sử dụng bàn phím có thể điều hướng trang web một cách liền mạch.
- Thiết kế lại trạng thái
:focusđể chúng thực sự hiển thị (không bao giờ sử dụngoutline: nonetrừ khi bạn có một giải pháp thay thế xứng đáng!).
Kết quả là một trang web trông tuyệt vời và thân thiện với tất cả người dùng.
Cặp đôi hoàn hảo: ASP.NET Core
Frontend chạy độc lập là tuyệt vời, nhưng làm thế nào nó có thể chạy mượt mà trong môi trường .NET?
Bí quyết của chúng tôi nằm ở sự đơn giản. Thay vì cố gắng buộc Vite tạo ra các tên tệp được hash phức tạp (như main.a1b2c3.js), chúng tôi đã tắt tính năng hashing trong Vite và để ASP.NET xử lý Cache Busting.
Chỉ cần một dòng code nhỏ trong Razor View:
<script src="~/assets/main.js" asp-append-version="true" defer></script>Thuộc tính asp-append-version="true" sẽ tự động thêm một chuỗi truy vấn hash vào đường dẫn tệp bất cứ khi nào tệp thay đổi. Vì vậy, chúng tôi có được khả năng lưu trữ cache tuyệt vời mà không cần phải cập nhật các tệp .cshtml sau mỗi lần build frontend. Một mũi tên trúng hai đích!
Lời kết
Hiện đại hóa frontend cho một dự án CMS không chỉ là nâng cấp công nghệ; đó là nâng cấp trải nghiệm của nhà phát triển. Ít thời gian chờ đợi build hơn có nghĩa là ít bực bội hơn và có nhiều thời gian hơn cho sự sáng tạo.
Nếu bạn đang mắc kẹt với các dự án CMS cũ, hãy thử "Vite-hóa" chúng. Điều đó hoàn toàn xứng đáng với công sức bỏ ra!