Щільне з'єднання Javascript, HTML та CSS: сучасніший підхід?

Дуже часто бачити, як Javascript прив'язаний до певних селекторів, щоб знайти елементи, зберігати дані та слухати події. Також звичайно бачити ці самі селектори, які використовуються для стилізації.

jQuery (та його селекторний двигун Sizzle) підтримують та сприяють цьому, посилаючись на елементи з синтаксисом типу CSS. Таким чином, цю техніку особливо складно «вивчити» (або рефактор) під час створення проектів.

Я зрозумів, що це результат історії розробки HTML і Javascript, і що браузери були побудовані для ефективного споживання / розбору / та надання такого роду з'єднань. Але оскільки веб-сайти стають все більш складними, ця реальність може створити труднощі в організації та підтримці цих окремих шарів.

Моє запитання: чи можна і чи слід цього уникати на сучасних веб-сайтах?

Якщо я новачок у передових розробках, і хочу навчитися речам «правильно», чи варто навчитися розв’язувати та уникати таких залежностей з самого початку? Чи означає це уникати jQuery на користь бібліотеки, яка рекламує більш розв'язану структуру?

Неможливо цього уникнути. Вони сполучені через те, що взаємодіють між собою. Якщо ваш JavaScript має намір робити будь-які маніпуляції з DOM, то йому потрібен спосіб посилання на DOM.

Для цього існують різні умовності.

API DOM рівня 2 забезпечує методи getElementById, getElementByTagName та getElementsByName. На сьогоднішній день це робочі коні будь-якого обходу DOM. Всі інші більш фантазійні jQuery-селектори вирішують комбінацію цих результатів та / або пряму обхід кожного вузла DOM (це було способом зробити getByClassName).

Іншого ярлика немає. Javascript повинен знати, що робити і де. Як правило, якщо в елементі є ідентифікатор або клас, що стосується лише сценаріїв, багато людей будуть префіксувати його js-чи іншим очевидним прапором.

Ще одна більш нова умова - це вибір атрибутів даних.

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

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

Атрибут даних, як правило, використовується для сценаріїв, а вибір, який використовується, має певний сенс. Недолік у тому, що це повільніше, ніж використання getElementById ().

Іншим підходом є той, який використовує angularJS, який створює модель перегляду. У цій конвенції будь-який тип функцій сценаріїв визначається спеціально призначеними атрибутами, як ng-disabled ng-hrefі багато інших. Ви не додаєте селекторів у свій JavaScript. Документ HTML стає головним органом щодо того, що написано та як, і javascript на ньому працює абстрактно. Це хороший підхід, але, очевидно, з вищою кривою навчання, ніж попередні методи. І знову ж таки, продуманість повинна враховуватися.

Але ніколи не думайте, що ви можете писати інтерактивні HTML та JavaScript, і якось обидві ці частини не знають про іншу. Це більше про те, як можна обмежити посилання на залежності.

Якщо ви готові відмовитися від інтерактивності, яку ви отримаєте, ви можете повністю уникати Javascript. Такі структури, як ASP.NET MVC, дуже добре обслуговують сторінки, що містять лише HTML, CSS та кнопку SUBMIT.

ДОБРЕ. Можливо, це трохи екстремально.

Розв'язка веб-програми вже відбувається на багатьох рівнях. Програми REST дозволяють визначити ваш додаток з точки зору "веб-ресурсів", пов'язаних із URL-адресою. Моделі перегляду дозволяють представляти дані в інтерфейс користувача, який відокремлений від доменної моделі, але має форму, необхідну для правильного його відображення. Сервісні шари дозволяють замінити один інтерфейс користувача на інший тощо.

Історично завжди було взаємодія між інтерактивністю та зв'язком. Чим інтерактивніша ваша веб-сторінка, тим щільніше поєднане з додатком. Але логіка інтерактивності на веб-сторінці обмежується лише веб-сторінкою; будь-яке з'єднання з сервером відбудеться через POST або AJAX. Тому я не впевнений, що вам слід надто перейматися зв'язком на рівні Javascript, крім того, щоб звертати увагу на спосіб передачі пакетів даних між браузером та сервером.

Найбільш "сучасний" підхід (тобто аромат тижня), ймовірно, SPA-програми .

Мартін Фаулер описує один підхід до цього як відокремлений DOM , де ви відокремлюєте свій DOM JavaScript від логіки JavaScript на своїй сторінці.

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

Ні, не слід уникати використання селекторів класів, елементів та ідентифікаторів на стороні клієнта. Синтаксис використовується тому, що селектори CSS є дуже зрілою та добре усталеною мовою домену, і, маючи спільний дизайн, набагато простіше ділитися загальною логічною моделлю сторінки між програмою та дизайном, що дуже, дуже добре.

Хоча можливо використовувати цей синтаксис неправильно та створити жахливий і нездійснений додаток, таке можливо незалежно від вашої мови чи набору інструментів.

Комусь потрібно створити інтерфейс менеджера контурів jQuery для шару непрямості та кешу до дому.

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

Потім,

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

Так,

// 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({});