Тестирование типов TypeScript

Иногда проекты дорастают до такого уровня, что нужно проверять сами типы. Например, у вас в разных местах приложения есть типы, которые должны быть почти одинаковые, но одно приходит из бекенда и генерируется на основе какого-то контракта, а второе давно написали на клиенте, чтобы привязать к React. В такие моменты иногда возникает желание написать тесты на типы.

Адам Ракис из Spotify показывает по шагам, как написать тип TypesMatch<A, B>, который вернёт true, если типы и правда совпадают. Итоговый вариант выглядит просто, но интересно почитать, как к нему Адам приходит. А затем этот специальный тип можно использовать для тестирования существующих типов, банально запуская tsc на файлике с «тестами».

Знаю, что есть уже готовые библиотеки, который решают ровно такую задачу. В том же typehero.dev они активно используются. Но всегда интересно разобраться, как эти библиотеки под капотом устроены.

https://frontendmasters.com/blog/testing-types-in-typenoscript/

Как подсидеть тимлида

Видео выходного дня. Старенький, но всё ещё актуальный доклад Егора Толстого. Если вы уже тимлид или собираетесь им стать, помните:

- Тимлид не должен писать код всё своё рабочее время. Вообще-то его задача — команду развивать, а не быть самым классным разработчиком.

- Если хотите писать код — пишите. Главное, не берите блокирующие задачи, которые можете не сделать. Но если хочется писать код — можно. Я хоть уже давно ушёл в менеджерство, раз в пару недель трогаю код в своих проектах, закрываю простенькие баги.

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

- Если кажется, что вы ничего полезного не делаете («раньше вот код писал, а теперь просто по встречкам хожу»), то во-первых, вы не одиноки, а во-вторых, начните вести дневник выполненных дел. Я, например, уже 5 лет веду вики-страничку «Дневник доброжелюбного бородача», в которую записываю всякую важную активность: что делал, что улучшил, какой процесс запустил. Очень помогает приглушить синдром самозванца.

В докладе есть ещё несколько дельных советов, рекомендую.

https://youtu.be/aJv6uQMChm0

Что нового в браузерах за месяц

Ох, как же мне теперь удобно станет статистику для докладов собирать!

Патрик Броссет собрал страничку, которая берёт данные из пакета web-features (большой сборник веб-фич), склеивает это с browser-compat-data и раз в сутки самообновляется. В итоге можно не просто смотреть, какие фичи есть в браузерах, а отслеживать, что появляется в каждом отдельном браузере каждый месяц. Эдакий общий сборник релизов. Очень удобно.

Например, с мая text-wrap: balance работает во всех свежих версиях Interop-браузеров. А с апреля везде есть popover.

https://web-platform-dx.github.io/web-features-explorer/monthly/

CSS anchor positioning API

С нетерпением жду, когда все браузеры поддержат CSS Anchor Positioning. С ним ведь можно будет отказаться от отдельных библиотек для тултипов во многих случаях, всё на CSS — мечта.

Юна Кравец показывает и рассказывает, как работать с «якорями», какие новые свойства, директивы и функции появились в CSS. Поиграться можно уже в Chrome 125.

Статья с подробностями: https://developer.chrome.com/blog/anchor-positioning-api
Демка: https://anchor-tool.com/

Что не так с Emoji

Видео выходного дня.

В 2017 году Лёша Авдеев на конференции Web Standards Days в Минске рассказывал о том, как работают эмодзи в браузерах и операционных системах (да, именно с того дня я называю эмоджи эмодзи). Лёша показал, как собираются эмодзи из нескольких в один, какие шрифты отвечают за их отрисовку, как их обрабатывать при помощи JavaScript и почему соц. сети в итоге рисуют картинки, а не используют шрифты.

Думаете, что-то изменилось за 6.5 лет?

https://youtu.be/DUwZpLBSuiI

Единица измерения `cap`

Ахмад Шадид столкнулся с задачей, когда нужно между словами добавить расстрояние, равное высоте прописной буквы. И обычно такое решается подбором пикселей или em, если знаешь метрики шрифта. Особо искушённые пользователи CSS могут прикрутить ex. Но на самом деле современные версии браузеров умеют в единицу измерения cap, которая равна той самой высоте прописной буквы. Браузер ведь и так знает метрики шрифта, а значит может и эту высоту передать в CSS.

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

https://ishadeed.com/article/css-cap-unit/

<dialog> с заблокированным скроллом

Скорее всего у вас была похожая задачка: при показе всплывающего окна сделать так, чтобы за ним не скроллился контент. Обычно для такого при открытии модалки при помощи JavaScript на body добавляют overflow: hidden. Но у такого подхода есть пара недостатков:
- Нужен JavaScript там, где он как будто не должен быть.
- Контент за модалкой начинает прыгать, потому что скроллбар убирается, а это влияет на ширину страницы.

Крис Койер делится простым рецептом, как на современном CSS эти недостатки убираются:
- Вместо JavaScript можно использовать body:has(dialog[open]). Если модалки сделаны при помощи dialog, то такого селектора достаточно.
- На html можно добавить scrollbar-gutter: stable;, чтобы при открытии модалки скроллбар прятался из-за overflow: hidden, но место под него оставалось. То есть контент прыгать не будет.

https://frontendmasters.com/blog/scroll-locked-dialogs/

TypeScript 5.5

Подъехал сочный релиз. Безусловно, надо вчитываться в код в анонсе, чтобы понять детали, но вот, что меня радует из новинок.

1. Inferred Type Predicates. TypeScript становится всё умнее и учится понимать из контекста, с какими типами мы работаем. Например,

const definedEntities = entities
    .map(e => allEntities.get(e))
    .filter(e => e !== undefined);

definedEntities.forEach(e => e.doSomething());

Раньше такой код выдавал бы '' is possibly 'undefined'. Сейчас TS понимает, что выше по коду все undefined уже ушли. Можно будет убрать столько as из кода!

2. Проверка синтаксиса регулярных выражений. И на опечатки укажет, и подсветит, когда с именованными группами вы работаете не так, как надо. Экономия времени полезная получится.

3. Поддержка новых методов Set из EcmaScript. Там добавили всякие пересечения, исключения и прочие полезные операции не так давно. Теперь оно и в TS будет валидно обрабатываться.

4. Новый флаг --isolatedDeclarations, который будет приучать вас более явно задавать типы для экспортируемых сущностей. Особенно полезно, если вы генерируете .d.ts для ваших библиотек.

5. В конфиге теперь можно пользоваться переменной ${configDir}, чтобы ссылаться на папку, в которой конфиг находится. Если у вас разные конфиги в разных папках, проще будет эти самые папки перемещать по проекту.

6. Сам пакет TypeScript «схуднул» на 30%. CI/CD станут быстрее.

7. Больше нельзя написать type undefined = any;. Честно говоря, не знал, что раньше было можно, как-то не было необходимости такие подлянки в проекты вставлять. Но теперь совсем нельзя.

И ещё всякое разное. Скидывайте команде, чтобы был повод завести тикет на обновление TS в проекте.

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-5/

Модификаторы БЭМ и нативная вложенность в CSS

После того, как в CSS стало можно вкладывать одни селекторы в другие, как мы это раньше делали в препроцессорах, остался один важный кейс, который довольно быстро принесли фанаты БЭМ.

.block {
   &__modifier {
      color: var(--omg);
   }
}

Вот так в CSS написать нельзя, селекторы — это не строки, которые можно просто склеить.

Но Владислав Зубко нашёл решение.

.tag-list__tag {
  --background-color: var(--color-red-200);

  &[class*='--html'] {
    --background-color: var(--color-green-100);
  }
}

И ведь по сути да, если у элемента есть заданный класс, то у него сработает и селектор по атрибуту [class].

https://whatislove.dev/articles/bem-modifiers-in-pure-css-nesting/

CodeRun. Большой запуск

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

Сегодня мы выходим из беты! Случилось то, к чему я шёл несколько лет. Очень волнительно 🙂

Теперь у нас есть свой маскот Кодерун, новый брендинг, мультифайловые задачи, подборки, переработанная навигация, профиль участника. И будет ещё больше, бэклог ломится от интересных идей!

Так как я вообще-то фронтендер и хочу больше фронтендерских челленджей, то помимо нового сезона CodeRun мы запускаем скриншотные задачи — задачи, где надо подобрать вёрстку под картинку. Как иногда в проектах бывает, только ещё более пиксель-пёрфект.

Собрал для вас авторскую подборку задач, решать можно туть. Надеюсь, вам понравится сражаться с субпиксельными артефактами в градиентах 😉

А всей большой команде CodeRun хочу выразить огромную благодарность за то, что помогли реализовать мою старую мечту — сделать классный тренажёр с интересными задачами для тех, кто хочет развиваться и прокачиваться. Люблю вас! 💛

https://coderun.yandex.ru/

Как ты кодишь? Виталий Харисов

Видео выходного дня. У Сергея Бережного есть формат, где он зовёт знакомых разработчиков и допытывается, как у них настроен IDE, какие алиасы в терминале, какой стиль кода они используют и так далее. В этом видео Виталий Харисов, с которым мы какое-то время вместе работали в Поиске в одной команде и даже парно программировали, переписывая куски Бабули, показывает свой сетап.

Интересно посмотреть, как без всяких наворотов и плагинов, почти на стандартном наборе утилит, Виталий решает свои задачи порой быстрее, чем со всевозможными умными автодополнениями и улучшалками. Своими глазами видел :)

https://youtu.be/3grLGPuNBTo

Кастомные элементы не требуют дефиса в середине

Не знаю, зачем вам этот факт, но мне он показался интересным.

Думаю, у вас, как и у меня, где-то в голове было знание: «имена кастомных элементов должны содержать дефис (dash)». И я был уверен, что этот дефис должен быть в середине имени. Джим Нильсен выяснил, что нет.

<mytag-></mytag-> — это валидный кастомный элемент. Теперь живите с этим.

https://blog.jim-nielsen.com/2024/custom-elements-only-need-end-with-a-hyphen/

Классные анимации

Понравилась статья Эмиля Ковальски про то, чем отличаются посредственные анимации от классных анимаций. Откликается.

1. Классные анимации выглядят натурально. Не стоит везде использовать стандартные изинги, иногда надо посидеть поиграться с кривыми Безье или вообще сложить анимацию из нескольких частей.

2. Классные анимации — быстрые. Тут очень согласен. «Да, я понял, что анимация красивая, можно мне уже сайтом пользоваться?» — очень часто на красивых сайтах ловлю такую мысль.

3. У классных анимаций есть назначение. Изменение состояния, привлечение внимания, плавный переход между экранами — ок. «Смотрите, я научился вставлять анимации везде» — не ок.

4. Классные анимации — производительные. Если интерфейс зависает во время анимации, потому что анимация сделана на JS, а параллельно крутится майнинг какого-то очередного коина, удовольствия от такого интерфейса будет мало.

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

6. Классные анимации — доступные. Не забывайте, что есть люди, которым физически неприятно видеть некоторые виды движения. Уважайте настройки их системы.

7. Классные анимации сделать тяжело. Нужно приложить усилия. Но оно того стоит.

https://emilkowal.ski/ui/great-animations

Как руководителю внедрять изменения, чтобы двигать команду вперед и ускорять работу

Видео выходного дня. Олег Федоткин погружается в то, как приносить крупные инновации в большие компании. Мысли, которые захотелось записать:

- Компании, которые не меняются, умирают. Большинство самых богатых компаний мира 60 лет назад сейчас в этот список не входят.

- Эффективность и продуктивность ≠ работа «туда». Можно продуктивно заниматься ерундой.

- Внедрять изменения нужно не к дате и директивно, а к результату и для чего-то. Объяснять «что-то» важно всем участникам процесса.

- Top-Down инновация, когда изменения идут с самого верха структуры компании, похожа на скалу, о которую бьются волны. Чем больше уровней в компании, тем хуже такой подход работает.

- Внедрение нужно начинать с небольшой группы людей. Но даже тут может помешать теория диффузии инноваций. Или помочь, если уметь её применять.

- Для диффузии инноваций важно внедрять новое постепенно, ориентируясь на инноваторов и ранних адоптеров, которые сами в случае полезного внедрения сарафанным радио повлияют на остальных участников внедрения. Инноваторы любят что-то новое, чего нет у остальных. Это как Apple Vision Pro, который по сути своей пока бесполезен, но техноблогеры всё равно его хотят.

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

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

- Соберу-ка я список инноваторов вокруг себя, чтобы через них эффективнее внедрять новое.

https://youtu.be/7HKJf7HGnTY

Адаптивные графики на HTML и CSS

Матиас Шафер делится тем, как из бар-чартов (диаграммы с горизонтальными полосками, их ещё горизонтальными гистограммами называют) на SVG получилось сделать адаптивный вариант на HTML и CSS. Причём это хороший пример для полезного применения многострадальных сабгридов.

- Гриды позволяют размещать подписи, значения и сами полоски как угодно. Хоть влево, хоть вправо, хоть одно под другим.

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

- Доступность из коробки, потому что по сути график — это список значений. Как раз для списка сабгриды хорошо и подошли.

- При желании любое значение можно особым образом выделить, так как это обычный CSS. Добавил класс на ряд — и вот уже очень важное значение на графике выглядит тоже очень важно.

- В гридах можно накладывать одни элементы поверх других, поэтому получилось сделать шкалу с промежуточными значениями.

- Я бы добавил чуть больше математики на calc и CSS-переменных, чтобы ещё меньше писать лишнего в самом HTML. Прям просится в демках поправить.

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

- При желании такой же подход можно применить и к колоночным диаграммам. Или даже превращать их в горизонтальные гистограммы, когда экран маленький, а колонок много.

Хороший пример для вдохновения, чтобы с чего-то начать и доработать под себя.

https://9elements.com/blog/responsive-bar-charts-in-html-and-css/

Клавиатурная навигация для CSS-игры

Темани Афиф продолжает удивлять. На этот раз он показывает по шагам, как на HTML и CSS сделать игру, которая работает с кнопками-стрелками на клавиатуре для передвижения персонажа по экрану. В демке Марио собирает монетки на время и уклоняется от гумб.

1. Стрелки меняют положение скроллбара в контейнере. То есть если у нас есть большой контейнер со скроллбарами, мы можем как-то реагировать на стрелки, если скроллбар двигается.

2. Свежее свойство animation-timeline: scroll(neasert inline), scroll(nearest block); позволяет привязать анимацию к положению скролла. То, что нам нужно.

3. Прячем сами скроллбары через scrollbar-width: none;.

4. Размечаем кифреймы по каждой оси, чтобы получить нужные нам позиции монеток. В нужных кадрах выставляем значения CSS-переменных в 1 как признак того, что та или иная монетка собрана.

5. Используем Style Queries @container style(...), чтобы менять холст под значения переменных.

6. Щедро намазываем прототип препроцессорами, чтобы не писать весь этот код руками. На сдачу получаем возможность использовать рандом для генерации нескольких уровней.

7. Так как игра на скроллбарах, управление мышкой получаем из коробки.

Жду, когда Doom запустят на HTML+CSS и таких вот хаках. Кажется, недолго осталось.

https://frontendmasters.com/blog/how-keyboard-navigation-works-in-a-css-game/

Speculation Rules API для View Transition

Недавно браузеры начали у себя активно внедрять View Transition API для многостраничных сайтов, а не только SPA. Но у подобной красоты есть минус — браузер реально что-то рисует относительно поздно, прогрессивный рендеринг уже не работает.

Райан Седдон показывает, как при помощи ещё одного API, Speculation Rules API, ускорить показ красоты. Добавляете на страницу специальные правила, и браузер по ховеру уже через 200мс попытается отпререндерить будущую страницу. Это, конечно, даёт лишнюю нагрузку на сервера, но зато пользователь увидит то, что ему нужно, раньше.

https://ryanseddon.com/web/view-transitions-speculative/

Как собрать сложное расширение для Chrome

Нина Торгунакова в блоге Злых Марсиан по шагам собирает расширение для работы с сервисом Playbook. Сначала добавляет OAuth-авторизацию, пишет сам скрипт для сохранения медиа в локальное хранилище, затем добавляет пункт в контекстное меню браузера, обработку ошибок. И готовит расширение для публикации в Chrome Web Store.

Часто использую статьи марсиан как инструкции. Эта уже в закладках на случай, если захочу опубликовать какое-нибудь расширение.

https://evilmartians.com/chronicles/how-to-make-complex-chrome-plugins-a-zero-gravity-guide

Верстаем в прямом эфире

Точнее, верстать будет Полина Гуртовая, помогать ей будет Алёна Батицкая, а я буду давать комментарии. Решать будем задачи на вёрстку, которые я собирал для своей подборки на CodeRun.

Всё это состоится 18 июля в 20:00 по Минску. Приходите советовать советы и спрашивать вопросы в комментариях к стриму 🙂

https://news.1rj.ru/str/doka_guide/161

Разные способы спрятать что-то в DOM

Крис Фердинанди собрал полезную шпаргалку, в каком случае как лучше прятать элементы в DOM.

1. Свойство display: none. Прячет элемент полностью, контент элемента не читается скринридерами.

2. Атрибут [hidden]. Почти как display: none, только в HTML. Крис не пишет про это, но [hidden] легко теряет свою визуальную спрятанность, если поверх выставить display: block.

3. Свойство visibility: hidden. Прячет элемент, но оставляет вместо него пустое пространство. Контент элемента не читается скринридерами.

4. Класс .visually-hidden. Популярный набор свойств, которые заставляют элемент занимать нулевое пространство на странице, то есть быть визуально невидимым, но при этом оставляют содержимое читаемым скринридерами.

5. Атрибут [aria-hidden="true"]. Прячет содержимое от скринридеров, не влияет на визуальное отображение.

Статья Криса Фердинанди:
https://gomakethings.com/the-many-ways-to-hide-things-in-the-dom/

А ещё есть хорошая статья про прятание содержимого от скринридеров у Доки:
https://doka.guide/a11y/content-hidden/

Подводные камни In-app браузеров

Когда вы открываете ссылки в каких-нибудь нативных приложениях соц. сетей, они часто норовят открывать даже не WebView, а какую-то свою обёртку над WebView, которая имеет полный контроль над вашей страницей. Поль Эш-Лоран объясняет, почему такие обёртки — зло.

1. У них меньше функций, чем у браузеров. Просто потому, что операционные системы в принципе ограничивают WebView из соображений приватности и безопасности.

2. В In-app браузерах у вас вообще нет контроля над собственным кодом. Если какой-нибудь Cakebook решит вставить туда свой скрипт для «улучшения пользовательского опыта», то вы ничего с этим сделать не сможете.

3. Неконсистентный для пользователя UI/UX. Дизайнеры таких браузеров считают важным сделать что-то «удобнее оригинала», но забывают, что в основном пользователи сидят именно в обычных браузерах, поэтому там привычно. А сила привычки очень велика.

В 2022 году был скандал вокруг того, что Meta добавляет отдельный скрипт на каждую открываемую веб-страницу в своих приложениях, который отслеживает буквально каждое мельчайшее действие на странице. К сожалению, в 2023 году дело против Meta по этому кейсу было закрыто. TikTok делает так же. И не только они. Недавно Twitter/X зачем-то стал открывать страницы в первый раз в какой-то поделке, похожей на браузер, а во второй раз — в WebView.

Так и что с этим делать? Мы не контролируем собственные сайты?

В статье предлагается посмотреть на https://inappbrowser.com/ и https://inappdebugger.com/, которые помогают детектить, открывается сайт в обычном браузере или в In-app браузере. Плюс показывают код, который был внезапно вставлен на страницу извне.

Для Android можно использовать префикс intent: в ссылках. Так операционная система будет понимать, что вы хотите открыть именно дефолтный браузер в системе, а не In-app.

Также для любых ОС, если вы хотите сберечь пользовательские данные, можно задетектить, что страница открыта в In-app браузере, и вывести для пользователя инструкцию, как открыть страницу в нормальном браузере. Увы, требует дополнительной разработки, причём поди ещё угадай, какую инструкцию составить. Тот же Twitter очень дерзко в своём In-app браузере в принципе не даёт опции открыть в дефолтном браузере.

https://frontendmasters.com/blog/the-pitfalls-of-in-app-browsers/