Блог Senior JS-разработчика из Хельсинки Автор: @bekharsky По рекламе: https://telega.in/channels/htmlshit/card?r=GLOiHluU или https://t.me/it_adv Чат: https://t.me/htmlshitchat
Оценить канал htmlshit и оставить отзыв — могут только зарегестрированные пользователи. Все отзывы проходят модерацию.
5 звезд
0
4 звезд
0
3 звезд
3
2 звезд
0
1 звезд
0
Последние сообщения 4
2023-06-11 18:57:40
#статья дня
В Chrome 114, вышедший вот буквально пару недель назад, приземлился крайне любопытный атрибут: popover. Что это такое? Давайте посмотрим.
Добавленный элементу атрибут popover превратит его в неблокирующий (об этом ниже) диалог, удобный для меню, выбора вариантов, уведомлений, или отображения вспомогательных элементов формы. Собственно, сразу пример кода:
Pew-pew!
Что мы получаем из коробки: - Никакого теребоньканья скриптов - Никаких игр в z-index: 10000: всплывашке будет выдан свой слой - Клик вне элемента скроет его (нативный onClickOutside) - Захват фокуса и esc для закрытия
В отличие от dialog, как я уже сказал выше, всплывашка не блокирует взаимодействие со страницей и дополнительного контроля со стороны JS API не предоставляет. Dialog сильно старее и довольно спорен в целом.
В общем, читаем блог разработчиков Chrome: https://developer.chrome.com/en/blog/introducing-popover-api/
В статье: • исследование БД на основе популярного бенчмарк-теста YCSB; • «сравнение яблок и апельсинов» или небольшая ретроспектива в историю исследований баз данных SQL; • проверка производительности БД на разных сценариях.
Одно из самых интересных чтений на свете — это как принимались те или иные решения в уже готовом продукте.
Понятное дело, что новые проекты, т. н. greenfield, писать легко. Перед тобой чистый лист, гуляй не хочу, экспериментируй. Но потом...
Потом у твоего проекта появляются пользователи. И ладно если твои пользователи это просто посетители, а если твой проект — фреймворк или библиотека, а пользователи — разработчики, которые уже использовали твоё детище в своих продуктах?
Как убедить тех, кого убедить сложно, что были приняты поспешные решения, даже если они казались удобными? Как убедить людей в том, что им необходимо переписать свои продукты с учётом новых реалий?
И вот поэтому статьи вроде "Breaking React Query's API on purpose" — это настоящая золотая жила. Кто бы мог подумать, что такие простые вещи как события onSuccess и onError на самом деле могут приводить к проблемам и их придётся объявлять устаревшими?
Рекомендую не только пользователям React Query, если что.
Про caniuse.com говорить никому уже не приходится, это база, которая должна появляться как только ты набрал "c" в адресной строке.
Но иногда кому-то из нас приходится верстать... письма. И вот тут начинается веселье.
Да, огромное число людей пользуется веб-почтой, но не менее большое — использует различные клиенты, от мобильных до корпоративных. Да и веб-почта зачастую урезает возможности в вёрстке.
Для таких случаев придуман https://www.caniemail.com/
Всё то же самое, что Can I Use", но про почту.
Больше никаких "а может?.." Определяете целевую аудиторию — и поехали верстать.
Две недели назад я писал о том, что мой бывший коллега Даниэль Ющик создал Stylelint-плагин, помогающий привнести Defensive CSS-практики в ваш процесс деплоя.
Насколько я понял, не так много людей среди подписчиков в принципе используют линтеры стилей, полагаясь на встроенные возможности IDE. И, пожалуй, зря.
Впрочем, очень удачно подоспела и расширенная статья Даниэля об его плагине и в принципе о том, как настраивать Stylelint, включая демо-проект.