Yandex for Frontend
Канал для фронтендеров от Яндекса. Рассказываем о мероприятиях для фронтендеров и любителей красивых и функциональных интерфейсов, делимся экспертизой. Чат: https://t.me/yalovefrontend Каналы Яндекса про разработку: https://t.me/addlist/Hrq31w2p1vUyOGZi
Больше📈 Аналитический обзор Telegram-канала Yandex for Frontend
Канал Yandex for Frontend (@yandex4frontend) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 10 901 подписчиков, занимая 11 368 место в категории Технологии и приложения и 59 926 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 10 901 подписчиков.
Согласно последним данным от 23 июня, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило 5, а за последние 24 часа — -6, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 30.39%. В первые 24 часа после публикации контент обычно набирает 14.50% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 3 313 просмотров. В течение первых суток публикация набирает 1 581 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 15.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как интерфейс, yandex, typescript, css, фронтендеров.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Канал для фронтендеров от Яндекса. Рассказываем о мероприятиях для фронтендеров и любителей красивых и функциональных интерфейсов, делимся экспертизой.
Чат: https://t.me/yalovefrontend
Каналы Яндекса про разработку: https://t.me/addlist/Hrq31w2p1vU...”
Благодаря высокой частоте обновлений (последние данные получены 24 июня, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
intl-push:
title: Intl Push
triggers:
- on: commit
into: trunk
max-active: 1
flow: intl-push
Скрипт проходит по изменениям в PR, находит добавленные ключи и формирует из них список. Затем для каждого воркспейса запускает команду, которая отправляет все ключи из кода в TMS, и туда же попадают новые. Свежие ключи улетают через API в систему управления переводами.
Но отправка ключей — полдела, нужно ещё забирать готовые переводы обратно в код. Поэтому ровно в 05:00 по Москве запускается cron-job:
intl-pull:
title: Intl Pull
flow: intl-pull
max-active: 1
schedule:
timezone: MSK
cron: 0 5 * * *
Скрипт выкачивает переводы для всех 27 языков, раскладывает данные по файлам локализации в репозитории и сам создаёт Pull Request с изменениями. И, если тесты проходят, отправляет его на автоапрув.
🧽 А ещё мы добавили в CI дополнительную проверку на дубликаты, чтобы нельзя было случайно слить два PR с одинаковыми ключами.
⏮ В рамках проекта мы сделали дашборд, который помогает нам узнавать статус перевода на конкретный язык. В нём видно всё: синие столбцы означают ключи, у которых задача есть, а красные, что её нет. Если графа какого-то языка внезапно покраснела на 30%, мы сразу понимаем, что кто-то влил крупную фичу, а переводы застряли. Поэтому можем среагировать до того, как это заметит пользователь.
❗️ У нас есть правило: фичу открываем на конкретную страну только после появления переводов на нужный язык.
Английский и русский обязательны всегда. Если фича нужна только в России, она открывается только для российских парков. Если нужна на зарубежные рынки, то ждём, пока переводы доедут. Дашборд позволяет отслеживать этот момент в реальном времени.
🈶 Какую проблему подсветила автоматизация
Когда вы удаляете React-компонент — вы устраняете вызов <Message>. ID исчезает из кодовой базы, но в TMS он остаётся.
Мы тратили ресурсы на хранение того, что пользователь никогда не увидит. И на момент аудита в TMS накопилось около 4–5 тысяч таких ключей-призраков. Но у нас уже давно есть скрипт, который сравнивает слепок ключей в коде со слепком в TMS, поэтому их можно постепенно удалять.
🈶 Как мы сэкономили рабочее время
В среднем разработчики раньше заводили 2,5 задачи на перевод в день, тратили около 2 минут на каждую и 15 минут на обновление файлов. Это 20 минут ручной работы на команду ежедневно — достаточно, чтобы выбить из рабочего потока. Теперь всё это делает CI.
💡 И мы можем гарантировать: если код в мастере сегодня, перевод будет на проде через N дней. Менеджеры планируют маркетинговые запуски и релизы в новых странах с точностью до дня.
➡️ Читайте все подробности в моей статье на Хабре. Там я рассказала, как мы жили до появления автоматизации и как устраняли накопившийся лингвистический долг, чтобы насладиться её результатами. А также поделилась метриками и задачами на будущее.
Подписывайтесь:
💬 @Yandex4Frontend@media. Она позволяет интерфейсу адаптироваться под предпочтения конкретного пользователя: настроить тёмную тему, прозрачность, контрастность, включить или отключить анимации.
✨ Больше о @media в Доке
А на конференции «Я 💛 Фронтенд» Роман поделился и другими фичами, с которыми можно строить по-настоящему адаптивные интерфейсы. Этот подход отходит от классических вьюпортов и брейк-пойнтов: ключевую роль в нём играет контекст и окружение компонента.
➡️ Смотрите полный доклад на ютубе и в VK Видео.
Подписывайтесь:
💬 @Yandex4FrontendВы наткнулись на архивный FTP-сервер. Внутри — код масштабного проекта и дневник неизвестного разработчика. Релиз почти готов. Но часть системы вошла в бесконечную рекурсию: тесты падают, пул-реквесты конфликтуют, а финальный merge так и не произошёл…✨ Добро пожаловать в «Рекурсию по городу» — командное CTF-приключение для разработчиков, которое подготовили эксперты из Яндекса. Вам предстоит исследовать вечернюю Москву, распутать загадку проекта и починить реальность, чтобы релиз состоялся. В игре более 30 локаций, но какой маршрут выбрать и по какой стратегии двигаться — решать только вам. На каждом пункте нужно выполнить задание: найти правильный вход, понять фразу на табличке, увидеть предмет на фасаде или человека. Часть квестов зашифрованы в головоломках и математических задачках. Вы сами выбираете сложность и маршрут. Принять участие можно в двух форматах: 🟡 С командой — форму заполняет капитан и указывает данные всех участников 🟡 Самостоятельно — подберём вам команду для игры прямо на месте Когда и где: 📆 23 мая с 17:00 до 01:00 📍 Москва, «Красная Роза» ➡️ Присоединиться к приключению Подписывайтесь: 💬 @Yandex4Frontend
Omit<T, K>, ожидаете аккуратный тип без служебных полей, а вместо этого теряете автокомплит и только потом замечаете, что контракт уже превратился в {}. Ситуация знакомая и неприятная сама по себе, а в проде на on-premise-инсталляциях может обойтись особенно дорого: ошибка между фронтом и бэком здесь редко заканчивается «быстрым откатом».
В одном из кейсов Яндекс 360 проблема оказалась именно такой. На уровне кода всё выглядело разумно: есть union-типы событий и служебные поля вроде type и timestamp, которые не нужно передавать дальше. Значит, можно взять привычный Omit. Интуитивное ожидание — получить тот же union, только без пары ключей. Фактический результат может быть другим: тип схлопывается в {}.
Причина не в «магии», а в том, как устроен стандартный Omit. Внутри это Pick<T, Exclude<keyof T, K>>. И здесь важен keyof: для union-типов он видит только общие ключи всех веток. Если убрать именно их, Exclude возвращает never, а затем Pick<T, never> даёт {}. В этот момент исчезает видимая структура данных. Вместе с ней пропадает автокомплит, а это хороший практический сигнал, что контракт уже потерян и compile-time-защита работает не так, как ожидает разработчик.
Главный риск в том, что {} в TypeScript — это не полезная модель «пустого объекта», а тип, который пропускает слишком многое. Код продолжает собираться, но перестаёт надёжно описывать форму данных. Для систем, где строгий контракт между фронтом и бэком — часть эксплуатационной надёжности, это уже не частность типизации, а источник тихих ошибок. Runtime-проверки по-прежнему нужны, но и compile-time-слой не должен отключаться незаметно.
✨ Исправление есть, и оно практичное: включить дистрибутивность и применять Omit к каждой ветке union отдельно. Для этого подходит DistributiveOmit:
DistributiveOmit<T, K> = T extends any ? Omit<T, K> : never
Такой тип сохраняет структуру каждой ветки, возвращает нормальный union и вместе с ним — автокомплит, читаемость и ожидаемую типобезопасность. Это тот случай, где одна короткая утилита заметно повышает предсказуемость контракта и экономит время на поиск причин «странного» поведения уже после релиза.
Полезный вывод здесь простой: Omit над union-типами нельзя применять на автопилоте. Если T может быть union, итоговый тип стоит проверить отдельно — особенно если IDE внезапно перестала подсказывать поля. Исчезающий автокомплит в таких местах — не мелочь интерфейса, а повод посмотреть, не превратился ли ваш тип в {}.
➡️ В моём полном докладе с Я.Субботника — продовый кейс из Телемоста, разбор того, как keyof ведёт себя на union-типах и почему DistributiveOmit лучше сделать стандартным инструментом для таких сценариев. Посмотреть выступление можно на ютубе или в VK Видео.
🔻 Презентацию ищите под этим постом.
📺 А доклады остальных спикеров можно найти в плейлистах на ютубе или в VK Видео.
Подписывайтесь:
💬 @Yandex4Frontend@gravity‑ui/charts. Она опенсорсная, а я один из двух её core-контрибьюторов.
В основе библиотеки лежит декларативный подход. Пользователь передаёт в компонент один объект-конфиг: серии, оси, заголовок, легенду, тултип. Большая его часть легко сериализуется, логируется и передаётся между системами. А там, где декларативного описания недостаточно, конфиг принимает функции — кастомный рендерер тултипа, обработчики кликов, форматеры меток. Структура данных остаётся предсказуемой, а точки расширения явными.
Ещё один важный момент — гибридный рендер. Основным слоем выступает SVG. Он обеспечивает чёткие границы, масштабирование без потери качества и полный контроль над позиционированием. Но не умеет переносить текст и не поддерживает богатую HTML-разметку. Поэтому для тултипов, data labels с переносами и интерактивных элементов поверх графика мы добавили отдельный HTML-слой, который синхронизируется с координатами SVG.
И немного про производительность. Все взаимодействия с графиком (ховер, клик, движение мыши) проходят через централизованную шину событий на основе d3.dispatch. Это позволяет тултипу, легенде и crosshair реагировать согласованно, без прямых зависимостей. Но главное — движение мыши не вызывает перерендер React. На частоте ховера мы обновляем DOM напрямую через D3, а React подключается только там, где действительно нужно менять структуру или глобальное состояние.
➡️ В статье на Хабре я подробнее рассказал, зачем мы начали разрабатывать свою библиотеку и почему нам не подошли альтернативы, которые уже были на рынке. И по шагам расписал весь процесс миграции.
🧽 Библиотека @gravity‑ui/charts открыта под MIT-лицензией. Вы можете попробовать поработать с ней в вашем проекте: документация, storybook, гитхаб.
Подписывайтесь:
💬 @Yandex4FrontendAGENTS.md. Это стандарт для всех современных ассистентов. В одном файле мы прописываем:
🟡 Структуру директорий
🟡 Команды для сборки и проверки
🟡 Жёсткие правила: что можно, а что нельзя
Пишите только то, что модель не может узнать сама дёшево. Исследования показывают, что инструкции в повелительном наклонении («Используй CSS Modules для новых компонентов») AI выполняет в 94% случаев.
🈶 Второй уровень — контекст UI Kit
У нас есть внутренняя библиотека компонентов Orbita. Чтобы ассистент не генерировал несуществующие пропсы, мы разработали собственный MCP-сервер. Через него модель получает актуальный API компонентов, токены и паттерны композиции.
🈶 Третий уровень — связь дизайна и кода
Мы договорились с дизайнерами: Figma задаёт требования, а реализация остаётся за кодом. Инструмент Figma Code Connect описывает маппинг свойств. Теперь LLM видит, как называется параметр, и больше не путает enabled с isDisabled.
🈶 Что в итоге
AGENTS.md требует один день на настройку, MCP-сервер — около недели. Синхронизация с Figma наступает через 28 дней. Вложения окупаются, ассистент перестаёт гадать и начинает генерировать корректный код, который проходит дизайн-ревью с первого раза.
➡️ А в полной статье на Хабре я разбираю:
🟡 Как структурировать AGENTS.md, чтобы он работал, а не пылился в репозитории
🟡 Почему собственный MCP-сервер меняет правила игры для внутренних библиотек
🟡 Как синхронизировать Figma и код, чтобы ассистент перестал ошибаться в пропсах
Подписывайтесь:
💬 @Yandex4Frontend«Инфраструктурой Яндекса пользуются несколько десятков тысяч человек. Я представляю, кто эти люди, чем они занимаются и какие у них потребности. Со многими общаюсь, и связь с ними ближе, поэтому разрабатывать для них мне интереснее».🈶 Чем я занимаюсь сейчас Делаю инфраструктуру для коллег уже год 😌 Первой моей задачей стала разработка большой фичи для сервиса выдачи ресурсов. Раньше, чтобы получить GPU, команды вручную создавали тикет или писали запрос в одну из таблиц. Периодически заказы дублировались, возникала путаница, а выдача графических процессоров задерживалась. Мы добавили в наш сервис раздел про GPU. Теперь команде нужно просто заполнить заявку. Запрос согласуют без дополнительных таблиц и траты времени. Ещё я делал интерфейс Bootstrap. Он по шаблонам позволяет развернуть микросервис в инфраструктуре Яндекса, что существенно экономит время и силы. А теперь я занимаюсь доработками под продуктовые задачи и помогаю коллегам заехать к нам. ➡️ В блоге о работе в Яндексе я также рассказал, какие решения значительно упрощают и ускоряют работу нашей команды, и поделился небольшой историей о том, как пофиксил Ретродоску. 🧽 Кстати, заглядывайте в мой канал. Там я пишу об интересных вещах из мира фронтенда. Подписывайтесь: 💬 @Yandex4Frontend
Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
