Дивовижний світ веброзробки

#нове_відео "Співбесіда на сцені №2" нарешті вийшла! Чи можливо мати достатньо досвіду й знань, аби вважатися справжнім техлідом в 22 роки? Я ніколи в це не вірив, але Давид Касумов насмілився кинути виклик моїм упередженням. Чи вдалося йому мене переконати? Дізнаєтесь лише з нового відео! З вас вподобайка, обовʼязковий коментар під відео та поширення серд друзів, колег та родичів. Приємного перегляду! https://youtu.be/XCPPTNBNKB4

Чи можна відправити форму без JavaScript? Так. Ба більше, форми зʼявилися до JavaScript. І призначалися якраз для відправки даних на сервер. Але чому ми настільки звикли до обробки форм за допомогою JS, що це питання взагалі виникає? Не будемо вдаватися в глибокий історичний аналіз і зійдемося на тому, що потреби інтерфейсів змінювалися набагато швидше, ніж стандарти HTML. Та сама валідація (точніш, її історична відсутність), певні особливості перетворення форми на структуровані дані (чекбокси як масив, ага), не надто зручний UX для відправки файлів і так далі. Все це виправлялося усе новими й новими JS-бібліотеками, і врешті витіснило з колективної свідомості той факт, що форми, взагалі-то, і самі непогано вміють відправлятися. Щоправда, так само з перезавантаженням сторінки, але шо ж. Найпростіша поведінка за замовчуванням — це відправка GET-запиту на сервер.

<form>
  <input name="username" />
  <input name="password" />
  …
</form>

перетворюється на ?username=шпігун&password=таємно. Якщо ж вказати <form method="POST">, то дані підуть не в URL, а в тіло запиту як application/x-www-form-urlencoded. Пункт призначення задається через атрибут action, в якому можна вказати потрібний ендпоїнт. Файли. Форми вміють відправляти файли. Десь так року з 1995-го. Для цього достатньо вказати enctype="multipart/form-data", і бравзер відправлятиме вашу форму у вигляді так званого multipart message, тобто кожне поле — окрема частина, файл — теж окрема частина, зі своїми header, filename, content type і binary body. Тєлєк, духовка, два крісла Що ще нам для щастя треба? Наприклад, декларативно задавати різні сценарії відправки форми.

<form action="/article" method="post">
  …
  <button formaction="/article/publish">Publish</button>
  <button formmethod="get" formaction="/article/preview">Preview</button>
</form>

Як бачите, сама кнопка може перевизначати як метод відправки, так і призначення. Про валідацію перед відправкою всі вже, певно знаю, але згадаю побіжно: так, форми вміють у валідацію. Не таку супернаворочену, як із бібліотеками, але більшість випадків покриває. З цікавого — CSS нині має купу селекторів за валідністю значень в полі введення, як то :valid, :invalid, :required, :optional, :in-range, :out-of-range, що разом з іншими можливостями на кшталт :has відкриває майже безкрайнє поле можливостей зіпсувати ваш UX через стилі.

disabled поля у валідації участі не беруть (та й не відправляються взагалі), а readonly не блокує відправку, навіть якщо воно required і при цьому пусте. Ну бо користувач не може змінити його значення.

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

<iframe name="result" hidden></iframe>

<form action="/upload" method="post" target="result">
  <input name="title">
  <button>Send</button>
</form>

Тут нюанс в тому, що якщо щось піде не так з обробкою форми, то про це знатиме тільки iframe, а не ми. Ніхто не казав, що буде легко, це ж хак, а не best practice. А, ще форму можна сабмітити в межах сторінки тепер за допомогою dialog:

<dialog id="confirmDialog">
  <form method="dialog">
    …
    <button value="cancel">Cancel</button>
    <button value="confirm">Delete</button>
  </form>
</dialog>

dialog.addEventListener('close', () => {
  console.log(dialog.returnValue);
});

Насправді, базових можливостей форми без JS вистачає аби покрити переважну більшість випадків, просто ми вже звикли якось все переускладнювати. Якщо у вас не монструозна форма на десять екранів зі складними залежностями, швидше за все, вам цілком вистачить простого method="POST". Спробуйте. @babichdev

Шоб не знімати нове відео готую старе відео

Шоб не знімати нове відео знімав нове відео

Шоб не знімати нове відео знімав нове відео

Зібрали чи то на пів відео, чи то на пів резюме )

Я знайшов найгірше резюме веброзробника. І, що найжахливіше, воно — моє. Якщо за сьогодні зберемо 10 000 грн на РЕБ для 115 ОМБр, зроблю відеоогляд і розбір чому воно абсолютно жахливе зі сторони технічного інтервʼюєра. Зібрано: 25 693 грн Мета: 230 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743 P.S. У нас зʼявився дедлайн по збору — 19 травня.

*обіжено сопе* Це шо, ніхто не хоче в телевізор? https://forms.gle/nTk163B1KEJ7qeRG9

Товариство! 9 травня відбудеться зйомка нового випуску формату "Одне питання — три відповіді" у Львові. Шукаю одного джуніора, одного мідла і одного синьйора аби ставити їм різні хитрі запитання зі співбесід і потім душно розбирати кожну відповідь. Хочете потрапити в телевізор? Залишайте заявку ось тут: https://forms.gle/nTk163B1KEJ7qeRG9 Або пишіть мені особисто, це може суттєво підвищити ваші шанси потрапити в число учасників ;) Зйомка відбудеться за підтримки компанії appflame.

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

Так, ну а хто вже подивився відео, з вас по десять гривень. Бо збір на РЕБ для 115 ОМБр триває. Зібрано: 8 065 грн Мета: 230 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743

Як вдало розпочати новий робочий тиждень? Правильно — з перегляду нового відео! https://youtu.be/Fds47q02RNQ

Товариство, останнє нагадування! Svitla Systems розігрує бананку і крутяцьку парасольку (дивлюсь у вікно — актуально шо капєц) просто за те, що ви дасте відповідь на запитання у формі. Цього разу, до речі, єдино правильної відповіді немає, тож участь в розіграші братимуть усі, хто заповнять формочку до кінця сьогоднішнього дня! І ще — якщо зберемо достатньо відповідей, то окрім бананки й парасольки, ми розіграємо персональну консультацію від мене особисто. Скільки це достатньо? Ну явно більше, ніж є зараз ;) Чекаємо на ваші відповіді на "Питання від партнера"! https://forms.gle/rqHKzisACJxDsSCp9

Я так і не навчився вайбкодити. Увесь вайб зникає вмить, щойно у мене зʼявляється думка — "гм, а шо воно там нагенерувало?". Знаєте, є приказка "деякі двері краще не відкривати"? У випадку з LLM її можна переробити на "деякі файли краще не відкривати". Або навіть "всі файли". Я постійно заглядаю в ці файли, і результаті або це перестає бути вайбкодингом, коли я починаю робити вже серйозний сетап зі скілами, вікі та іншими правилами, або ж я дякую за напрямок і починаю писати сам. До речі, другий шлях мені подобається більше. Я дивлюсь на цей код, відзначаю, що я б зробив по-іншому і… роблю по-іншому. Чому для мене цей шлях кращий? Бо я впертий як віслюк в своїй недовірі до LLM, і через це постійно шукаю кращі, на мою думку, шляхи зробити те чи інше. Чи то інший архітектурний підхід, чи то використання іншого бравзерного API, чи моє улюблене "це вміє CSS". Певною мірою я можу сказати, що для мене вайбкодинг є потужним поштовхом для самовдосконалення, адже піддаючи сумніву кожне рішення LLM, я здобуваю нові знання. Проблема LLM в тому, що вони генерують усереднений код. Не такий, що підходить під цю конкретну задачу, а такий, яким в середньому є увесь той код, на якому LLM вчилась. А людство, в середньому, не є наймудрішою колективною свідомістю, будьмо відверті. Відмовляючись приймати посередність, я прагну знайти досконалість через нові знання. І часто це призводить до цікавих відкриттів. І нагадаю вкотре — я чітко розділяю вайбкодинг та AI assisted розробку. Радити в цьому випадку будувати пайплайни з агентів, створювати безліч скілів і будувати knowledge-wiki для маленького проєкту-досліду це усе одно, що радити рибалці, що сидить на березі ставка з однією вудкою, обовʼязково придбати 800 спінінгів і авіаносець для виходу у відкритий океан.

#css_in_action Анімуючи небуття Ми усі звикли до анімацій в CSS. Зокрема я зараз говоритиму про transition: воно змінює значення від початкового до кінцевого в залежності від часової функції на заданому часовому проміжку. І тут важливо згадати про дві умови: анімація не може відбутися, якщо немає так званого before-change style — попереднього відрендереного стану, від якого анімація може стартувати, а також якщо значення, яке ми намагаємося "оживити", не може мати проміжних станів, тобто є дискретним. В CSS обидві умови можна зламати, просто використавши display: none. Тривалий час задача "показати/сховати елемент і додати анімацію появи/зникнення" покладалась на JavaScript та його ненадійні таймери. Згодом зʼявилася дещо надійніші події на кшталт transitionend, але вони вирішували лише частину проблеми. Але сьогодні ця задача більше не є проблемою. CSS надає нам дуже цікаві інструменти, що дозволяють дещо більше, ніж просто "анімувати `display:none`". Мова про @starting-style та allow-discrete. Коли елемент переходить від display: none до "видимого" значення, за замовчуванням усі кінцеві значення властивостей застосовуються одразу, навіть попри transition-duration. Чому? Бо у елемента немає *початкового стану*, на основі якого можна розрахувати перий кадр анімації. Чому? Бо він на момент початку переходу просто ніколи не був *відмальований*. Це якщо ми говоримо про видиму зміну стану.

Примітка Елемент може не мати відмальованого стану з кількох причин. Наприклад, display: none означає, що елемент взагалі не бере участі в рендерингу, а от visibility: hidden значить, що елемент невидимий, але займає місце в макеті.

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

element {
  transition: 1s;
  display: none;

  &.visible {
   display: block;
   opacity: 1;

   @starting-style {
     & { opacity: 0; }
    }
  }
}

Таким чином можна додати анімацію не лише до display: none -> block, а й при вставці нового елементу в DOM. Тож, якщо коротко: @starting-style це шпаргалка, яку ми надаємо бравзеру, аби він зміг зрозуміти, як намалювати перший кадр анімації для елементу, у якого не було відмальованого (rendered) стану до того. Наступна проблема — анімація від видимого стану до "невідмальованого", і полягає вона в абсолютно іншому механізмі: оскільки дискретні значення анімувати неможливо, бравзер за замовчуванням просто "перемикає" їх на *початку переходу*. І саме тому намагаючись "анімувати" елемент в небуття від display: block до display: none ми не бачимо переходу, а лише миттєве зникнення. Це можна було б вирішити, якби можна було "відкласти" перемикання на потрібний нам час замість миттєвої зміни. І от якраз це раніше можна було вирішити виключно за допомогою JavaScript: або ставити таймери, або слухати події завершення анімації, і вже тоді "клацати перемикач" вручну. І, нарешті, цей механізм є і в CSS. Це значення allow-discrete для властивості transition-behavior. Він робить рівно те, що необхідно: дозволяє відкласти перемикання дискретної властивості на потрібний час.

element {
  transition:
    opacity 1s,
    display 1s allow-discrete;
  display: none;
  opacity: 0;
}
element.visible {
  display: block;
  opacity: 1;
}

Якщо ми приберемо .visible з елементу, то спочатку побачимо, як той поступово "зникає", і лише в кінці, коли opacity досягне нуля, display набуде значення none. Якщо коротко, то allow-discrete дозволяє визначити для перемикання значення дискретної властивості певну точку на часовій шкалі анімації, але з купою виключень, звісно. Які я вам пропоную дослідити самим. MDN: @starting-style MDN: allow-discrete *** @babichdev

Ще шість донатів не вистачає до нового допису. Маєте часу до вечора )

Подивіться трози смішного, може подобрієте і пару гривень закинете на збір. https://www.youtube.com/watch?v=4IbYcY0-va0

#коштозбір Товариство, збір на РЕБ для 115 ОМБр триває. Зібрано: 47 210 грн (+3055грн) Мета: 300 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743 P.S. Я дуже хочу написати один допис про крутяцьку фічу CSS, але не маю достатньої мотивації. Мотивація може зʼявитися, якщо сьогодні до вечора зʼявиться щонайменше 20 донатів.

#коштозбір Товариство, збір на РЕБ для 115 ОМБр триває. Зібрано: 44 155 грн (+1050грн) Мета: 300 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743

#розіграш А ще маємо "Питання від партнера", товариство. Svitla Systems розігрує бананку і крутяцьку парасольку (дивлюсь у вікно — актуально шо капєц) просто за те, що ви дасте відповідь на запитання у формі. Цього разу, до речі, єдино правильної відповіді немає, тож участь в розіграші братимуть усі, хто заповнять формочку до 13 квітня. https://forms.gle/rqHKzisACJxDsSCp9 І якщо ви ще досі з якихось причин не подивилися нове відео "Що робить Engineering Manager" — не зволікайте. Вийшло дуже цікаво.