Есть ли недостатки в внедрении Javascript на основе классов? - PullRequest
Новая
       1

Есть ли недостатки в внедрении Javascript на основе классов?

2 голосов
/ 07 июня 2010

Я наблюдаю все больше и больше явлений - это код Javascript, который привязан к определенному элементу на конкретной странице, а не привязан к видам элементов или шаблонам пользовательского интерфейса.

Например, скажем, у нас было несколько анимированных меню на странице: 

<ul id="top-navigation">
    ...
</ul>

<!-- ... -->

<ul id="product-list">
    ...
</ul>

Эти два меню могут существовать на одной и той же странице или на разных страницах, а на некоторых страницах может не быть меню.

Я часто вижу такой код Javascript (для этих примеров я использую jQuery): 

$(document).ready(function() {
    $('ul#top-navigation').dropdownMenu();
    $('ul#product-selector').dropdownMenu();
});

Заметили проблему?

Javascript тесно связан с конкретными экземплярами шаблона UI, а не с самим шаблоном UI.

Теперь не будет ли намного проще (и чище) сделать это вместо этого? - 

$(document).ready(function() {
    $('ul.dropdown-menu').dropdownMenu();
});

Затем мы можем добавить класс «выпадающее меню» в наши списки следующим образом: 

<ul id="top-navigation" class="dropdown-menu">
    ...
</ul>

<!-- ... -->

<ul id="product-list" class="dropdown-menu">
    ...
</ul>

Такой способ работы будет иметь следующие преимущества:

  • Упрощенный Javascript - нам нужно присоединить один раз к классу.
  • Мы избегаем поиска конкретных экземпляров, которые могут не существовать на данной странице.
  • Если мы удаляем элемент, нам не нужно искать Javascript, чтобы найти код присоединения для этого элемента.

Я полагаю, что подобные методы были впервые опубликованы в некоторых статьях на alistapart.com.

Я удивлен, что эти простые методы до сих пор не получили широкого распространения, и я все еще вижу «лучшие» примеры кода и структуры Javascript, ссылающиеся непосредственно на экземпляры пользовательского интерфейса, а не на шаблоны пользовательского интерфейса.

Есть ли причина для этого? Есть ли какой-то большой недостаток в только что описанной технике, о которой я не знаю?

Ответы [ 2 ]

1 голос
/ 07 июня 2010

Ваш подход предпочтителен.

Причина, по которой люди делают вещи по-разному, заключается в том, что они могут, и это все еще работает.

1 голос
/ 07 июня 2010

Прежде всего, я согласен с вами, что в целом лучше использовать классовый подход.

Но я не думаю, что зашёл бы так далеко, чтобы сказать, что это меньше связывает код с пользовательским интерфейсом. Если вы подумаете об этом, если код принимает идентификатор «foo» и имя класса «foo», вы все равно должны знать это при работе с пользовательским интерфейсом. Между ними все еще есть «контракт» - неважно, встречаете ли вы его по ID или по классу.

Одним из недостатков использования подхода класса, который я себе представляю, является скорость - должно быть быстрее найти конкретный элемент по идентификатору, чем найти потенциально несколько элементов по классу. Разница, вероятно, совершенно незначительна.

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

Одна вещь, которую я бы изменил в обоих ваших примерах ... почему в селекторе есть UL? Если код знает, что он может работать только в том случае, если целью является UL, это одно, но в этом случае было бы лучше избегать UL в селекторе и позволить коду выдать значимую ошибку, если Обнаружено, что target не является UL, чтобы страница просто ничего не делала без указания причины (например, потому что UI поместил ID / класс в OL).

Другими словами, просто "#foo" или ".foo", а не "ul.foo" и т. Д.

Я должен отметить, что в случае, если кто-то считает, что UL каким-то образом делает селектор более эффективным, это не так, поскольку селекторы оцениваются справа налево.

...