tôi thích viết mã. Tôi đã viết bằng Java, PHP, C#, Perl Shutter và JavaScript. Tôi yêu thích js nhiều như vậy, nhưng sở thích của tôi có lẽ là HTML vì cách bản chất khai báo của nó cho phép tôi dễ dàng diễn đạt những gì tôi đang hình dung trong đầu và chỉ với một cú nhấp chuột vào nút làm mới, tôi có thể thấy ngay tác phẩm của mình trên đó . Đó là thiết kế và kỹ thuật tất cả trong một chuyển động và tôi thích nó. Nhưng HTML không nhận được loại sử dụng mà nó nên. Hãy xem qua những điều cơ bản và tìm hiểu một cách tiếp cận mới mà bạn có thể thấy đáng xem xét
Vì vậy, công việc của HTML là cung cấp cấu trúc và ý nghĩa nội dung. Đây được gọi là ngữ nghĩa. Khi web phát triển, HTML được điều chỉnh để bao gồm các yếu tố mới nhằm cung cấp hỗ trợ ngữ nghĩa cho nhiều nội dung hơn, chẳng hạn như
để điều hướng và cho video vàNhững bổ sung này đã được thực hiện thông qua các cấu trúc HTML thông thường. thẻ, thuộc tính và lồng nhau. Trong trường hợp bạn cần xem lại, đây là một số ví dụ
h1 là thẻ “tiêu đề cấp 1”
Đó là một phần tử "neo", thẻ a, với các thuộc tính tải xuống và "tham chiếu siêu văn bản" và nó được lồng bên trong p hoặc đoạn văn. Dưới đây là một số ví dụ khác
HTML cung cấp cho chúng tôi rất nhiều yếu tố này để làm việc, nhưng như bạn biết rõ, nó không cung cấp cho chúng tôi đủ yếu tố cho mọi thứ chúng tôi cần. Không phải bằng một cú sút xa. Lấy các biểu tượng làm ví dụ đơn giản, đây là một số trong giao diện người dùng của GitHub
Vì HTML không cung cấp cho chúng tôi thẻ biểu tượng để đánh dấu các biểu tượng của trang web nên chúng tôi phải đưa ra các giải pháp của riêng mình. Dưới đây là bốn cách tiếp cận tương tự mà bạn có thể đã thấy trước đây
Những giải pháp đó sử dụng các lớp để xác định cả loại thành phần và thuộc tính của nó, và mặc dù điều đó không có gì sai nhưng vẫn có những hạn chế
1] Đặt tên lặp lại.
fa, icon, oi, và octiccon phải được lặp lại hai lần. Không khô rao.
2] Mất sự rõ ràng khi điều sau chắc chắn xảy ra [hoặc nỗ lực thêm cần thiết để ngăn chặn điều đó]
Chính xác thì cái cuối cùng được cho là gì?
3] Thẻ trở thành bản soạn sẵn không thể tránh khỏi mà không có ý nghĩa gì
Điều đó có nghĩa là
tất cả đều là bản soạn sẵn. đáng tiếc4] Bên cạnh các yếu tố tiêu chuẩn, thiết kế dựa trên lớp có vẻ không phù hợp
Điều gì sẽ xảy ra nếu các phần tử tiêu chuẩn sử dụng các lớp như thế này?
Khá thô, nhưng đó là thiết kế dựa trên đẳng cấp và thậm chí còn tệ hơn nếu bạn theo dõi BEM. Đây là một ví dụ về điều đó từ một hệ thống thiết kế phổ biến
Các cách tiếp cận khác thậm chí còn kỳ lạ hơn
Chúng ta không phải làm theo cách này. Chúng tôi không cần phải sử dụng các lớp học hoặc mánh khóe. Có một cái gì đó tốt hơn
Chúng tôi có thể thiết kế các thành phần tùy chỉnh với các API có ý nghĩa hơn bằng cách sử dụng thẻ, thuộc tính và lồng nhau - giống như các phần tử thực. Đây là ý nghĩa của nó
Một thiết kế dựa trên lớp điển hình
Hiện đã hoàn tất với thẻ và thuộc tính tùy chỉnh
Nếu điều này làm bạn khó chịu, đừng lo lắng. Thẻ tùy chỉnh tương thích với tất cả các trình duyệt hiện đại và các phiên bản IE mới hơn. Các trình duyệt vui vẻ tải xuống, phân tích cú pháp và hiển thị các thẻ tùy chỉnh giống như bất kỳ HTML “thực” nào vì đây là HTML thực. Chắc chắn, đó không phải là thành phần tiêu chuẩn và các trình duyệt sẽ không có bất kỳ kiểu mặc định hoặc hành vi tích hợp nào cho thẻ tùy chỉnh hoặc thẻ không xác định của bạn, nhưng đó hoàn toàn không phải là vấn đề. Bạn có thể tạo quy tắc CSS cho các thẻ tùy chỉnh, như biểu tượng, giống như cách bạn có thể làm cho các thẻ và lớp tiêu chuẩn
Vì vậy, có chúng tôi đi. Nó hoạt động hoàn hảo và ngoài tính đặc hiệu, nó không khác gì. biểu tượng và. icon-phone. trước
Hãy làm một cái khác
Một thiết kế Huy hiệu dựa trên lớp điển hình trông giống như
Không tệ, nhưng đây là điều tương tự khi sử dụng thẻ và thuộc tính
Cái thứ hai rõ ràng là một thành phần Huy hiệu với các thuộc tính riêng của nó. Một lần nữa, không giống như các yếu tố thực tế. Và với một chút CSS, chúng tôi có thể thêm một số thông tin vào Huy hiệu để khi nó có số lượng bằng 0 hoặc không có số lượng, nó sẽ ẩn đi
thật tuyệt
Dưới đây là một số ví dụ khác về các thành phần được tạo bằng thẻ và thuộc tính tùy chỉnh thay vì lớp
Chúng ta làm lại các Thao tác Hộp thoại của Vật liệu từ trước đó thì sao?
Bạn có thể thấy sự khác biệt?
Bạn đang bắt đầu cảm nhận được những lợi ích?
Thiết kế các thành phần UI đơn giản này với các thẻ và thuộc tính thay vì các lớp rất thú vị và tốt hơn. khách quan là tốt hơn
Cho phép các kỹ sư giao diện người dùng thiết kế các thành phần với nhiều API có ý nghĩa hơn thay vì thẻ soạn sẵn và danh sách các lớp
Thẻ tùy chỉnh có ý nghĩa ngữ nghĩa mạnh mẽ và dễ dàng nhận dạng. so với.
Không còn BEM hay các phương pháp tương tự cho kỹ thuật xoay quanh các vấn đề với thiết kế dựa trên lớp
Trong nhiều trường hợp, bạn có thể bỏ nhu cầu trừu tượng hóa. {{> icon name="phone"}} hoặc được thay thế bằng
Kết quả là một đánh dấu rõ ràng, dựa trên tiêu chuẩn có giao diện đồng nhất đẹp mắt với khả năng đọc tuyệt vời
Using custom tags and attributes is officially supported. It’s how HTML thought we’d design custom components, but we instead went crazy for classes!
Ngoài ra còn có một lợi ích lớn khác khi sử dụng thẻ và thuộc tính tùy chỉnh. nó định vị thành phần của bạn tốt hơn để cải tiến trong tương lai. Làm thế nào vậy?
Tạo và chia sẻ các thành phần tùy chỉnh là một cam kết. Các thành phần của bạn sẽ phát triển và có thêm các khả năng mới theo thời gian. Hãy xem sự phát triển có thể có của thành phần Cảnh báo tùy chỉnh [còn gọi là Chú thích]
Thiết kế ban đầu
Điều đó sẽ trông giống như
Xin lưu ý rằng không có phụ thuộc ở đây. Không có gì để tải xuống, không có công cụ và không có gì để xây dựng. Không phép thuật, không hack, không sở hữu độc quyền, không khuôn khổ hay cú pháp đặc biệt, không gì cả. Và khi nói đến việc xây dựng phần mềm, không gì tốt hơn một thứ
Thông báo của chúng tôi hiện khá đơn giản, vì vậy hãy xem liệu chúng tôi có thể đặt cho nó một biểu tượng không
Với một biểu tượng
Điều đó hiệu quả, nhưng đó không phải là cách đúng đắn để thiết kế một thành phần. Hãy lấy một biểu tượng mà không phụ thuộc vào người triển khai
Với biểu tượng được suy ra
Ok, điều đó bắt đầu thực sự trông giống như một cái gì đó. [Lưu ý rằng CSS ở đây không bao gồm tất cả các thuộc tính cần thiết]
Việc Cảnh báo tự động biến mất là điều khá phổ biến, vì vậy hãy thêm hỗ trợ cho điều đó. Nếu thực sự có một phần tử cảnh báo HTML và nó có tính năng tự động biến mất thì người ta có thể tưởng tượng rằng nó sẽ có thuộc tính tự động loại bỏ để kích hoạt hành vi này, vì vậy hãy bắt đầu với điều đó
Tính năng tự động loại bỏ mới
Tốt đẹp. Chúng tôi thực sự đã có cho mình một thành phần hữu ích mà không cần một bước xây dựng hoặc polyfill nào - hãy tưởng tượng rằng. Và kiểm tra API nhỏ thân thiện của nó
thẻ cảnh báo
thuộc tính loại [bắt buộc] - một trong các thuộc tính “thành công”, “cảnh báo” hoặc “lỗi”
tự động loại bỏ [tùy chọn]
id, class, aria- and other “inherited” attributes still apply
transitionend event - DOM event, fires after Alert disappears
Accepts nested content, including other custom tags
Nếu bạn không biết rõ hơn, bạn có thể nghĩ rằng đây là một trong số các phần tử HTML5 ưa thích. Đó là dấu hiệu chúng ta đang đi đúng hướng
Đóng, nhưng không hoàn toàn
Tuy nhiên, có một vấn đề nhỏ. Vấn đề là tên thẻ của chúng tôi không hoàn toàn phù hợp với tương lai. Có hai cân nhắc ở đây.
Xung đột
Đầu tiên là một ngày nào đó HTML có thể nhận được thẻ có cùng tên với thẻ của chúng tôi. Tôi cầu nguyện mỗi đêm trước khi đi ngủ rằng WHATWG sẽ cung cấp cho chúng tôi, nhưng nếu WHATWG không cung cấp thì vẫn có khả năng một số nhà phát triển khác sẽ cung cấp cho chúng tôi. Dù bằng cách nào cũng có nguy cơ xảy ra va chạm và điều đó đưa chúng ta đến sự cân nhắc thứ hai. tiền tố.
Tiền tố
Mặc dù về mặt kỹ thuật, đây không phải là Phần tử tùy chỉnh nhưng bạn sẽ muốn tuân theo thông số kỹ thuật đó bằng cách sử dụng tiền tố cho thẻ tùy chỉnh của mình. Tại Avalara, chúng tôi sử dụng s- làm tiền tố của mình. Chữ s là viết tắt của Skylab, là tên hệ thống thiết kế của chúng tôi, nhưng nó cũng có nghĩa là.
tiêu chuẩn - chúng tôi luôn hướng tới tiêu chuẩn cho đến khi chúng tôi thực sự cần đưa vào phần phụ thuộc
ngữ nghĩa - thẻ có thuộc tính có nhiều ngữ nghĩa hơn div có lớp
small - basic HTML and CSS can take you very far without the overhead of something like React
shared - these components are shared by our 20+ web apps and three times as many developers
Seattle - ok not really, but that’s where we are! Come join us
Vì vậy, vâng, tiền tố là một cách thực hành tốt nhất. Nó giải quyết nguy cơ xung đột giữa các thẻ và là điểm phân biệt trực quan hữu ích giữa thẻ tiêu chuẩn và thẻ tùy chỉnh. Quan trọng hơn, nó giúp bạn thiết lập rất tốt khi chức năng hỗ trợ JavaScript được yêu cầu và thành phần “vi mô” nhỏ hạnh phúc của bạn cần phát triển và trở thành Phần tử tùy chỉnh thực sự [hoặc tương tự]. Bạn thấy đấy, việc sử dụng các thẻ tùy chỉnh có tiền tố thay vì các lớp cho phép các thành phần của bạn mở rộng theo một trong hai hướng. bạn có thể thu nhỏ thành các thành phần chỉ có CSS nhẹ như biểu tượng hoặc tất cả các thành phần tương tác đáp ứng tất cả các thay đổi trạng thái trong khi vẫn duy trì cùng một giao diện HTML. Bí mật là các thẻ tùy chỉnh có tiền tố
Hãy xem cách Cảnh báo của chúng ta có thể chuyển từ thẻ tùy chỉnh cơ bản có kiểu sang thành phần hỗ trợ JavaScript tương tác mà không vi phạm các thay đổi hoặc thay đổi mô hình
Trong bản phát hành Cảnh báo trong tương lai, giả sử chúng tôi đang thêm khả năng đặt thời lượng tự động loại bỏ. Bạn có thể lấy bốn giây mặc định bằng cách thêm thuộc tính hoặc bạn có thể rút ngắn hoặc kéo dài thời lượng đó bằng cách đặt giá trị của nó thành một số
Ghi đè thời lượng tự động loại bỏ
Nhưng như chúng ta đã học được, cách tốt nhất là sử dụng tiền tố, vì vậy điều đó thực sự nên
lưu ý bên lề. Nếu bạn là người duy trì thư viện dùng chung, hãy chọn một tiền tố ngắn có ý nghĩa đối với bạn. Ví dụ, Bootstrap của Twitter sẽ đi từ
Vật liệu có thể sử dụng mdc- như hình trên
Dù sao, quay lại chế độ tự động loại bỏ. Hỗ trợ giá trị giây hiện yêu cầu sử dụng JavaScript. Tại thời điểm này, hầu hết mọi người làm theo những gì họ biết hoặc thử tăng cường hương vị của ngày cho bất kỳ thành ngữ và cú pháp đặc biệt nào được yêu cầu. Đó không phải là vấn đề nếu bạn là một nhóm nhỏ với một ứng dụng, nhưng nếu bạn có nhiều người tiêu dùng thành phần Cảnh báo của mình thì bạn đang tham gia vào một hợp đồng mã và hợp đồng đó càng ít yêu cầu người triển khai thì càng tốt
Chúng tôi có thể giảm thiểu hợp đồng và có vị trí tốt hơn trong dài hạn nếu chúng tôi chọn một giải pháp tuân theo hoặc gần với các Yếu tố tùy chỉnh. Dưới đây là một số tùy chọn có sẵn ngày hôm nay
Tất nhiên là các Thành phần tùy chỉnh hoặc Thành phần web toàn diện
Polymer
Slim
Vue
Riot, which has the best DX out there imo, try it. There’s even a w3c proposal that takes the Custom Elements spec in a similar direction
Dưới đây là hai ví dụ trong đó Cảnh báo đã được nâng cấp thành một thành phần có trạng thái để hỗ trợ giá trị do người dùng xác định cho độ trễ tự động loại bỏ.
Yếu tố tùy chỉnh + yếu tố
Bất kể triển khai như thế nào, đánh dấu của chúng tôi cho Cảnh báo vẫn không thay đổi
Và mặc định vẫn hoạt động như vậy
Không gian front-end nổi tiếng với sự thay đổi nhanh chóng. Đó là một nơi cường điệu và mốt nhất thời. Điều đó có thể sẽ không thay đổi, nhưng trong tương lai nếu thứ bạn chọn cho phép bạn và các nhà phát triển khác soạn giao diện người dùng bằng HTML, thì đó là một lựa chọn tốt. Nếu điều gì đó buộc bạn phải thêm nhiều kb [hơn 10 phút+gz] và viết cú pháp đặc biệt, thì đó không phải là lựa chọn tốt cho bố cục giao diện người dùng vì chúng tôi đã có HTML cho điều đó. Chúng tôi chưa sử dụng nó đúng cách
Khả năng viết các ứng dụng được xây dựng bằng loại đánh dấu dựa trên tiêu chuẩn này không chỉ là một DX tốt hơn mà còn ít tốn kém hơn vì không có gì độc quyền chắc chắn sẽ lỗi thời và cần được tái cấu trúc. Lấy giao diện người dùng của GitHub làm ví dụ. Không biết họ đã xây dựng nó bằng gì, nhưng khi tôi viết bài này, tôi nhìn vào giao diện và tưởng tượng mình đang sử dụng Skylab để tạo lại nó
Bây giờ tôi biết điều này không giải quyết được vấn đề khó khăn về quản lý trạng thái ứng dụng và giao diện người dùng phản ánh trạng thái đó một cách đáng tin cậy. Đó là điều mà React và những người khác đặt ra để giải quyết và họ đã làm được. Nhưng cộng đồng front-end dường như đã không thể thực hiện một cách tiếp cận cân bằng để áp dụng các công nghệ mới này và chỉ bắt đầu thiết kế quá mức mọi thứ trước mắt. Nó rất phổ biến trong cộng đồng React nói riêng. Tôi sẽ mạo muội nói rằng nếu bạn sử dụng React thì chắc chắn bạn đang có một ứng dụng được thiết kế quá mức, hoặc ít nhất là một phần. Khi tôi nhìn thấy những thứ như thế này, tôi chỉ tự hỏi tất cả các nhà phát triển React đang làm cái quái gì với chính họ [đây là những thành phần React thực sự, có hàng trăm ví dụ như thế này]
Chỉ cần dành một phút để suy nghĩ về những gì đã xảy ra ở đó…
Đây là một cái khác từ một công ty tuyệt vời nên biết rõ hơn
Việc lạm dụng các thư viện này làm giảm lợi ích tiềm năng, thậm chí đến mức dẫn đến kết quả tiêu cực tổng thể. Nhưng tôi không biết, có lẽ nó không quá rõ ràng
Một kỹ sư có nên viết hàng chục dòng CSS để tạo Huy hiệu hay họ nên viết tổng cộng 474 dòng mã trên 8 tệp có nhiều phụ thuộc và một quy trình xây dựng bắt buộc?
“Vì vậy, nó có thể mở rộng quy mô,” tôi nghe thấy. Vì vậy, nó có thể…và 9 trong số 10 lần triển khai không có nguy cơ không thể mở rộng quy mô, nhưng tất cả 10 lần triển khai đã được giải quyết bằng [chèn thư viện js yêu thích] và hiện tại, ứng dụng có số lượng mã gấp 10 lần so với mức cần thiết và cực kỳ cao . Nó có thể thu nhỏ lại không?
Và đó thực sự là ý nghĩa của cách tiếp cận thẻ tùy chỉnh. Có, thiết kế thẻ cộng với thuộc tính đẹp hơn nhiều so với thiết kế dựa trên lớp [thời điểm chuyển đổi đó chắc chắn đã đến], nhưng có thể thiết kế và xây dựng các thành phần mở rộng theo bất kỳ hướng nào với HTML tốt trong nhiều trường hợp sử dụng
Các thẻ HTML tùy chỉnh, Thành phần web, thông số Phần tử tùy chỉnh và một số lib js gần với nó - đó là con đường để thiết kế các thành phần giao diện người dùng tốt hơn và vượt qua thời đại kỹ thuật quá mức này