#ссылка дня

Воскресных котов вам в ленту! Но просто котов вы можете найти где угодно, тут же — HTTP-коты: https://http.cat/

Знать коды протокола HTTP должен каждый веб-разработчик, чтобы не попадать в глупые ситуации и правильно пользоваться API. А раз их можно выучить, глядя на котов, почему бы и нет.

#http #handbook

#фишка дня

Селекторы атрибутов штука довольно удобная если правильно их использовать. Особенно хорошо они раскрываются с aria-атрибутами вроде aria-hidden, aria-pressed и так далее.

Да даже элементарные кнопки соцсетей весьма неплохо выглядят в виде data-social=“twitter”, чтобы не замусоривать пространство классов. Или вообще a[href*=“twitter.com”], если собрались на символах экономить.

В React строить API компонента на data-атрибутах тоже выходит весьма и весьма элегантно.

Вот только есть нюанс: селекторы атрибутов — регистрозависимы. Чтобы сделать их независимыми — стоит добавить модификатор i, то есть:

[data-social=“twitter” i]

Свалидирует

<div data-social=“Twitter”>
<div data-social=“twitter”>
<div data-social=“TWITTER”>

…ну и если хотите ровно наоборот — есть модификатор s. Но оно совсем новое и для частных случаев, которые по-умолчанию и так регистронезависимы (вроде type, checked, disabled).

#attribute #css #case

#продолжение дня

Собственно, помните, в сегодняшнем посте про атрибуты я написал, что на React они ощущаются максимально нативно и элегантно?

Ну ок, написал не так, но это в виду и имел.

Представьте жить в мире, где атрибуты были бы нормой.

И не data-бред, а любые. Не пришлось бы накидывать классы, создавать их композицию, выдумывать БЭМ, OOCSS и прочие методологии, превращающие вёрстку во что-то более-менее поддерживаемое на уровне API отдельных компонентов… Ладно, что-то я разошёлся по мотивам недавнего спора.

Короче, картинку я украл в твиттере Кричащего банана. Он норм пишет, моя рекомендация.

#attributes #css #react

#заметка дня

Пожалуйста, прекратите засорять глобальное пространство имён утилитами из npm/yarn.

Это я о чём:


$ npm i -g gulp
…bla-bla-bla
$ gulp


Не надо! Даже если документация говорит вам это сделать. Или, ещё хуже, рандомный ютубер или блогер.

Используйте для ваших локальных задач npm-скрипты:


$ npm i gulp
…create your scripts
$ npm run gulp


А для глобальных, скорее всего, есть инструменты получше.

Итак, как же работают npm-скрипты?

Если вы зайдёте в каталог node_modules, со всеми пакетами, там будет вложенный каталог .bin. Но вот исполняемых файлов, бинарников, там нет. А есть т. н. символические ссылки, симлинки. А вот уже они указывают на нужный файл в каком-либо конкретном пакете.

Как они узнают, куда указывать? Всё просто: в package.json нужного пакета будет, опять же, секция bin.

Итого, если node run xxx не нашёл скрипта с нужным именем, он полезет за ним в локальное пространство имён. Не найдя приложения в локальном пространстве имён, он полезет в глобальное и запустит приложение.

Почему это полезно?

Да потому что можно держать миллион разных версий gulp/webpack/vite/далее везде и не страдать по этому поводу. Работать будет всегда и везде. А если сюда приплюсовать nvm… Но об этом потом.

Кому интересны подробности, вот вам баззворд для лучшего понимания проблемы: PATH.

Задавайте ваши ответы, котаны.

P. S. inb4 npx

#js #node #run

#фишка дня

Надоело читать это: «To push the current branch and set the remote as upstream, use
git push --set-upstream origin fix/bug-1359»?

А всё потому что git на сервере не знает ничего о ветках на вашей машине. Нужно явно указать: «Хочу создать ветку на удаленном сервере с указанным названием и связать её с локальной». Названия даже могут отличаться, но чаще всего — совпадают. Ну, у меня, во всяком случае.

Поэтому, глядите чо: https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushautoSetupRemote

Ну или просто взгляните на КДПВ.

Завезли с версии 2.37.0, так что проверьте сначала. Спасибо за уточнение подписчику :)

#git #remote

#ссылка дня

Готовьтесь к большим изменениям!

…наверное.

Корчое, начиная с версии 108, Хром начнёт иначе реагировать на экранную клавиатуру: https://developer.chrome.com/blog/viewport-resize-behavior/

В чём разница, в двух словах?

Действие по умолчанию будет точно таким же, как на iOS: изменяться будет т. н. visual viewport (видимая область экрана) — то, что видно на экране в данный момент. На масштабе 100% видимая область экрана совпадает с layout viewport — область раскладки. Чтобы было проще понять, позиционированные с помощью position: fixed элементы прикрепляются к области раскладки, а не к видимой области.

Короче, суть в том, что в новом Хроме на андроид ваши зафиксированные элементы будут скрыты за клавиатурой. Как на iOS.

Но будут добавлены meta-атрибуты, чтобы это поведение изменить.

Демо-сайт, объясняющий новое поведение: https://viewport-resize-behavior.netlify.app/

#chrome #keyboard #fixed

#инструмент дня

Ты тоже верстать умеешь лучше, чем рисовать? Say no more!

Библиотека Satori от небезызвестной компании Vercel умеет конвертировать почти любой HTML-макет в SVG: https://github.com/vercel/satori

Зачем это надо?

Ну, например, автоматически генерировать OG-изображения для соцсетей. Или быстро сверстать — буквально — визитку и внедрить ее в ваш дизайн-макет. К слову, тут у кого-то из подписчиков была задача сгенерировать изображения таблиц. Или на карте точки расставлять и потом экспортировать в отчёт.

Короче, крутая штука же.

#svg #html

#ссылка дня

Недавно в нашем чате был жаркий спор на тему доступности. Мол, нормально делай — нормально будет и вообще морочить себе голову не надо, таких людей единицы.

Оно как бы и да и нет. Например, давайте представим себе на минуту средних дизайнеров сайтов и приложений.

Чаще всего они сидят в условиях, близких к идеальным. На стуле, перед большим монитором. И рисуют, не знаю, приложение для оплаты парковки. Он или она молоды и здоровы, мышка твёрдо лежит в руке. Идиллия.

Как по их представлению человек будет пользоваться приложением? Припарковался, устроился поудобнее и оплатил?

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

И так с любым проектом. Думать надо.

Собственно, вот и ссылка на сегодня: https://a11ymyths.com/ru/

Мифы о доступности на разных языках. Всем читать, котаны.

#a11y

#инструмент дня

Нужна карусель изображений на сайт? jQuery-плагины не катят? Swiper.js чёртов огромный монстр и уже набил оскомину? Slick.js глючный? Owl не поддерживается? Нужна интеграция с React, Vue, Svelte?

Встречайте: https://splidejs.com/

Splide написан на TypeScript. Лёгкий, быстрый, куча интеграций. Десятки примеров использования сразу на главной странице. Не портит SEO страниц. Lighthouse тоже очень даже зелёный.

Нет зависимостей и поддержка от IE10.

Просто праздник какой-то.

#slider #carousel #gallery #swiper

#ссылка дня

Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.

Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.

В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.

Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.

Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers

Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.

Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).

#docs #explainers #process

#фишка дня

Если вы любитель открывать кучу вкладок и нелюбитель использовать группы, для вас в Chrome есть прекрасное сочетание клавиш Ctrl-Shift-A или Cmd-Shift-A.

Это список вкладок с поиском! Очень удобная штука. Конечно, надо хоть немного помнить, что ты вообще открывал :)

Я просто к чему это, взглянул на экран «своего» джуна… ужас.

#chrome #feature #search

#ссылка дня

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

1. Собственно, введение в Git от GitHub: https://guides.github.com/introduction/git-handbook/

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

В их введении описывается, что такое вообще система контроля версий, репозитории, основы Git и GitHub (пулл-реквесты и т. д.)

2. Интерактивный сервис по изучению веток: https://learngitbranching.js.org/

Игра, практически. Красивое.

3. ProGit, второе издание: https://git-scm.com/book/en/v2

4. Книга от авторов GitTower — многим нравится иметь приложение на компьютере. Примерно то же самое, что в руководстве от GitHub: https://www.git-tower.com/learn/git/ebook/

5. Опять же, руководство от Atlassian — авторов конкурента GitHub, BitBucket: https://www.atlassian.com/git/tutorials

6. Основы от Роджера Дадлера: https://rogerdudler.github.io/git-guide/

Есть версия на русском.

7. Пошаговое руководство в основы и не только: https://gitimmersion.com/

8. Ещё одно: https://think-like-a-git.net/

9. Для любителей видеоуроков и конкретных решений: https://gitforeverybody.com/free-git-tutorials/

10. Ещё одно визуальное руководство: https://git-school.github.io/visualizing-git/

11. Ну и мой любимый универсальный сайт https://learnxinyminutes.com/docs/git/

Там не только Git, там вообще всё :)

Не переставайте учиться, котаны.

#git #linkdump

#статья дня

…я не говорю, что все поголовно вешают свои обработчики кликов на div. Но наверняка многие до сих пор используют ссылки (спасибо дизайнерам за унификацию). Или просто любой попавшийся элемент.

Не надо так.

Тег button с нами очень давно, его нужно лишь правильно приготовить. Иначе ссылки и кнопки будут выглядеть по-разному:

1. Сбросить стили браузера
2. Унифицировать с a
3. Добавить активных состояний (:focus и :active)
4. Правильно обработать клавиатурную навигацию (:focus-visible) дабы не раздражать нежные фибры души дизайнеров, но уважать остальных людей.

В общем, к делу. Сама статья: https://fvsch.com/styling-buttons

И готовый результат (я переложу его из статьи в CodePen, добавив стили поддержки :focus-visible): https://codepen.io/alinaki/pen/LYxbvOw

#css #button #focus #focusvisible

#статья дня

Если вы до сих пор не подписаны на блог Джоша Камю и не добавили его в RSS-читалки (олды тут?), то чего вы ждёте вообще?

У него вышла, как всегда прекрасно иллюстрированная интерактивными примерами, статья о CSS Transform: https://www.joshwcomeau.com/css/transforms/

Хотели заполнить пробелы в понимании, как трансформы работают? — самое время.

Перечислять, что конкретно он там описал, нет никакого смысла. Там есть всё.

#css #transform #animation

#видео дня

Да, я нашёл это на Reddit (но я хотя бы признаюсь в этом, в отличие от… 😇).

Оригинальное название — как создать визуальный XOR-эффект на одном только CSS filter и mix-blend-mode (инвертирование по маске, короче). Но для этого стоило бы заодно код переписать в кодпен…

Поэтому делаем так: теперь это видео о том, как использовать Emmet будто ты бог вёрстки.

Эффективность 9000, короче.

#emmet #filter #blend

#статья дня

Пожалуй, всё же эта статья будет статьёй дня. Хотя кто мне запрещал несколько в день? Никто, правильно.

Итак… Работа с WebGL-шейдерами в React через React Three Fiber!

Раз:
https://blog.maximeheckel.com/posts/the-study-of-shaders-with-react-three-fiber/

Два:
https://blog.maximeheckel.com/posts/the-magical-world-of-particles-with-react-three-fiber-and-shaders/

Целая серия (аж две!) статей о шейдерах и RTF, с интерактивными примерами и погружением не только в RTF, но и немного в основы WebGL вообще.

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

Всем шейдеров, котаны!

#webgl #react #rtf

#заметка дня

Заменили уже node-sass в своих проектах на sass?

Нет? А чего ждём?

Чем больше в компании людей на Apple M1, тем веселее становится поддержка проектов, использующих node-sass (libsass, сиплюсплюсовая реализация): он компилируется нормально только когда Меркурий в ретрограде. Или если не дышать.

А ещё оно deprecated уже года полтора: https://sass-lang.com/blog/libsass-is-deprecated

Сегодня набралась критическая масса таких людей у нас, поэтому я дропнул node-sass в пользу sass (релизация, написанная на Dart, DartSass; не спрашивайте).

Заодно убрал normalize-scss в пользу modern-normalize, ибо старый normalize уже не нужен.

На Webpack 5 переходить не буду, уйду на Vite.

Обновляйтесь, котаны.

P. S. речь о node-пакетах. Оригинальный отдельный sass — он на Ruby, RubySass :)

#scss #m1 #yarn #npm

#статья дня

Чему senior-разработчики могут поучиться у начинающих: https://stackoverflow.blog/2019/12/19/what-senior-developers-can-learn-from-beginners/

А теперь подтверждение тезисов статьи от, собственно, меня.

Случилось вот что: мы в шесть глаз просмотрели глупейшую опечатку.

В очень старом коде было повторяющееся условие проверки включения элемента в массив настроек:

settings.indexOf(“ADD_RESULTS”) !== -1

…и обратное к нему (=== -1).

Очевидно, было принято решение заменить его на переменную shouldAddResults и использовать везде.

И в этот момент и была допущена ошибка: заменив инверсное условие, мы забыли поставить оператор отрицания: “!”. И на ревью никто не заметил этого.

Почему? Потому что иногда лучше быть чётким в своих условиях, пусть даже код и выглядит странно. Очевидно, решение было плохим, но оно хотя бы было прямолинейным и чётко описывало условие. Раз три человека это пропустило, значит, и подход к рефакторингу был неверным изначально.

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

…и ещё пишите тесты, прежде чем влезать в логику старого кода, да.

#tdd #codestyle #refactoring

#фишка дня

Я давно ничего интересного про псевдокласс :has не приносил. Да-да, его ещё родительским называют.

Что если я вам скажу, что эффект на видео выше можно сделать не написав ни строчки кода на JS?

А вот как-то так:
https://codepen.io/jh3y/pen/abGPKGO

inb4 да, там есть JS, чтобы разбить текст на символы. Вы же не ожидаете, что кто-то это руками будет делать?

Меня в этом примере так-то вот что поразило:

.char:has(+ .char:hover)

Не, ну вы понимаете, понимаете, нет, что тут произошло сейчас?

Мы сослались на предыдущую букву от той, на которую навели мышь! Потому что у этой предыдущей буквы есть нижестоящий сосед, на которого мы навели, а значит, можно указать его селектор в аргументе псевдокласса :has!

🤯🤯🤯

CSS это весело, котаны.

#css #has

#инструмент дня

Всем же знакома ситуация с иллюстрации? CLS, Cumulative Layout Shift — одна из наиболее бесящих проблем при работе с несистемными, подгружаемыми шрифтами. Понятно, что шрифты это лишь одна из причин, но уж очень заметная.

Что же делать?

Можно сделать описание резервного, fallback-шрифта, на основе любого существующего системного и максимально уменьшить сдвиг. Адаптировать метрики, интерлиньяж, кернинг…

И вот именно этим занимается прекрасная библиотека https://github.com/pixel-point/fontpie

Вы генерируете нужные адаптации для вашего шрифта и указываете их как резервные.

Посмотрите пример на странице репозитория, впечатляет!

#font #css #cls

#заметка дня

Я тут сделал свой первый ESLint-плагин! Ну и, соответственно, ввёл в наши сборки новое правило. Но обо всём по порядку.

У «моей» среды исполнения JS — Google AppsScript — есть одна неприятная особенность. А именно: в глобальный скоуп попадают все переменные, объявленные на уровне модуля. Ну и, соответственно, они друг-друга могут перезаписать.

Вообще, про забавности в разных средах JS можно целую презентацию подготовить.

Проблему можно решить используя любой бандлер, но огромную базу легаси-кода перетащить в бандлер та ещё задача, плюс, надо соблюсти условия по видимости API, поскольку в среде есть свои соглашения по приватным и публичным методам.

Потому было решено проблему видимости исключить на корню: если тебе нужен полноценный модуль, используй классы и свойства класса соответственно. Если нет — убирай свои константы в функцию. Короче говоря, понадобилось запрещающее переменные на уровне модулей правило.

С плагинами для линтера есть одна проблема: почему-то нет возможности написать своё локальное правило, в рамках репозитория проекта. Надо обязательно создавать npm-пакет… но я не хочу. По крайней мере, не сейчас.

На помощь пришёл другой плагин: eslint-plugin-local-rules.

Великолепная штука, создал eslint-local-rules.js и поехали.

Но это всё было бы гораздо сложнее разрабатывать, если бы не ещё один инструмент: https://astexplorer.net/

Abstract Syntax Tree explorer: обозреватель абстрактного синтаксического дерева. Грубо говоря, ваш код разбивается на узлы и связи между ними: вот это — оператор, это — скобка, это — определение переменной, это — присвоение значения и так далее.

Анализируя это дерево (ну и конечно, документацию ESLint и исходники других плагинов) можно вполне себе быстро реализовать задачу.

Пишите плагины для ESLint, котаны. Это не больно.

…больно разгребать глупые баги :)

#eslint #javascript #ast