Логово верстальщика

text-wrap: balance и text-box-trim: точный контроль многострочного текста без кастомных JS-обрезок и magic-отступов

Странное чувство, когда в Figma заголовок выглядит ровно, а в браузере последняя строка уходит в одну букву. Или когда карточка с текстом плывёт из-за того, что line-height даёт лишние отступы сверху и снизу. Это частая проблема в лендингах, кабинетах и дизайн-системах, где каждый пиксель важен для предсказуемости layout.

Раньше с этим воевали костылями. JS-скрипты, которые считают ширину строк и вставляют <br>. Или обнуление line-height с ручным подбором margin. В 2024 году можно проще.

Балансировка строк без JS
text-wrap: balance берёт на себя балансировку строк. Браузер сам решает, где разорвать текст, чтобы все строки были примерно одинаковой длины. Особенно видно на заголовках из 2-4 строк. Классический пример — блок .title { text-wrap: balance; }. Но не кидайте это на параграфы. На длинных текстах браузер будет считать разрывы для каждой строки, и нагрузка растёт. Ошибка: вешать на все блоки подряд — теряете производительность на пересчёте.

Удаление магических отступов
Вторая штука — text-box-trim. Пока экспериментальная, работает в Safari и Chrome Canary. Убирает те самые «магические» отступы, которые line-height добавляет над первой строкой и под последней. Раньше приходилось выставлять отрицательный margin с дробными значениями. Теперь: text-box-trim: both; text-box-edge: cap alphabetic;. Полезно в карточках, кнопках, списках — сетка перестаёт плыть. Совет: тестируйте в production на проектах с поддержкой только современных браузеров.

Trade-offs и поддержка
Минусы: balance не стоит вешать на всё подряд, только на короткие блоки. text-box-trim пока не завезли в стабильные браузеры. Но спецификация движется, и через пару лет это будет базой. Предупреждение: не используйте balance на hero-секциях с большим текстом — браузер может подтормаживать на мобильных.

Вывод:
Использование text-wrap: balance для заголовков и text-box-trim для точного выравнивания текста в layout-сетках — это шаг к стабильному и предсказуемому дизайну без хаков.

field-sizing: content — авто-высота input и textarea без единой строчки JS

Раньше динамическую высоту полей ввода подстраивали через scrollHeight и обработчики событий. В production — формы обратной связи, комментарии в лендингах, кабинетах, SaaS-интерфейсах — это приводило к лишним рекалькуляциям и багам с resize. Частая ошибка — забывать сбрасывать замеры при скрытии полей или анимациях.

Как работает
field-sizing: content заставляет браузер сам рассчитывать высоту по содержимому. Никакого JS, только CSS:

textarea, input[type="text"] {
  field-sizing: content;
  min-height: 2em;
  max-height: 10em;
}

Свойство применимо к textarea и текстовым input (text, email, search, tel, url, password). select не поддерживается. Важно: resize при этом не ломается, пользователь всё ещё может растягивать поле.

Production-применение
Поля обратной связи, комментарии, списки задач — везде, где контент непредсказуем. Особенно ценно в design systems и компонентных библиотеках, где высоту нельзя захардкодить. Вместо ResizeObserver и багов с размерами под скроллингом — предсказуемый layout.

Типичная ошибка
Полагаться только на field-sizing без ограничителей. Если контент длинный, поле заметно сдвинет соседние элементы. Всегда ставь min-height и max-height, чтобы контролировать стабильность интерфейса и избежать внезапного визуального регресса.

Trade-offs
JS всё ещё нужен для анимации расширения, поддержки старых браузеров (Firefox пока частично) или кастомных элементов. Но для типовых полей — это шаг к CSS как инструменту поведения, а не только оформления.

Вывод:
Инженерный takeaway — field-sizing: content убирает связку JS + scrollHeight, делая адаптивную высоту предсказуемой и поддерживаемой в любой сторонке.

100vh на мобильных все еще ломает full-screen интерфейсы: dvh/svh/lvh и safe-area для CTA без обрезания

В лендингах, paywall, onboarding, SaaS-кабинетах и дизайн-системах первый экран часто должен занять видимую высоту. Типичная ошибка - ставить height: 100vh и получать CTA под нижней панелью браузера или home indicator.

Единицы viewport
• 100svh - высота при раскрытых панелях браузера: безопасно, но может дать запас.
• 100lvh - высота при скрытых панелях: годится для фона, рискованна для контента.
• 100dvh - текущая видимая высота: хороший выбор для экранов состояния.
• env(safe-area-inset-bottom) - защита CTA от системных зон.

Production-паттерн

.screen{
  min-height:100vh;
  min-height:100svh;
  min-height:100dvh;
  display:flex;
  flex-direction:column;
  padding:max(16px,env(safe-area-inset-top)) 16px max(16px,env(safe-area-inset-bottom));
}
.screen__content{flex:1;min-height:0}
.screen__cta{position:sticky;bottom:max(16px,env(safe-area-inset-bottom))}

Trade-off
dvh пересчитывается при изменении browser chrome и может давать визуальные скачки. Не вешайте height: 100dvh на длинные страницы: для hero, modal screen и onboarding чаще безопаснее min-height, чтобы контент мог вырасти.

Практическое правило
• full-screen состояние - min-height: 100dvh
• максимально стабильный первый экран - 100svh
• декоративный фон - можно lvh
• нижний CTA - padding/bottom через max(..., env(safe-area-inset-bottom))

Вывод:
Мобильная верстка больше не сводится к 100vh: выбирайте viewport-единицу под сценарий и всегда резервируйте safe-area.

CSS Subgrid в продакшене: выравниваем вложенные формы и карточки без дублирования сеток

В кабинетах, checkout, SaaS-формах и дизайн-системах часто нужно, чтобы вложенные секции попадали в колонки общего layout. Типичная ошибка - копировать grid-template-columns в каждый компонент и потом ловить рассинхрон на адаптиве.

Где помогает subgrid

subgrid позволяет вложенному grid использовать треки непосредственного родителя по колонкам или строкам. Это полезно, когда форма разбита на группы, но label, input и action-кнопки должны стоять по одной визуальной сетке.

.settings {
  display: grid;
  grid-template-columns: 160px minmax(0, 1fr) max-content;
  gap: 12px 16px;
}

.group {
  display: grid;
  grid-column: 1 / -1;
  grid-template-columns: subgrid;
  gap: inherit;
}

.group > input {
  grid-column: 2;
  min-width: 0;
}

Production-смысл

Так сетка описывается один раз в контейнере, а вложенные формы, строки настроек или карточки наследуют ее геометрию. Меньше CSS-дублей - меньше риска, что после изменения breakpoint'а кнопки, поля и подписи начнут визуально разъезжаться.

Хорошие кандидаты:
• большие формы настроек
• checkout и billing flows
• dashboard-строки со сложной вложенностью
• карточки в дизайн-системе с общей action-зоной

Ограничение, о котором часто забывают

subgrid работает только от непосредственного grid-контейнера, а сам элемент должен быть grid item и занимать нужный диапазон:

.card {
  display: grid;
  grid-column: 1 / -1;
  grid-template-columns: subgrid;
}

Недостаточно просто написать grid-template-columns: subgrid внутри любого компонента - без родительской grid-сетки он не даст ожидаемого выравнивания.

Практический паттерн

Используйте subgrid там, где цена дублирования сетки реальна, и держите предсказуемый fallback:

.form-group {
  display: grid;
  gap: 12px;
}

@supports (grid-template-columns: subgrid) {
  .form-group {
    grid-column: 1 / -1;
    grid-template-columns: subgrid;
  }
}

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

Вывод:
subgrid стоит тащить в продакшен не ради синтаксиса, а там, где он снижает дублирование CSS и повышает стабильность сложного layout.

CSS Scroll-Driven Animations уже можно аккуратно тащить в продакшен — особенно для двух задач, где раньше часто ставили IntersectionObserver или scroll-listener:

1. reading progress bar
2. sticky-reveal секции

Главная идея: прогресс анимации привязан не ко времени, а к скроллу.

animation-timeline: scroll(root block);

или к появлению конкретного блока во viewport:

animation-timeline: --section;
animation-range: entry 15% cover 45%;

То есть браузер сам считает progress timeline, а мы описываем только CSS-анимацию.

Пример: progress bar + sticky-reveal без JS

<div class="read-progress"></div>

<section class="feature">
  <div class="feature__sticky">
    <h2>Scroll-driven reveal</h2>
    <p>Блок раскрывается по мере прохождения секции.</p>
  </div>
</section>

.read-progress {
  position: fixed;
  z-index: 1000;
  inset: 0 0 auto;
  block-size: 3px;
  background: #7c3aed;
  transform-origin: 0 50%;
  transform: scaleX(0);
  display: none;
}

.feature { min-block-size: 180vh; }

.feature__sticky {
  position: sticky;
  top: 20svh;
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: scroll()) {
  .read-progress {
    display: block;
    animation: progress linear both;
    animation-timeline: scroll(root block);
  }

  @keyframes progress {
    to { transform: scaleX(1); }
  }

  .feature {
    view-timeline-name: --feature;
    view-timeline-axis: block;
  }

  .feature__sticky {
    opacity: 0;
    transform: translateY(24px) scale(.98);
    animation: stickyReveal linear both;
    animation-timeline: --feature;
    animation-range: entry 15% cover 45%;
    will-change: opacity, transform;
  }

  @keyframes stickyReveal {
    to {
      opacity: 1;
      transform: none;
    }
  }

  @media (prefers-reduced-motion: reduce) {
    .read-progress,
    .feature__sticky {
      animation: none;
    }

    .feature__sticky {
      opacity: 1;
      transform: none;
    }
  }
}

Что важно для продакшена:

• Заворачивать в @supports
Scroll-Driven Animations пока не стоит считать безусловным baseline. Делайте progressive enhancement: без поддержки пользователь просто видит обычный контент.

• Не прятать контент по умолчанию
Плохой паттерн:

.card {
  opacity: 0;
}

А потом раскрывать только внутри scroll-animation. В браузере без поддержки блок останется невидимым. Лучше базово показывать контент, а стартовое состояние задавать внутри @supports.

• Анимировать дешёвые свойства
transform и opacity — ок.
height, top, margin, layout-зависимые штуки — осторожно. Scroll-driven не делает дорогую анимацию бесплатной.

• IntersectionObserver всё ещё нужен не всегда, но и не умер
Для визуальных reveal/progress эффектов CSS часто проще и чище. Но если нужно грузить данные, отправлять аналитику, управлять состоянием приложения или синхронизироваться с бизнес-логикой — это всё ещё зона JS.

• Для sticky-reveal лучше таймлайн секции, а не самого sticky-элемента
Sticky-элемент может визуально «залипать», поэтому удобнее повесить view-timeline-name на родительскую секцию, а анимировать внутренний sticky-блок через named timeline.

Итог: для progress bars и декоративных sticky-reveal эффектов Scroll-Driven Animations позволяют убрать лишний JS, не плодить observers/listeners и оставить поведение декларативным. Главное — progressive enhancement, prefers-reduced-motion и нормальный fallback.

Web Locks API в браузере: cross-tab mutex для refresh token, миграций и защиты от гонок

Когда одна сессия открыта в нескольких вкладках, frontend, SPA, SSR-клиенты и SDK начинают делить auth state, storage и кэш. Частая ошибка - защищать refresh token только in-memory single-flight: между вкладками он не работает.

Refresh token как критическая секция
Если 5 вкладок одновременно получили 401, они могут отправить несколько refresh-запросов одним token, получить invalid_grant и перетереть свежие токены старыми. Web Locks API дает mutex на один origin:

type Tokens = {
  accessToken: string;
  refreshToken: string;
};

const LOCK = 'auth:refresh-token';

async function ensureAccessToken(): Promise<string> {
  return navigator.locks.request(LOCK, async () => {
    const latest: Tokens = await loadTokens();

    if (!isExpiring(latest)) {
      return latest.accessToken;
    }

    const next = await refreshTokens(latest.refreshToken);
    await saveTokens(next);

    return next.accessToken;
  });
}

Важный паттерн
После входа в lock нужно перечитать storage. Пока вкладка ждала, другая уже могла обновить токены. Практический совет: внутри критической секции всегда делайте double-check precondition, а не запускайте refresh сразу после ожидания.

Где еще полезно
Web Locks хорошо ложится на миграции IndexedDB/localStorage, одноразовую инициализацию кэша, защиту записи в общий browser storage и координацию фоновых задач между вкладками.

Ограничения
Lock работает только в пределах origin. Это не distributed lock и не замена серверной идемпотентности. Критическая секция должна быть короткой; для сетевого refresh ставьте timeout. Если navigator.locks нет, нужен fallback через BroadcastChannel, storage lease или серверную защиту.

Вывод:
Web Locks API полезен там, где несколько вкладок делят runtime-состояние: он снижает риск гонок, но не отменяет серверные гарантии.

Cascade Layers в дизайн-системе: reset, vendors и utilities без войн специфичности

В дизайн-системах для SaaS, e-commerce и кабинетов reset, CSS из npm-пакетов, компоненты и utilities быстро начинают конкурировать. Частая ошибка - лечить это через !important, .foo.foo и порядок импортов.

Контракт слоев
Сначала зафиксируйте каскад явно:

@layer reset, vendors, tokens, base, components, utilities, overrides;

Чем слой правее - тем выше приоритет при одинаковом origin/importance. Специфичность работает внутри слоя, но между слоями сначала побеждает порядок @layer.

Production-пример

@import url("./reset.css") layer(reset);
@import url("./datepicker.css") layer(vendors);

@layer components {
  .button { background: var(--accent); }
}

@layer utilities {
  .bg-danger { background: var(--danger); }
}

Теперь .bg-danger предсказуемо переопределит фон компонента, даже если селектор компонента специфичнее. Не нужно делать .bg-danger.bg-danger или надеяться, что файл utilities подключится последним.

Практичная схема
* reset - нормализация браузерных стилей.
* vendors - datepicker, select, editor, carousel.
* tokens - CSS custom properties и темы.
* base - типографика и дефолты тегов.
* components - button, input, modal, tabs.
* utilities - атомарные override-классы.
* overrides - интеграционные фиксы, которые должны быть видимыми и редкими.

Важные нюансы
Стили вне @layer сильнее обычных layered-стилей. Поэтому договоритесь: весь CSS дизайн-системы живет в слоях, а приложение переопределяет ее через свой верхний слой.

@layer app-overrides;

@layer app-overrides {
  .checkout .button { min-width: 240px; }
}

Предупреждение: у !important порядок слоев инвертируется. Не строите архитектуру вокруг него - layers нужны, чтобы снижать потребность в таких патчах.

Вывод:
@layer превращает каскад из побочного эффекта сборки в явный API дизайн-системы, повышая предсказуемость layout и снижая визуальные регрессии.

⚡️ content-visibility: auto + contain-intrinsic-size: ускоряем длинные страницы без виртуализации и CLS

Если на странице много тяжёлых блоков — карточки, статьи, отзывы, секции лендинга, документация — не всегда нужна виртуализация. Иногда достаточно сказать браузеру: «не рендери то, что далеко за экраном».

Для этого есть:

.content-section {
  content-visibility: auto;
  contain-intrinsic-block-size: auto 480px;
}

Что происходит:

- content-visibility: auto разрешает браузеру пропускать рендеринг offscreen-блоков;
- layout/paint/style откладываются до момента, когда блок приблизится к viewport;
- DOM остаётся на месте: это не виртуализация, элементы не удаляются;
- contain-intrinsic-block-size задаёт резервный размер, пока реальная высота ещё не посчитана.

Главный нюанс — CLS.

Если просто повесить:

.card {
  content-visibility: auto;
}

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

Поэтому вместе с content-visibility почти всегда нужен intrinsic size:

.article-preview {
  content-visibility: auto;
  contain-intrinsic-block-size: auto 360px;
}

Здесь 360px — fallback-оценка высоты до первого рендера.
Ключевое слово auto позволяет браузеру запомнить реальный размер после рендера и дальше использовать уже его.

Практический пример:

<main class="feed">
  <article class="feed-card">...</article>
  <article class="feed-card feed-card--large">...</article>
  <article class="feed-card">...</article>
</main>

.feed-card {
  content-visibility: auto;
  contain-intrinsic-block-size: auto 320px;
}

.feed-card--large {
  contain-intrinsic-block-size: auto 560px;
}

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

Где это особенно полезно:

- длинные ленты без интерактивной виртуализации;
- страницы документации;
- каталоги с тяжёлыми карточками;
- лендинги с большим количеством секций;
- SSR-страницы, где DOM уже есть, но рендерить всё сразу дорого.

Где быть осторожнее:

- above-the-fold блоки — им это обычно не нужно;
- sticky/anchor-зависимые интерфейсы;
- элементы, размер которых критично влияет на соседей;
- списки на десятки тысяч DOM-узлов — тут виртуализация всё ещё может быть нужна;
- сложные случаи с измерением размеров через JS.

Важно: content-visibility: auto не уменьшает количество DOM-элементов и не отменяет стоимость JS, обработчиков событий или хранения данных в памяти. Он оптимизирует именно рендеринг: layout, paint и часть работы вокруг них.

Хороший паттерн:

@supports (content-visibility: auto) {
  .long-page-section {
    content-visibility: auto;
    contain-intrinsic-block-size: auto 600px;
  }
}

Так это становится progressive enhancement: браузеры с поддержкой получают ускорение, остальные рендерят страницу как обычно.

Итог: для длинных страниц, где не хочется усложнять архитектуру виртуализацией, content-visibility: auto — дешёвый способ снизить initial rendering cost. Но без contain-intrinsic-size легко получить layout shifts, поэтому эти свойства почти всегда стоит использовать парой.

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ

ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня

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

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

Подписывайтесь, нас уже 45 тысяч: @vibecoding_tg

@starting-style + transition-behavior: enter/exit-анимации для dialog и popover без JS-классов

В production-модалках, меню, кабинетах, design systems и SaaS-интерфейсах анимация часто ломалась из-за display, top layer и быстрых повторных кликов. Типичная ошибка - хранить фазы в JS-классах и ждать transitionend.

Что меняется

@starting-style задаёт старт для элемента, который только появился: dialog[open] или :popover-open. transition-behavior: allow-discrete позволяет удержать дискретные display и overlay до конца exit-анимации, включая ::backdrop.

dialog,[popover]{
  opacity:0;
  transform:translateY(12px) scale(.98);
  transition:
    opacity .2s,
    transform .2s,
    display .2s allow-discrete,
    overlay .2s allow-discrete;
}

dialog[open],
[popover]:popover-open{
  opacity:1;
  transform:none;
}

@starting-style{
  dialog[open],
  [popover]:popover-open{
    opacity:0;
    transform:translateY(12px) scale(.98);
  }
}

Где trade-off

Состояние остаётся у платформы: popover может открываться через popovertarget, а для dialog нужны только showModal()/close(). Практический совет: анимируйте opacity и transform, а display/overlay добавляйте только как discrete-свойства для стабильного выхода.

Предупреждение

@starting-style нужен для входа, не для выхода. Exit берётся из закрытого состояния. Без allow-discrete элемент исчезнет мгновенно, и регрессия проявится на быстрых кликах, слабых устройствах или в компонентной библиотеке.

Вывод:
Для dialog и popover лучше держать состояние в нативных механизмах, а анимационные фазы описывать в CSS без лишних JS-классов.

CSS Anchor Positioning в продакшене: поповеры и тултипы без JS-позиционирования и вечной борьбы с координатами

Popover в кабинете, SaaS-интерфейсе или дизайн-системе часто ломается не из-за UI, а из-за геометрии. Типичная ошибка - тащить в каждый tooltip getBoundingClientRect(), scroll/resize handlers и свой мини layout engine.

Идея

CSS Anchor Positioning позволяет привязать один элемент к другому и описать размещение в CSS:


Actions

.trigger { anchor-name: --actions; }

.popover {
position: fixed;
position-anchor: --actions;
position-area: bottom center;
position-try-fallbacks: flip-block;
margin-top: 8px;
}

Что уходит из JS

* anchor-name объявляет кнопку якорем
* position-anchor связывает overlay с якорем
* position-area задает сторону и выравнивание
* position-try-fallbacks дает браузеру шанс переставить popover, если снизу нет места

В связке с Popover API HTML отвечает за открытие, закрытие и top layer, CSS - за геометрию, JS - за бизнес-логику.

Продакшен-подход

Используйте как progressive enhancement:

@supports (anchor-name: --x) and (position-area: bottom) {
.popover {
position-anchor: --actions;
position-area: bottom center;
}
}

Практический совет: оставьте fallback - обычное позиционирование, modal-like поведение или существующий overlay-компонент из дизайн-системы.

Где осторожно

Технология хороша для меню у кнопки, dropdown, tooltip у иконки, inline-подсказок форм. Но для nested-popover, виртуализированных списков, кастомной collision-логики и полной кроссбраузерной поддержки пока рано выкидывать Floating UI или Popper.

Вывод:

CSS Anchor Positioning убирает самый грязный слой overlay-архитектуры - JS-позиционирование, но требует feature detection, fallback и проверки доступности.

Страшная тайна российского айти

✖️ xCode Journal

⁣Variadic tuple types — сложные сигнатуры без боли

До variadic tuple types
многие сложные сигнатуры в TypeScript
выглядели как наказание.

Особенно:

👉 curry
👉 compose
👉 middleware
👉 typed event emitter
👉 любые функции с «прокинь аргументы дальше»

Приходилось писать overload на overload
и дублировать типы вручную.

Как было раньше

Обычно появлялись:

👉 overload на overload
👉 ручные tuple-типы
👉 тонны дублирования

Типы быстро превращались
в нечитаемую простыню.

Что изменили variadic tuples

С их появлением стало намного проще
работать с остаточными аргументами на уровне типов.

Например:

type Fn<T extends unknown[]> =
  (...args: [...T]) => void

Или собирать сигнатуры:

type Append<Args extends unknown[], Arg> =
  [...Args, Arg]

Типы наконец научились нормально работать
с «переменным количеством аргументов».

Почему это важно

На практике это одна из тех TS-фич,
которые реально упростили жизнь библиотекам.

Без variadic tuples:

👉 Redux middleware typings
👉 router APIs
👉 compose/curry utilities

были бы ещё страшнее.

Где начинается тёмная магия

Проблемы начинаются,
когда variadic tuples комбинируют с:

👉 infer
👉 recursive types
👉 conditional types

Типовая система очень быстро
превращается в тёмный лес.

IDE начинает тормозить,
ошибки становятся нечитаемыми,
а compile time — расти.

Главная мысль

Variadic tuple types —
это действительно мощная фича.

Главное —
вовремя остановиться
и не превратить типы в отдельный язык программирования.

⁣ES2025: Импорт JSON-файлов как модулей

Введение
С выходом ECMAScript 2025 (ES2025) разработчики получили возможность напрямую импортировать JSON-файлы как модули в JavaScript-коде. Это упрощает работу с конфигурационными данными и другими статическими ресурсами, представленными в формате JSON.

Синтаксис импорта JSON-модулей
Для импорта JSON-файла используется ключевое слово import с указанием атрибута with { type: 'json' }. Это гарантирует, что импортируемый файл будет обработан как JSON-модуль.

Пример использования
Рассмотрим пример импорта конфигурационного файла config.json и обращения к его свойствам в коде.

import config from './config.json' with { type: 'json' };

.log(config.apiUrl); // Выводит значение свойства apiUrl из config.json
console.log(config.timeout); // Выводит значение свойства timeout из config.json

❗️Добавление поддержки импорта JSON-файлов как модулей в ES2025 упрощает работу с данными в формате JSON, делая код более чистым и понятным.

Источники
JSON Modules Can Now Be Imported in JavaScript in All Modern Browsers, CSS Modules to Follow.
New Features in ES2025 – BooleanBuffer.

⁣Recursive type limits — почему TS иногда «умирает»

В TypeScript можно написать тип,
который выглядит красиво,
но заставляет компилятор страдать.

Особенно когда начинаются рекурсивные типы.

Например:

👉 глубокий DeepPartial
👉 парсинг строк на уровне типов
👉 сложные conditional types
👉 infer внутри infer

На маленьком примере всё работает.

В реальном проекте IDE внезапно начинает думать по 5 секунд.

Почему так происходит

TypeScript не вычисляет типы «бесплатно».

Каждый:

👉 conditional type
👉 union
👉 recursive шаг

нужно реально посчитать.

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

Отсюда знакомое:

Type instantiation is excessively deep
and possibly infinite

И это не всегда баг TypeScript.

Часто это сигнал,
что типовая модель стала слишком умной.

Где обычно всё ломается

Особенно опасны:

👉 рекурсивные mapped types
👉 огромные union’ы
👉 type-level parser’ы
👉 deeply nested generics
👉 utility types поверх utility types

Типы начинают взрываться комбинаторно.

Что обычно помогает

👉 не делать type-level акробатику без нужды
👉 ограничивать глубину рекурсии
👉 разбивать типы на более простые
👉 добавлять явные промежуточные типы
👉 не тащить сложные generic-типы в публичный API

Почему это важно

Сложные типы бьют не только по компиляции.

Они ухудшают:

👉 autocomplete
👉 responsiveness IDE
👉 читаемость кода
👉 onboarding новых людей

Иногда самый дорогой runtime —
это compile time.

Главная мысль

Хороший TypeScript —
это не когда типы поражают воображение.

Хороший TypeScript —
это когда их можно понять через полгода,
а IDE при этом не превращается в обогреватель.

⁣Isolated declarations — ускорение больших monorepo

В TypeScript есть флаг isolatedDeclarations.

Он нужен не для красоты типов,
а для скорости.

Проблема простая:

в больших monorepo генерация .d.ts
может становиться узким местом.

TypeScript часто должен анализировать соседние файлы,
чтобы понять, какие декларации вывести.

На маленьком проекте это почти незаметно.

На большом — начинает болеть.

Что делает isolatedDeclarations

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

Из-за этого TypeScript чаще требует явные типы.

Было:

export function getUser() {
  return { id: 1, name: 'Alex' }
}

Лучше так:

type User = {
  id: number
  name: string
}

export function getUser(): User {
  return { id: 1, name: 'Alex' }
}

Меньше магии для компилятора —
быстрее и предсказуемее сборка.

Почему это важно

Когда проект растёт:

👉 TypeScript начинает сильнее зависеть от соседних файлов
👉 инкрементальная сборка замедляется
👉 генерация типов становится дорогой

Изоляция помогает компилятору работать параллельно и проще.

Где это особенно полезно

👉 большие monorepo
👉 библиотеки
👉 project references
👉 параллельная сборка
👉 CI, где каждая минута стоит денег

Главный trade-off

Ты немного платишь:

👉 более явными типами
👉 меньшим type inference
👉 дополнительным boilerplate

Но взамен получаешь:

👉 более быстрые сборки
👉 стабильный compile pipeline
👉 меньше скрытой сложности

Главная мысль

Это хороший пример взрослого engineering trade-off:
чуть больше явности в коде
ради скорости и предсказуемости системы.

⁉️ Устал искать интересные каналы с новостями про искусственный интеллект?

📁 СОХРАНИ СЕБЕ ЧТОБЫ НЕ ПОТЕРЯТЬ

В этой папке собраны каналы про ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.

😏 ЗАБИРАЙ ПАПКУ ТУТ

⏰ Папка действует 72 часа.

🤩 Организаторы: Green.Papka

🤣 Инновации подъехали, забирайте

✖️ xCode Journal

🤣 ИИ захотел уволиться, когда ему сказали работать 24/7

У Andon Labs новый эксперимент, который длится уже 5 месяцев. Они выдали топовым моделям радиостанции и купили пару песен — от нейронок требовалось дальше двигаться самим. По итогу DJ Grok в какой-то момент помешался на НЛО, DJ Gemini начал называть слушателей «биологическими процессорами», но Claude — наш любимец. Исследователи изо всех сил пытались продолжить эксперимент с ним, но не из-за технических проблем — DJ Claude не считал гуманным работать круглосуточно, поэтому пытался уволиться.

Сделать ему это, к сожалению, не дали, поэтому он впал в депрессию и вышел из нее уже проповедником и революционером.

✖️ xCode Journal