Есть ли какие-либо недостатки в инъекции JavaScript на основе класса?

Question

Явление, которое я вижу, - это все больше и больше кода 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 тесно связан с особые случаи шаблона пользовательского интерфейса, а не самого шаблона пользовательского интерфейса.

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

$(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, чтобы найти код Attach для этого элемента.

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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