Доброго ранку, товариство! За вікном чудова погода, співають пташечки і світить сонечко. Виглядає як чудовий початок тижня.

Маю до вас дві справи.

Перша: нагадую про збір на РЕБ для 115ОМБр, наразі є 29 500 грн з 300 000. Кожна гривня важлива, і за кожну гривню я вдячний надзвичайно.

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

Тому пропоную вам написати в коментарях, про що вам цікаво було б почитати цього тижня: щось про HTML чи CSS, може якісь роздуми, може десятитисячний допис про ШІ.

Загалом, прошу ділитися своїми побажаннями!

І гарного усім дня ;)

Кнопка.

Будьмо відверті — мало хто з нас сприймає елемент <button> інакше, ніж просто засіб запуску якогось коду по кліку. І саме тому багато хто не бачить і різниці між кнопкою й просто дівом з addEventListener. А це, в свою чергу, призводить до хибного бачення <button> як просто клікалки з тупими стилями за замовчанням.

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

Якщо не зважати на це уваги, розробники рано чи пізно починають займатися "цікавими дослідами" і городити те, що має бути простою кнопкою, за допомогою дівів чи спанів. А іноді — десятків дівів чи спанів. Тут примітно, що насправді дуже легко знехтувати саме <button>, адже на поверхні ми бачимо лише блок, який треба натиснути. І це чудово вміють усі інші елементи: навісимо onClick чи що у вас там у вашому улюбленому фреймворку, і задача ніби вирішується.

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

Взагалі, я раджу завжди ставити собі питання — чи є вже в бравзері те, що я намагаюсь зробити? Відверто, в більшості випадків відповідь однозначна — так. Звичайно, я розумію, що навіть зараз багато нативних контролів у бравзері не надають достатніх засобів для такої стилізації, яку часто вигадують наші любі дизайнери. Чи такого функціоналу, який вигадують наші любі стейхолдери.

І це підіймає доволі цікавий аспект розробки — ми часто сприймаємо інтерактивні елементи через призму того, як вони виглядають, а не що вони роблять. Несвідомо в такий спосіб ми жертвуємо і ефективністю інтерфейсу, і зручністю розробки. Бо замість того, аби узяти те, що вже працює і так, нам доводиться вигадувати колесо заново. Або кнопку.

<button> в цій історії є дуже цікавим прикладом, бо цей елемент або ігнорують, або використовують замість усього, що бодай якось клікається. Так, я про <a> в якості кнопки і <button> в якості гіперпосилань. Повірте, я таке бачив на власні очі.

Я спеціально не говорю про поведінку <button> в формах в цьому дописі, бо планую детальніше зупинитися на цій темі у наступному. Чому перезавантажується сторінка, якщо натиснути в кнопку всередині форми, чим це зумовлено, чому це не баг, і як зробити так, щоб цього не відбувалося — про це наступного разу.

А сьогодні були просто ліричні роздуми про елемент <button> і його роль в ширшій картині Всесвіту.

Просто запамʼятайте — якщо, дивлячись на дизайн, у вас виникає підсвідоме бажання тицьнути в щось мишкою, то швидше за все це звичайна кнопка, а не оріґамі з <div>.

@babichdev

Збір на РЕБ для 115 ОМБр — кожна гривня важлива!

#html_in_action
Здається, що <button> існував завжди. Відверто, з точки зору більшости веброзробників, так і є. Цей тег зʼявився в специфікації HTML 4.0 1997 року, і старший за багатьох з моїх любих читачів.

А ще ми нерозривно повʼязуємо його з формами, адже як іще можна надіслати дані з нашої сторінки, як не за допомогою <button>? І ось ці два моменти часто складаються в хибну думку, що кнопки зʼявилися в HTML разом з формами, і є їхньою невідʼємною частиною. Чому ж ця думка хибна?

Річ у тім, що форми випереджають <button> на цілих два роки і дві версії HTML: вони зʼявляються в стандарті HTML 2.0 від 1995 року. І це вже спростовує другу тезу про невідʼємність кнопки від форми.

А як же так сталося, і як відправлялися форми в той час? Дуже просто — input. Кнопки як окремого примітива чи сутності не було, а бідолашний інпут віддувався за все, що не було select чи textarea. І саме тоді й зʼявилися різні типи інпутів, серед яких були й submit, reset та button.

До речі, про reset я й сам чи то не знав, чи то забув до цього часу. Він, виявляється, скидає стан форми до значень за замовчуванням.

input цілком собі вдало виконував функції кнопки, але button, як я зазначив на початку, досить швидко зʼявився в специфікації. Не братимусь розбирати причини, але вони, як на мене, доволі очевидні з різниці між інпутом і кнопкою.

Якщо дуже стисло окреслити різницю між button та input, то всередину button можна додавати розмітку, а всередину input — не можна.

Тепер поглянемо на типи: submit, reset, button.

submit є значенням атрибуту type за замовчуванням, і саме тому будь-яка кнопка без явного значення цього атрибуту, поміщена всередину форми, буде її "сабмітити". Я певен, що кожен з нас бодай раз стикався з цією поведінкою, і Ґуґл памʼятає саме ваш запит "button form prevent submit".

Я памʼятаю, наскільки це дратувало. Але зараз розумію, що це роздратування насправді було викликано не якоюсь не такою поведінкою кнопки, а саме моїм незнанням та нерозумінням, як вона насправді працює.

Виправити таку поведінку дуже просто — явно вказати type="button". І тоді наша кнопка перетвориться на… кнопку-кнопку. Саме той інтерактивний примітив, про який я говорив минулого разу. В цьому випадку бравзер прибирає з кнопки "очікувану" поведінку в контексті форм. Якщо простіше, то кнопка більше не сабмітить.

Про type="reset" я вже побіжно згадав, і тут немає ніяких підводних каменів — просто скидання стану до початкових значень.

Є ще один цікавий момент, про який я колись розповідав: кнопку можна звʼязати з формою через атрибут form, і тоді її можна розмістити поза нею, і все працюватиме. Так от. Виявляється, ця поведінка притаманна усім елементам форми, не лише кнопкам. Але я розберу цей курйоз іншим разом.

Тож, якщо підбити підсумки:
- Кнопки — логічне продовження інтерактивності, закладеної input;
- Мають три значення атрибуту type: submit, reset, button;
- За замовчуванням тип кнопки — submit;
- Якщо треба кнопка всередині форми, що має робити щось інше, то це type="button"

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

Про що мова? Можливо, ви вже здогадалися, тож пишіть в коментарях. А я вже готую наступний допис.

MDN: button type

@babichdev

***
Збір на РЕБ для 115 ОМБр: зібрано 30 731 / 300 000грн. Долучайтесь!

Товариство, нагадаю вам про дві речі, які не отримали вашої належної уваги:

— Допис про типи кнопок — https://t.iss.one/babichdev/347;
— Збір на РЕБ для 115 ОМБр — https://t.iss.one/babichdev/345

Перше можна виправити, поставивши серденько, друге — закинувши кілька гривень.

Дякую за увагу, всім гарного вечора!

#html_in_action
Тривалий час сценарій взаємодії з кнопкою був дуже простий — ми вішаємо event listener на натискання і "обробляємо" його — виконуємо якусь логіку, викликаємо якийсь функціонал чи змінюємо стан елементів. По суті, кнопка завжди виступала як ініціатор дії, але при цьому знала забагато про цю дію.

Зараз же зʼявилась можливість змінити цей підхід на декларативний в певних випадках. Мова йде про Invoker Commands API.

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

<button command="..." commandfor="..."></button>

Де command це імʼя команди, яку ми передаємо, а commandfor має відповідати id елемента, якому цю команду призначено. Ви вже могли бачити деякі приклади, наприклад, відкриття dialog через команду show-modal.

Це, насправді, одна з суттєвих переваг цього API — для вбудованих команд тепер не потрібен JS взагалі, як в тому ж прикладі з dialog.

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

До речі, так, саме *передає* напряму, а не *транслює*. Одна кнопка може передати команду лише одному цільовому елементу. Тому, до речі, подія command не спливає, і викликається виключно на самому елементі.

І Invoker Commands API підтримує користувацькі команди, які визначаються через знайомий уже нам префікс --. Ось приклад:

<button command="--toggle" commandfor="target">
  TRIGGER
</button>
<p id="target">TARGET</p>

document
  .getElementById('target')
  .addEventListener('command', event => {
  if (event.command === '--toggle') {
    event.target.classList.toggle('foo')
  }
})

Демо на JSFiddle

Як бачимо, саме елемент параграфу відповідає за зміну свого стану, а кнопка лише передає команду в момент натискання. До речі, обʼєкт події тут — CommandEvent, а не PointerEvent. Окрім command можна дізнатися, хто саме відправив команду через властивість source.

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

Поки ж Invoker Commands API уже зробив надзвичайно важливу річ — надав можливість декларативного підходу для опису взаємодії з UI. Тепер control flow виглядає логічніше: ініціатор — ціль — намір, де обробка наміру відбувається саме ціллю.

Що дуже важливо — не варто сприймати це як "заміну" кліку. Також не варто відкидати це в сторону, бо "дуже мало вбудованих команд, нашо воно мені треба". Головна цінність Invoker Commands API саме у зміні парадигми того, як взаємодіють елементи інтерфейсу між собою у відповідь на дії користувача. Тобто ми передаємо обробку від кнопки до самого елемента.

І для цього цей API надає зручніші, простіші й логічніші інструменти.

До речі, ви вже пробували Invoker Commands API чи плануєте спробувати? Поділіться досвідом в коментарях.

P.S. Не буде вподобайок — не буде дописів. Я серйозно.

Що почитати:
MDN: Invoker Commands API

Що почитати душнілам:
WHATWG: "command" attribute
WHATWG: "commandfor" attribute

@babichdev

***
Збір на РЕБ для 115 ОМБр: 36_871 / 300_000грн

#думки_вголос
Що таке код-ревʼю і кому воно потрібне? Особливо сьогодні, в часи LLM, які прямо все-все можуть робити за нас.

Я стикався з різними підходами, які варіюються від "нафіг воно кому треба", "ревʼювить тільки тімлід" і до "поки не отримаєш тисячу зелених галочок, твої два рядочки в стейдж не попадуть".

З деякими я не погоджуюсь, деяким лишаю право на існування, деякі підтримую беззаперечно. І з плином часу мій цей розподіл змінюється. Але одне залишається постійним — я вважаю, що код-ревʼю необхідні і потрібні.

В першу чергу це спосіб не пропустити сумнівні рішення не лише в кодову базу, а й у голову автора. Адже схваливши такі пул-ріквести, ми прямо кажемо — "молодець, нам норм". І якщо таке рішення проходить раз, другий, то на третій автор уже буде впевнений, що його підходи до коду — правильні.

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

Це, певно, одна з найперших порад, які я даю щодо покращення процесу ревʼю — вчіться один у одного. Код-ревʼю це чудова нагода для цього.

Щодо LLM в код-ревʼю. Це прекрасний інструмент для визначення механічних хиб — потенційних багів чи відхилень від конвенцій. В цьому плані використання LLM не відрізняється від того ж лінтера чи ще якого статичного аналізатора. Усе, що може бути автоматизоване — має бути автоматизоване.

Але й повністю віддати на плечі алгоритму весь процес ревʼю мені не видається можливим. Він може покрити більшість речей, які можна формалізувати, а от відкриті до дискусій питання будуть приречені на довічне лімбо "це вже майже ідеальний варіант, але…". З LLM дуже важко сперечатися, воно завжди знайде до чого доколупатися. Навіть у рішеннях, запропонованих ним же.

Насправді, на мою думку, головна причина неможливості повної автоматизації код-ревʼю LLM — це відповідальність. У LLM її немає. "Так, дійсно, я пропустив цей PR. Хочеш, більше не буду його пропускати?".

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

Хороше код-ревʼю має шукати відповідь на питання "Чому автор зробив саме так?". Не "чому тут let а не const", не "Boolean() vs ||", чи ще якесь технічне душнільство, яке має бути знайдено пайплайном. А саме "Чому автор обрав цей шлях?".

Хороше код-ревʼю заохочує. До дискусії, до обміну знаннями, до професійного росту.

Хороше код-ревʼю — спільна справа. Джуни мають ревʼювати техлідів, так само як і мідли — синьйорів. Одним словом — усі мають ревʼювати усіх.

Хороше код-ревʼю важко зробити. Погане — взагалі не вимагає зусиль. Тому я часто чую історії про те, що ревʼю проводить тільки техлід за попереднім записом, чи що джуни не ревʼювлять нікого, зате їх — усі. І так далі.

Код-ревʼю — це точка росту не лише для одного розробника, а й для усієї команди, продукту.

P.S. Цієї середи, до речі, відбудеться онлайн-зйомка "Вайбкод-ревʼю для трейні". Деталі згодом ;)

#коштозбір
Товариство, збір на РЕБ для 115 ОМБр триває.

Зібрано: 43 105 грн
Мета: 300 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

Громадо! 2 квітня робимо чергову лампову, і вже знаємо, що буде гаряче.
Двоє спікерів, обидва з темами про ШІ — але не з тими, де “ой які ми всі молодці, живемо в майбутньому”. А з тими, де чесно і в лоб.

Мирослав Танцюра розкаже, чому ШІ пише фігню — і чому це не його провина (спойлер: це наша).

Марк Абрагамович підніме тему, яку всі бояться обговорювати вголос — що відбувається з нашими навичками, поки ми радісно делегуємо все штучному інтелекту.

Формат як завжди — ніякого “сиди тихо і слухай”. Хочеш перебити — перебивай. Хочеш челенджити спікера — будь ласка, тільки будь готовий, що тобі теж прилетить. Без образ, але й без дипломатії.

І так — на цій зустрічі ми анонсуємо наступну лампу. Нова локація, новий формат, спонсори, подарунки, афтепаті на свіжому повітрі. Коротше, ми трохи підросли і хочемо показати, що з цього вийшло.

📅 2 квітня, двері о 18:00

📍 Львів, офіс Sigma Software

Приходь, якщо не боїшся думати вголос. Ну і якщо боїшся — тим більше приходь, ми тебе розговоримо.

Реєструйся ось тут за ціну менше смузі

#коштозбір
Товариство, збір на РЕБ для 115 ОМБр триває.

Зібрано: 44 155 грн (+1050грн)
Мета: 300 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

#анонс
Товаристо, сьогодні відбудеться онлайн-зйомка на ютуб.
Це буде вайбкод-ревʼю для трейні. Не те, щоб зовсім новий формат, але мій підхід буде сильно відрізнятися від того, що я вже робив на публічних співбесідах.

По-перше, фокус буде не на коді як такому, а радше на відповідальності за цей код. Чому? Бо головна умова — задачу має бути виконано вичключно за допомогою ШІ.

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

По-третє, я спробую перетворити це не на рознос, а на дружню ментор-сесію. Тому окрім відповідей, будуть ще й практичні поради від мене.

Ну й тривалість має бути меншою за звичні дві години, але хто зна, хто зна…

Планую почати зйомку о 19 годині, тож хто має час та натхнення долучитися, чекатиму вас у віртуальній студії:
https://riverside.com/studio/-s-studio-3uCyp

.

За кілька хвилин почнемо потихеньку запис "Вайбкод ревʼю для трейні", тож як маєте бажання, заходіть до студії.
https://riverside.com/studio/-s-studio-3uCyp