Мы вынесли компактную карточку банковской карты в entities/card/ui: маска номера, баланс и статус — решение казалось очевидным.

Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card, features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей.

Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview, сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary, затем заново прогнали ролевые тесты.

После этого на ревью мы стали обсуждать имя папки ближе к концу разговора. Сначала отвечали на другой вопрос:

Какие будущие изменения выбранная граница позволит оставить локальными?

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

В статье разберем, как собрать простой DI-контейнер на чистом JavaScript без TypeScript, декораторов и reflect-metadata. Заодно посмотрим, как применить его в небольшом DDD-примере с корзиной, репозиторием, скидками и разными lifetime зависимостей.

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

В Wails основными файлами, с которыми проходит 90% работы это index.html, styles.css, main.js, app.go. Остальные файлы мы либо не трогаем, либо настраиваем один раз в самом начале.

Для фронтенда я использовал стандартный html, css, js без современных фреймворков (так как я в них не разбираюсь). Frontend часть подробно рассматривать в этой статье не планируется, a html будет использоваться только чтобы показать, где используются js функции.

Привет, Хабр!

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

Когда я только начинал карьеру во фронтенд-разработке, то постоянно задавался вопросами: «Зачем на интервью просят обходить граф, если на работе я просто правлю CSS-отступы?» или «Зачем мне знать сложность O(N), если вёрстка всё равно ломается в Safari?» С развитием ИИ подобные вопросы стали звучать ещё громче: «Зачем мне вообще думать, если агент напишет этот цикл за меня?»

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

Пример реализации простого кэширующего прокси для пакетов npm, composer и pip на базе node.js для Windows и Linux.

Как с помощью бесплатных инструментов Google создать систему анализа данных: от сбора ответов в форме до визуализации на сайте. В качестве примера разберем исследование туристических предпочтений и настроим автоматическую отправку письма при достижении цели.

Хочу сравнить фреймворк Point0 и библиотеку tRPC. Делаю это, потому что квери и мутации в Point0 очень похожи по DX на tRPC, но более удобны ввиду того, что всё же Point0 это фреймворк и он может обладать возможностями, которыми библиотека не может:

Объявлять квери вместе с серверным кодом прямо в клиентских файлах, или наоборот

Автоматически гидрировать и дегидрировать квери клиент при включении SSR

В мутациях отправлять файлы автоматически превращая данные в FormData и обратно

Иметь стабильные индивидуальные урлы для квери и мутаций

Не заставлять зависать редактор кода при увеличении количества эндпоинтов

Возвращать в ответах с сервера на клиент целые серверные компоненты или интерактивные острова

Управлять внешним видом состояний загрузки на страницах и в компонентах

Кроме того, что описано в этой статье, Point0 может много чего ещё, но об этом в других статьях. Сейчас фокусируемся на сравнении с tRPC. Предполагается, что вы с tRPC более менее знакомы, но ниже я всё равно буду показывать примеры реализации на tRPC, чтобы сравнения были видимыми.

Цифровая идентификация и её значение для веба в последние годы стали темой горячих обсуждений. Они привнесли с собой множество спорных моментов: законы о проверке возраста и их влияние на онлайн-анонимность; Википедия потенциально будет вынуждена верифицировать в Великобритании личность пользователей; привязка к официальным операционным системам iOS и Android стала обязательным форм-фактором для кошельков цифровой идентификации; кроме того, стоит упомянуть ситуацию, когда американские цифровые аккаунты были закрыты потому, что их пользователь был судьёй Международного уголовного суда.

В своей истории я расскажу о швейцарской правительственной системе идентификации AGOV. Этот развёрнутый в 2024 году сервис сегодня насчитывает 1,6 миллиона аккаунтов и становится всё более необходимым: через него можно получать пособие по безработице, предоставлять налоговую декларацию (а это обязательное действие!) и выполнять множество других операций. В кантоне Цюрих это единственная возможность подачи заявления на гражданство.

В конечном итоге, я был вынужден создать аккаунт AGOV. К сожалению, его регистрация была довольно сложной задачей, пока я не нашёл причины странного бага accessibility. Вдохновившись статьёй «Просто дайте мне выделить текст», хочу представить вашему вниманию «Просто дайте мне ввести цифры».

Недавно я опубликовал большую обзорную статью о том, как несколько лет развиваю свой пет-проект, который постепенно превратился в собственную Function-as-a-Service платформу. Она позволяет принимать пользовательский JavaScript, Python или Go, запускать его в изолированном окружении и управлять такими функциями почти как в небольшом облаке.

В этот раз я хочу разобрать более узкую тему и рассказать, с чего вообще начинались мои эксперименты с выполнением пользовательского JavaScript в Node.js. Мы посмотрим на самые простые встроенные инструменты, а также проверим, способен ли V8 оптимизировать код, созданный динамически во время работы приложения.

Прошло больше года с момента публичного релиза первой версии OpenIDE. Сейчас ею пользуются на постоянной основе десятки тысяч разработчиков в сотнях российских компаний.

И практически с самого первого дня к нам начали обращаться крупные компании, не с просьбой добавить фичу, а с предложением заплатить. Потому что когда организация всерьёз рассматривает IDE для команды в несколько сотен человек, ей важно знать: есть договор, есть SLA, есть кто-то, кто несёт ответственность и завтра никуда не денется. Бесплатный open-source продукт эту уверенность не даёт сам по себе, как бы качественно он ни был сделан.

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

Так появилась OpenIDE Pro.

Я продуктовый дизайнер. И мне захотелось поэкспериментировать: можно ли уже сейчас сделать полноценное управление сайтом с помощью жестов. Да и ИИшки уже стали достаточно мощными. Так родился этот эксперимент. Для контента взял свое портфолио.

Получилось вот что. Страница встречает полем из частиц. Разрешаешь камеру, и частицы собираются в твоё объёмное отражение. Разделы висят вокруг силуэта и открываются рукой: наводишь палец, пункт заполняется и раскрывается. Текст листается щипком, фотографии берутся в кулак и растягиваются двумя руками. Дизайн при этом намеренно тихий: монохром, костяная типографика на чёрном, единственный цвет живёт внутри 3D-формы. Вся выразительность отдана взаимодействию.

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

Но есть интересное наблюдение. Существуют проекты, которые строили свои виртуальные машины на WASM, но отказались от него. Самый заметный пример - это Polkadot. Они спроектировали собственную PolkaVM на базе набора инструкций RISC-V и переключили исполнительный слой смарт-контрактов на нее (при этом сам runtime Polkadot по-прежнему компилируется в WASM). Если WASM настолько хорош, как заявляется, то почему для нового движка выбрали не его, а регистровую машину?

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

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

потому что нельзя просто взять redux и начать использовать в React. Необходима некая «react-redux» библиотека. А в чём тогда смысл талдычить, что «Redux works with any UI layer»?

Всем привет, на этот раз хочу провести обзор инструмента ng-virtual-scroll-view.

В предыдущей статье я делал обзор на универсальные виртуализированнные списки, которые "под капотом" использовали одноосевой виртуальный scroll-контейнер. Из проекта ng-virtual-list решил вырастить ещё один инструмент, двухосевой виртуальный scroll-контейнер ng-virtual-scroll-view. Инструмент также поддерживает версии Angular с 14 по 22.

С API и примерами использования можно ознакомиться в документации.

В начале этого века сотрудниками лаборатории С.Э.Шноля (ИТЭБ РАН) совместно с Арктическим и антарктическим НИИ РАН на станции Новолазаревская в Антарктиде была организована посекундная регистрация альфа-распада плутония-239. Получаемые с 2001 по 2010 год кремниевыми счётчиками данные записывались в файлы, суммарный объём которых составил около 1 Гб. Задачей этого продолжительного эксперимента было доказательство влияния космофизических факторов на альфа-распад, которое могло проявляться в виде суточных, месячных и годовых циклов. Подобная цикличность противоречит давно устоявшимся воззрениям на случайный характер радиоактивности, поэтому антарктические данные не помогли С.Э.Шнолю (1930 - 2021) поколебать эти воззрения. Но он искал (и находил) закономерности в повторении формы поминутных гистограмм альфа-распада, а это не самый наглядный способ их демонстрации. Намного проще просто понаблюдать за интенсивностью альфа-распада. Причём иногда изменения этой интенсивности имеют довольно странный характер, который невозможно объяснить колебаниями температуры, атмосферного давления, сетевого напряжения, грозовыми разрядами и наводками от ближайших научных приборов и бытовой техники.

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

📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее».

Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench.

Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости.

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

«10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».

История про то, как я сделал себе виртуального аватара для коротких видео — без генерации видео через ИИ.

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

В итоге получилась самодельная полуавтоматическая DIY‑система:

— универсальные графические ассеты персонажа
— ручная озвучка моим голосом
— разметка фраз в аудио через Audacity
— текстовый сценарий с управляющими тегами для событий в ролике
— кастомный JSX‑плагин для After Effects

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

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

В конце — немного статистики по первым трём роликам, запущенным с нулевых аккаунтов: YouTube, Instagram, TikTok и ВК.

До момента, когда я сел писать эту статью, я вообще не понимал, что такое тамагочи. Нет, не в смысле «никогда не слышал» — конечно, слышал и видел (не вживую, через экран). Где-то на уровне культурного шума это слово всплывало регулярно в американских фильмах или сериалах, где герой с придыханием вспоминает игрушку детства и рассказывает, как ему это нравилось. Ярче всего у меня в памяти отпечаталась сцена из знаменитого детективного сериала «Менталист»: Патрик Джейн с неизменной полуулыбкой вручает коллеге тамагочи, и тот, взрослый серьёзный мужик (не очень серьёзный на вид, но в момент моего просмотра все взрослые люди серьёзные), вдруг расплывается: «О боже, у меня в детстве такой был! Я их обожал! Как ты узнал!» и т. д.

Раньше я реагировал на такие моменты как на упоминание Game Boy или Dendy: «ну да, старая штука, скорее всего, что-то похожее на Game Boy, который мне был понятен на то время», и я думал: «кому-то дорога как воспоминание, но мне-то чего с того, игрушка есть игрушка». Но сейчас в какой-то момент мне стало понятно, что если об этой игрушке говорят до сих пор, если она пережила три десятилетия и кучу переосмыслений — значит, там внутри что-то большее, и надо посмотреть, что это и как работает.

Так я и сделал. И для начала — немного истории, потому что без неё нет смысла вспоминать и описывать старые вещи (всё, что больше 10 лет назад, уже старое, поэтому, надеюсь, без обид xd).

JWT не защищает от кражи. Подпись гарантирует, что токен не подделан, но не мешает злоумышленнику использовать его, если тот оказался в чужих руках. В 2026 году утечки токенов через XSS, логи и CDN-атаки входят в тройку самых частых векторов компрометации, а медианное время обнаружения такой кражи составляет 43 дня.

В этой статье разбираем полный жизненный цикл токена — от выдачи до отзыва. Сравниваем хранение в localStorage, HttpOnly-куках и BFF-прослойке. Объясняем, почему Refresh Token Rotation — это must-have, а не опция, и как детектировать кражу еще до того, как злоумышленник успеет навредить.

Копипаста редко выглядит как копипаста. После переименования переменных, строк и чисел два одинаковых блока спокойно проходят ревью как разный код. Я написал clone-alert, чтобы находить такие совпадения в TypeScript, JavaScript и шаблонах Vue, Svelte и Angular.

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

🇧🇷 🇨🇳 🇮🇳 Локализуем React не трогая код компонентов

React-компоненты из node_modules уже скомпилированы, поэтому внедрить react-i18next в них обычно невозможно без форка библиотеки. В статье показываю, как перехватить все вызовы jsx/jsxs через кастомный react/jsx-runtime и автоматически локализовать текст даже внутри уже собранных компонентов, не меняя их исходный код.

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

Я поразмыслил над тем, как сделать современную электронную книгу рецептов, и на выходе получил проект умного холодильника, где на каждый день задаешь меню, а программа сама считает пищевую ценность, содержание полезных веществ, анализирует, насколько питание полноценное и сбалансированное. Таким образом, можно быстро создавать себе меню на неделю, которое может оказаться идеальным для продуктивности в Ваших физических тренеровках. Но далее открывается вообще новый мир: автоматизация покупки продуктов, четкое понимание, что нужно взять в магазине, ясный взгляд, сколько раз стоит питаться, чтобы не было дефицита белка или витаминов, где стоит использовать БАД и так далее. Аппаратная часть – матовый сенсорный дисплей на магнитах, подключенный к старому относительно бесполезному до этого проекта ноутбуку.

В начале этого года я создал самую быструю JS-библиотеку для работы с цветом: парсинг различных форматов, конвертация в OKLAB/OKLCH, проверка попадания в P3-гамут и многое другое. Библиотека весит всего 7 КБ и не имеет внешних зависимостей. Высокую скорость обеспечили оптимизации под V8: мономорфизм, скрытые классы, ноль лишних аллокаций.

С самого начала TypeScript обещал обеспечить масштабируемость JavaScript. Строгая типизация и богатый инструментарий позволили разрабатывать нетривиальные, высококачественные приложения под любые платформы.

В прошлом году наша команда анонсировала следующий шаг в масштабировании TypeScript: нативный порт на Go, который использует все возможности современного железа. Порт сделан максимально точно: новый код воспроизводит структуру и логику оригинальной кодовой базы, чтобы результаты двух компиляторов совпадали.

Ключевое отличие — TypeScript 7 использует скорость нативного кода, разделяемую память при многопоточности и ряд новых оптимизаций. В итоге полная сборка ускоряется в 8–12 раз.

Полгода я жил в одном и том же цикле. Собираешь скрапер, вечером он проходит все страницы, а к обеду следующего дня отдаёт сплошные капчи и 403. Добавляешь puppeteer-stealth, сверху ещё десяток заплаток, гонишь трафик через резидентные прокси, и всё равно на третьи сутки прилетает бан. Я устал чинить симптомы и сел разбираться, что именно нас выдаёт.

Десять дней разработки — и язык, на котором держится веб. В этой статье — история JavaScript и инструментов, которые привели его к этому.

Прошло полгода со времени публикции первого сравнения. Мир ИИ стремительно развивается, поэтому эксперимент пора повторить.

Это продолжение моей статьи о том, как я сделал движок совместимый с GTA San Andreas для запуска в браузере, рекомендую сначала прочитать:

https://habr.com/ru/articles/1051828/

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

Я не пытался сделать «приватный мессенджер» и вообще не думал про слежку и прослушку.

В один день мне просто надоело, что созвониться с человеком — это настоящая проблема: блокировки, включи-выключи VPN, а любой новый аналог встречает регистрацией с десятком полей — а теперь местами ещё и просьбой показать паспорт.
За ночь я собрал прототип голосового чата по принципу «ничего лишнего» — и уже потом с удивлением понял, что этот же принцип случайно сделал разговор в нём таким, что подслушать его со стороны физически негде.

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

В прошлых статьях я уже подробно разобрал базовую инфраструктуру Matomo: как развернуть систему на собственном сервере LAMP, рассчитать нагрузку, выстроить правильную архитектуру сайтов, measurable и Roll-Up аналитики внутри Matomo. Но вся эта серверная часть — только фундамент. 

И сегодня мы наконец переходим к самому важному слою Matomo — tracking-коду и архитектуре отслеживания пользовательских действий.

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

Angular часто воспринимают как тяжёлый корпоративный фреймворк «из прошлого»: сложный вход, много правил, меньше хайпа, чем у React. Но за последние годы фреймворк заметно изменился: появились сигналы, обновился SSR, стало проще начинать, а экосистема перестала быть закрытым «котлом» только для энтерпрайза.

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Олегом Щёголевым — frontend-разработчиком, преподавателем, ментором и специалистом по Angular автором Telegram-канала «SUMMON_THE_CODER».    

В этом выпуске мы разбираем путь в профессию, реальные проекты, ситуацию на рынке труда, зарплаты, использование нейросетей в разработке, статус GDE, современный Angular, сигналы, SSR, CLI, директивы, модули и главный вопрос: почему React популярнее, но крупные компании всё равно продолжают выбирать Angular.

Эта идея появилась у меня давно.

Когда мы внедряли BI в крупном банке, я заметил одну вещь: больше всего внедрению радовались руководители. У них появлялись дашборды, графики, показатели, визуальная картина происходящего.

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

BI хорошо показывает, что что-то изменилось: появилась аномалия, просел показатель, выросло значение, изменилась динамика. Но после этого почти всегда возникает следующий вопрос: почему так произошло?

И вот тут уже приходится разбираться не с графиком, а с данными.

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

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

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

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.

9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до god object на 1690 строк и бросил AI-кодинг. Я узнал в этом свою историю полугодовой давности, но вывод сделал другой.

Решил я поиграть на выходных в Carmageddon. Но вот незадача!- Заводить всё это в эмуляторе DosBox нет никакого желания (он стоит у меня для других целей, ну вы понимаете))- То что мы с Сашей Гурьяновым делали на DosZone у меня тормозит, так как не вывозит мой старенький процессор. Пора уже собрать комп для нашей ДОС Зоны))- Ремейки типа Carmageddo: Max Damage и Reincarnation полная фигня. Куплено в стиме и полно разочарования

Что же делать? Будем сами портировать в браузер! Всё как мы любим. Для эксперимента и развлечения ради!

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

Привет, Хабр! Меня зовут Оля Борисова, я фронтенд-разработчик в ПСБ. Работала как в продуктовых, так и в платформенной команде. Сегодня хочу поделиться нашим опытом разработки внутренних пакетов, их релизным процессом, расскажу какие проблемы у нас были, а также постараюсь дать советы тем, кто еще в начале пути.

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

Так было не всегда, когда-то у нас был один проект и все что с ним связано (компоненты, хелперы, конфиги и прочее) хранилось внутри него. Это работало пока не появилась надобность переиспользования наработок и лучших практик в других приложениях и направлениях. Так мы пришли к тому, что нам необходимы внутренние пакеты и механизмы их организации и менеджмента.

Красная волнистая линия под строкой раздражает, и самый быстрый способ её убрать — дописать any, as или !. Компилятор замолкает, сборка зеленеет, PR уходит дальше. Вот только ошибка никуда не делась: она переехала из редактора в рантайм, поближе к пользователю.

За годы ревью — чужого кода и своего — я привык читать эти три символа как сигнальную лампочку. Они почти всегда отмечают место, где тип не описан, а выключен. Иногда это осознанный и оправданный выбор. Гораздо чаще — способ не разбираться прямо сейчас, счёт за который приходит позже и другому человеку.

Поэтому на code review я задаю не привычное «как затипизировать, чтобы TypeScript замолчал», а обратный вопрос:

Что именно я здесь отключаю — и правда ли без этого нельзя?

Веду frontend-команду, много времени провожу в чужих диффах, и про any, as и ! у нас постепенно сложился небольшой свод договорённостей для review. Из него и выросла эта статья: 13 сценариев, которые складываются в один короткий фильтр. Для каждого есть пара «плохо → хорошо» и рабочий пример на TypeScript 6 — всё можно потрогать в playground (он написан на React, но сами приёмы относятся к TypeScript в целом). Разберём any и unknown, сужение и type guards, satisfies, as const, оператор ! и валидацию данных на границе.

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

Типы — это проверяемые обещания о данных. any, а также необоснованные as T и !, позволяют компилятору принять такое обещание без доказательства. Если тип неизвестен — это unknown и сужение; если известен, но невиден компилятору — это guard, валидация или контролируемый инвариант, а не слепое утверждение.

На code review я регулярно встречаю один и тот же вопрос, только записанный разным кодом: «Как правильно синхронизировать эти значения через useEffect?»

Со временем я понял, что чаще полезнее спросить иначе: а эффект здесь вообще нужен?

В статье разбираю 12 типичных сценариев из React-код-ревью: производное состояние, события, цепочки эффектов, внешний store, useEffectEvent, загрузку данных и современные подходы React 19.2. Для каждого случая — пример «плохо → хорошо» и практический фильтр, который помогает выбрать между рендером, обработчиком события, Action, useEffect или query-библиотекой.