Kết hợp chặt chẽ giữa Javascript, HTML và CSS: Cách tiếp cận hiện đại hơn?

Rất phổ biến khi thấy Javascript bị ràng buộc với một số bộ chọn nhất định để tìm các yếu tố, lưu trữ dữ liệu và lắng nghe các sự kiện. Cũng thường thấy những bộ chọn tương tự được sử dụng để tạo kiểu.

jQuery (và công cụ chọn Sizzle) hỗ trợ và thúc đẩy điều này bằng cách tham chiếu các phần tử với cú pháp kiểu CSS. Do đó, kỹ thuật này đặc biệt khó 'không học' (hoặc tái cấu trúc) khi xây dựng các dự án.

Tôi đã hiểu rằng đây là kết quả của lịch sử phát triển HTML và Javascript và các trình duyệt đã được xây dựng để tiêu thụ / phân tích / hiệu quả và kết xuất loại khớp nối này. Nhưng khi các trang web ngày càng phức tạp, thực tế này có thể gây khó khăn trong việc tổ chức và duy trì các lớp riêng biệt này.

Câu hỏi của tôi là: có thể và nên tránh điều này trong các trang web hiện đại?

Nếu tôi chưa quen với việc phát triển front-end và tôi muốn học mọi thứ 'đúng cách', có đáng để học cách tách rời và tránh những phụ thuộc như vậy ngay từ đầu không? Điều này có nghĩa là tránh jQuery có lợi cho một thư viện thúc đẩy cấu trúc tách rời hơn?

Không có cách nào để tránh điều đó. Chúng được ghép bởi vì chúng tương tác với nhau. Nếu javascript của bạn có ý định thực hiện bất kỳ loại thao tác DOM nào, thì nó cần một cách để tham chiếu DOM.

Có nhiều quy ước khác nhau cho nó.

API DOM cấp 2 cung cấp các phương thức getEuityById, getEuityByTagName và getElementsByName. Cho đến ngày nay, đây là những con ngựa của bất kỳ loại DOM nào. Tất cả các bộ chọn jQuery fancier khác giải quyết thành một sự kết hợp cuối cùng và / hoặc chuyển thẳng qua từng nút DOM (đây là cách để làm getByClassName).

Không có lối tắt nào khác. Javascript cần biết phải làm gì và ở đâu. Thông thường, nếu một phần tử có id hoặc lớp chỉ có liên quan đến tập lệnh, rất nhiều người sẽ thêm tiền tố vào đó js-hoặc một số cờ rõ ràng khác.

Một quy ước mới hơn là lựa chọn thuộc tính dữ liệu.

<ul data-myapp-sortable="true">

jQuery('[data-myapp-sortable]').makeSortable();

Thuộc tính dữ liệu thường được sử dụng cho các mục đích kịch bản và chọn sử dụng có ý nghĩa. Hạn chế là điều này chậm hơn so với việc sử dụng getEuityById ().

Một cách tiếp cận khác là phương pháp được sử dụng bởi angularJS, tạo ra mô hình khung nhìn. Trong quy ước này, bất kỳ loại chức năng kịch bản nào cũng được chỉ định bởi các thuộc tính được chỉ định đặc biệt như ng-disabled ng-hrefvà nhiều hơn nữa. Bạn không thêm bộ chọn trong javascript của mình. Tài liệu HTML trở thành cơ quan chính về nội dung được viết theo kịch bản và cách thức, và javascript hoạt động trên đó một cách trừu tượng. Đó là một cách tiếp cận tốt, nhưng rõ ràng với đường cong học tập cao hơn các phương pháp trước đây. Và một lần nữa, hiệu suất phải được xem xét.

Nhưng đừng bao giờ nghĩ rằng bạn có thể viết HTML và javascript tương tác, và bằng cách nào đó có cả những phần không biết về phần kia. Đó là nhiều hơn về cách bạn có thể giới hạn các tài liệu tham khảo cho các phụ thuộc.

Nếu bạn sẵn sàng từ bỏ tính tương tác mà bạn nhận được, bạn hoàn toàn có thể tránh Javascript. Các khung như ASP.NET MVC rất tốt trong việc phục vụ các trang chỉ chứa HTML, CSS và nút SUBMIT.

ĐƯỢC. Có lẽ đó là một chút cực đoan.

Việc tách rời trong một ứng dụng web đã xảy ra ở nhiều cấp độ. Các ứng dụng REST cho phép bạn xác định ứng dụng của mình theo "tài nguyên web" được liên kết với một URL. Mô hình xem cho phép bạn trình bày dữ liệu tới giao diện người dùng được tách rời khỏi mô hình miền, nhưng có hình dạng mà bạn cần hiển thị đúng. Các lớp dịch vụ cho phép một giao diện người dùng được hoán đổi cho một giao diện khác, v.v.

Trong lịch sử, luôn có sự đánh đổi giữa tính tương tác và khớp nối. Trang web của bạn càng tương tác nhiều, càng gắn kết chặt chẽ với ứng dụng. Nhưng logic tương tác trong trang web bị giới hạn trong chính trang web; mọi sự ghép nối với máy chủ sẽ xảy ra thông qua POST hoặc AJAX. Vì vậy, tôi không chắc chắn bạn nên quan tâm quá mức đến việc ghép nối ở cấp độ Javascript, ngoài việc chú ý đến cách các gói dữ liệu được truyền giữa trình duyệt và máy chủ.

Cách tiếp cận "hiện đại" nhất (nghĩa là hương vị của tuần) có lẽ là các ứng dụng SPA .

Martin Fowler mô tả một cách tiếp cận này là DOM tách riêng, trong đó bạn tách DOM JavaScript của bạn khỏi JavaScript logic trang của bạn.

Application Logic <----> DOM Manipulation <----> DOM / HTML

Không, không nên tránh sử dụng bộ chọn lớp, phần tử và ID phía máy khách. Cú pháp được sử dụng vì các bộ chọn CSS là ngôn ngữ miền rất thành thục và được thiết lập tốt, và có một thiết kế chung giúp chia sẻ một mô hình logic chung của một trang giữa chương trình và thiết kế, đó là một điều rất tốt.

Mặc dù có thể sử dụng sai cú pháp này và tạo ra một ứng dụng khủng khiếp và không thể nhầm lẫn, nhưng điều đó là có thể bất kể ngôn ngữ hoặc bộ công cụ của bạn.

Ai đó cần xây dựng giao diện trình quản lý đường dẫn jQuery cho lớp không xác định và bộ đệm cho dom.

pathMgr.register(name,selector [,isDynamic=false]);
pathMgr.get(name [,refresh]);

Sau đó,

String.prototype.reg([isDynamic=false]);
String.prototype.get(name [,refresh]);

Vì thế,

// at init....
var pathMgr=new PathMgr();
'sidebar-links #sidebar a'.reg();// new registery of selector '#sidebar a' under name 'sidebar-links'
// more, more


// in code
'sidebar-links'.get().css(etc...);
//or
'sidebar-links'.addStyleRule({});