Я не раз чув, що використання подій JavaScript, таких як onClick()HTML, є поганою практикою, оскільки це не добре для семантики. Мені хотілося б знати, які недоліки є, і як виправити наступний код?

<a href="#" onclick="popup('/map/', 300, 300, 'map'); return false;">link</a>

Ви, мабуть, говорите про ненав’язливий Javascript , який виглядав би так:

<a href="#" id="someLink">link</a>

з логікою в центральному файлі JavaScript виглядає приблизно так:

$('#someLink').click(function(){
    popup('/map/', 300, 300, 'map'); 
    return false;
});

Переваги є

• поведінка (Javascript) відокремлено від презентації (HTML)
• відсутність змішування мов
• ви використовуєте рамку javascript, наприклад jQuery, яка може вирішувати більшість проблем між браузером
• Ви можете додати поведінку до багатьох елементів HTML одночасно без дублювання коду

Якщо ви використовуєте jQuery, тоді:

HTML:

 <a id="openMap" href="/map/">link</a>

JS:

$(document).ready(function() {
    $("#openMap").click(function(){
        popup('/map/', 300, 300, 'map');
        return false;
    });
});

Це має перевагу продовжувати працювати без JS або якщо середній користувач натискає посилання.

Це також означає, що я міг обробляти загальні спливаючі вікна, переписуючи знову на:

HTML:

 <a class="popup" href="/map/">link</a>

JS:

$(document).ready(function() {
    $(".popup").click(function(){
        popup($(this).attr("href"), 300, 300, 'map');
        return false;
    });
});

Це дозволить вам додати спливаюче вікно до будь-якого посилання, просто надавши йому клас спливаючого вікна.

Цю ідею можна поширити ще далі:

HTML:

 <a class="popup" data-width="300" data-height="300" href="/map/">link</a>

JS:

$(document).ready(function() {
    $(".popup").click(function(){
        popup($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');
        return false;
    });
});

Тепер я можу використовувати один і той же біт коду для багатьох спливаючих вікон на всьому сайті, без необхідності писати набір матеріалів onclick! Так, для повторного використання!

Це також означає, що якщо згодом я вирішу, що спливаючі вікна є поганою практикою (якою вони є!) І що я хочу замінити їх модальним вікном стилю лайтбокс, я можу змінити:

popup($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');

до

myAmazingModalWindow($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');

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

Завдяки дуже великим програмам JavaScript, програмісти використовують більше інкапсуляції коду, щоб уникнути забруднення глобальної сфери. А щоб зробити функцію доступною для дії onClick в елементі HTML, вона повинна бути в глобальному масштабі.

Можливо, ви бачили файли JS, які виглядають приблизно так ...

(function(){
    ...[some code]
}());

Це вирази функцій негайно викликаних функцій (IIFE), і будь-яка функція, заявлена ​​в них, буде існувати лише у їхньому внутрішньому обсязі.

Якщо ви function doSomething(){}заявите в IIFE, то зробіть doSomething()елемент onClick елемента на своїй HTML-сторінці, ви отримаєте помилку.

Якщо, з іншого боку, ви створюєте eventListener для цього елемента в межах цього IIFE і дзвоните, doSomething()коли слухач виявить подію клацання, ви хороші, тому що слухач і doSomething()ділиться областю IIFE.

Для маленьких веб-додатків з мінімальною кількістю коду це не має значення. Але якщо ви прагнете писати великі, що підтримуються коди, onclick=""це звичка, якої слід уникати.

Це не добре з кількох причин:

• він змішує код і розмітку
• код, написаний таким чином, проходить через eval
• і працює в глобальному масштабі

Найпростіше було б додати nameатрибут до свого <a>елемента, тоді ви могли б зробити:

document.myelement.onclick = function() {
    window.popup('/map/', 300, 300, 'map');
    return false;
};

хоча сучасна найкраща практика полягає у використанні idзамість імені, а addEventListener()замість використання, onclickоскільки це дозволяє прив’язати кілька функцій до однієї події.

Є кілька причин:

1. Я вважаю, що це допомагає підтримувати окрему розмітку, тобто HTML та сценарії на стороні клієнта. Наприклад, jQuery дозволяє легко додавати обробників подій програмно.

2. Приклад, який ви подаєте, буде порушений у будь-якому користувальницькому агенті, який не підтримує JavaScript або вимкнено JavaScript. Концепція прогресивного вдосконалення заохочуватиме просте гіперпосилання на /map/користувацьких агентів без javascript, а потім додавати обробник кліків prgramatic для користувацьких агентів, які підтримують javascript.

Наприклад:

Розмітка:

<a id="example" href="/map/">link</a>

Javascript:

$(document).ready(function(){

    $("#example").click(function(){
        popup('/map/', 300, 300, 'map');
        return false;
    });

})

Перегляд

Ненав'язливий підхід JavaScript був хорошим у минулому - особливо посилання обробника подій у HTML вважалося поганою практикою (головним чином через onclick events run in the global scope and may cause unexpected errorте, що згадували YiddishNinja )

Однак ...

Наразі здається, що такий підхід трохи застарів і потребує певного оновлення. Якщо хтось хоче бути професійним розробником frontend та писати великі та складні додатки, тоді йому потрібно використовувати рамки, такі як Angular, Vue.js, тощо. Однак ці рамки зазвичай використовують (або дозволяють використовувати) HTML-шаблони, де пов'язують обробники подій в коді HTML-шаблону безпосередньо, і це дуже зручно, зрозуміло та ефективно - наприклад, у кутовому шаблоні люди зазвичай пишуть:

<button (click)="someAction()">Click Me</button> 

У raw js / html еквівалент цього буде

<button onclick="someAction()">Click Me</button>

Різниця полягає в тому, що в сирому js onclick подія запускається в глобальному масштабі - але рамки забезпечують інкапсуляцію.

То де проблема?

Проблема полягає в тому, коли початківець програміст, який завжди чув, що html-onclick поганий, і який завжди використовує, btn.addEventListener("onclick", ... )хоче використовувати якусь рамку з шаблонами ( addEventListenerтакож є недоліки - якщо ми оновимо DOM динамічним способом за допомогою innerHTML=(що досить швидко ) - тоді ми втрачаємо події обробники пов'язуються таким чином). Тоді він зіткнеться з чимось на зразок шкідливих звичок або неправильного підходу до використання фреймворку - і він буде використовувати рамки дуже погано - тому що він зосередиться в основному на js-частині, а не на частині шаблону (а також створює незрозумілі та важкі в обслуговуванні код). Щоб змінити ці звички, він втратить багато часу (і, ймовірно, йому знадобиться трохи удачі та вчителя).

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

То що робити?

Ми можемо ОБНОВЛИТИ ненав’язливий підхід JavaScript і дозволити зв'язувати обробники подій (зрештою, з простими параметрами) в html (але тільки прив'язувати обробник - не вводити логіку в onclick, як в ОП питання). Тож, на мою думку, у raw js / html це має бути дозволено

<button onclick="someAction(3)">Click Me</button>

або

function popup(num,str,event) {
   let re=new RegExp(str);  
   // ... 
   event.preventDefault();
   console.log("link was clicked");
}

<a href="https://example.com" onclick="popup(300,'map',event)">link</a>

Але нижче прикладів НЕ слід допускати

<button onclick="console.log('xx'); someAction(); return true">Click Me</button>

<a href="#" onclick="popup('/map/', 300, 300, 'map'); return false;">link</a>

Реальність змінюється, і наша точка зору повинна

Це нова парадигма під назвою " Ненав'язливий JavaScript ". Нинішній "веб-стандарт" говорить про окремі функціональні можливості та презентацію.

Це насправді не "погана практика", це просто те, що більшість нових стандартів хочуть, щоб ви використовували слухачів подій замість вкладеного JavaScript.

Також це може бути просто особистою справою, але я думаю, що набагато простіше читати, коли ви користуєтеся слухачами подій, особливо якщо у вас є більше 1 оператора JavaScript, який ви хочете запустити.

Я думаю, ваше запитання спровокує дискусію. Загальна думка полягає в тому, що добре розділяти поведінку та структуру. Крім того, afaik, обробник вбудованих клацань, повинен бути evalприведений до того, щоб він став справжньою функцією JavaScript. І це досить старомодно, але це доволі хиткий аргумент. Ну, добре, прочитайте про це @ quirksmode.org

• події onclick працюють у глобальному масштабі і можуть спричинити несподівані помилки.
• Додавання подій onclick до багатьох елементів DOM уповільнить
  продуктивність та ефективність.

Ще дві причини не використовувати вбудовані обробники:

Вони можуть вимагати нудних проблем, що уникають цитати

З огляду на довільну рядок, якщо ви хочете мати можливість побудувати оброблювач вбудованого рядка, який викликає функцію за допомогою цього рядка, для загального рішення вам доведеться уникнути роздільників атрибутів (із пов’язаною суттю HTML), і ви повинні вийти з роздільника, який використовується для рядка всередині атрибута, наприклад:

const str = prompt('What string to display on click?', 'foo\'"bar');
const escapedStr = str
  // since the attribute value is going to be using " delimiters,
  // replace "s with their corresponding HTML entity:
  .replace(/"/g, '"')
  // since the string literal inside the attribute is going to delimited with 's,
  // escape 's:
  .replace(/'/g, "\\'");
  
document.body.insertAdjacentHTML(
  'beforeend',
  '<button onclick="alert(\'' + escapedStr + '\')">click</button>'
);

Це неймовірно некрасиво. З наведеного вище прикладу, якщо ви не замінили 's, призведе SyntaxError, оскільки alert('foo'"bar')це невірний синтаксис. Якщо ви не замінили "s, браузер інтерпретував би його як закінчення onclickатрибута (з розмежуванням "s вище), що також було б невірно.

Якщо хтось звично використовує вбудовані обробники, потрібно буде обов'язково кожен раз робити щось подібне до вищезазначеного (і робити це правильно ) , що нудно і важко зрозуміти на перший погляд. Краще уникати вбудованих обробників повністю, щоб довільну рядок можна було використовувати в простому закритті:

const str = prompt('What string to display on click?', 'foo\'"bar');
const button = document.body.appendChild(document.createElement('button'));
button.textContent = 'click';
button.onclick = () => alert(str);

Хіба це не так приємніше?

Ланцюг застосування вбудованого обробника надзвичайно своєрідний

Як ви думаєте, що увійде наступний код?

let disabled = true;

<form>
  <button onclick="console.log(disabled);">click</button>
</form>

Спробуйте, запустіть фрагмент. Це, мабуть, не те, чого ви очікували. Чому він виробляє те, що робить? Тому що вбудовані обробники працюють всередині withблоків. Наведений вище код знаходиться у трьох with блоках: один для document, один для <form>, і один для <button>:

let disabled = true;

<form>
  <button onclick="console.log(disabled);">click</button>
</form>

Оскільки disabledє властивістю кнопки, посилання disabledвсередині вбудованого обробника відноситься до властивості кнопки, а не до зовнішньої disabledзмінної. Це досить контрінтуїтивно. withмає багато проблем: він може стати джерелом плутаних помилок і значно уповільнює код. У суворому режимі це взагалі не дозволено. Але з вбудованими обробниками ви змушені запускати код через withs - і не просто через один with, а через кілька вкладених withs. Це божевілля.

withніколи не слід використовувати в коді. Оскільки вбудовані обробники неявно вимагають withразом з усією його заплутаною поведінкою, слід уникати і вбудованих обробників.