Ưu tiên Utility trước, Component sau

• Thường thì trong CSS, phương pháp ưu tiên utility (Utility-First) như tailwindcss hay bị xem là kiểu treo lủng lẳng đầy class trong HTML.

• Nhưng đó chỉ là bề ngoài; cốt lõi của cách tiếp cận ưu tiên utility nằm ở vấn đề thời điểm cấu thành component.

• Phương pháp từng thịnh hành vào buổi đầu của CSS đã tạo ra cơn ác mộng về bảo trì.

• Trào lưu OOCSS cố gắng giải quyết vấn đề bằng cách cấu thành component. Khả năng tái sử dụng tăng lên, nhưng lại vấp phải bài toán khó trong việc xác định phạm vi component.

• Component vốn là để phục vụ tái sử dụng, nhưng vấn đề là không thể biết trước trong tương lai cái gì sẽ được tái sử dụng.

• Trào lưu Atomic CSS cố gắng giải quyết vấn đề bằng cách chỉ gán một class cho một thuộc tính. Tốc độ phát triển ban đầu nhanh hơn, nhưng vấn đề về khả năng bảo trì lại xuất hiện.

• Single Source of Truth bị phá vỡ quá dễ dàng — phải phụ thuộc vào tìm kiếm và thay thế trên toàn bộ mã nguồn (việc phụ thuộc vào template bên ngoài thì phiền phức và cũng có giới hạn).

• Khác với Atomic, cách tiếp cận ưu tiên utility thừa nhận component. Đồng thời, khác với OOCSS, nó bắt đầu từ utility. Component chỉ cần được cấu thành khi thật sự cần thiết.

• Nó chuyển câu hỏi từ “sẽ biến cái gì thành component?” sang “sẽ tạo component khi nào?”.

• Nói cách khác, utility-first nên được xem là cách tổng hợp, kế thừa và phát triển từ cả hai hướng tiếp cận đó.

• Vì vậy, trong phương pháp utility-first, component cần được nhấn mạnh hơn nữa. Không phải là “chúng tôi cho phép component”, mà là “chúng tôi tối đa hóa khả năng tái sử dụng bằng cách trì hoãn việc tạo component cho đến thời điểm nó thực sự cần thiết”.

[nemorize]

Đọc rất hay.

[mytory]

Cảm ơn :)