Dev News от Максима Соснова

When and what should I be logging? Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм. Итак, что надо логировать: Runtime decisions. В коде часто есть ветвление по различным условиям — по условиям типа isMobile, по фичефлагам. Вот все эти условия нужно логировать, чтобы понимать, как работал код в каждом конкретном случае. Например, логировать конфигурацию фичетогглов. Шаги в многошаговых фичах. Например, есть какой-то последовательный долгий процесс. В этом случае лучше логировать каждый шаг и его результат. Аудит. Если пользователь или система делает какое-то действие, необходимо логировать, кто и что сделал. Любые создания, обновления и удаления сущностей. Контекст вокруг ошибок. Недостаточно просто залогировать ошибку. Нужно логировать весь контекст, в котором она произошла — какой это был ретрай, какой статус-код, какой URL и всё остальное, что может помочь при дебаге. Как писать логи: Используй структурированные логи. Не просто строка в логах, а структура. Например, JSON-объекты. В идеале логи должны содержать ответы на вопросы «что произошло?», «кто это сделал?» и «когда это произошло?». Наращивай контекст логов. Сначала пользователь может быть неавторизован, но когда он авторизовался — его данные (userId, например) должны попадать в контекст последующих логов. Отдельно полезно делать связь логов через трейсинг. Что не надо логировать Избыточное логирование. Не надо логировать вызов всех функций и всех строчек кода. Секреты и персональные данные. Тут в целом всё понятно. Большой объём данных без чёткой цели. Тут тоже, думаю, понятно. Хотя, если бы не было проблемы с хранением и обработкой больших данных, то думаю, этого пункта не было бы. https://blog.sentry.io/logging-best-practices/ #development #logging #observability #sentry #best-practices

Check out the New Node.js API Documentation Preview Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org. https://beta.docs.nodejs.org #development #nodejs #documentation #dx

Дайджест за 2026-08-17 - 2026-08-21 postmortem.io · the library of real postmortems postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов. The secure way to release an npm package in 2026 Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты. npm publish-time malware scanning and dual-use metadata npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

npm publish-time malware scanning and dual-use metadata npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки. Как это работает: - Вы публикуете пакет - npm сканирует его. Сканирование может идти до 15 минут для больших пакетов - Если всё ок — пакет будет доступен для скачивания - Если не ок — то либо будет ручное ревью, либо блокировка публикации - В случае блокировки пришлют уведомление. В худшем случае могут потребоваться действия с аккаунтом. https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/ #development #javascript #npm #security #supply-chain #github

The secure way to release an npm package in 2026 Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты. В целом чеклист следует завету «не доверяй никому, кроме себя». Чеклист: 1. Trusted Publisher: укажите конкретный воркфлоу, с которого можно только публиковать staged-версии библиотек 2. Запретить публикацию через токены 3. Включить 2FA для всех 4. Дать возможность создавать теги в GitHub только админам 5. Зафиксировать версии GitHub Actions, которые вы используете 6. Добавьте автоматический линт безопасности 7. Установите 3 дня кулдауна на новые версии зависимостей 8. Используйте npm 12 или другой пакетный менеджер, который не исполняет postinstall-скрипты 9. Создайте workflow для публикации, как в статье Это не гарантия безопасности, но очень снижает риски того, что ваш пакет украдут. От каких конкретно рисков защита: 1. Trusted Publisher — разрешаем публикацию только конкретному воркфлоу 2. Запрещаем публикацию напрямую (без стейджинга) и через токены. Если токен украдут — опубликовать не смогут. Сам стейджинг гарантирует ручной апрув 3. 2FA требует подтверждения через второе устройство 4. Т.к. публикация только по тегам, то разрешаем создавать теги только админам 5. Фиксация версий GitHub Actions позволяет не попасться на взлом CI Actions 6. Линт безопасности автоматически проведёт основные проверки безопасности 7. Кулдаун 3 дня на новые зависимости даёт время обнаружить malware до того, как вы его подтянете 8. Запрет postinstall-скриптов убирает целый кластер атак 9. Аккуратный publish-workflow (без лишних deps в critical job) сужает поверхность атаки при релизе И, конечно же, в статье есть скилл для агента, который настроит всё за вас. https://evilmartians.com/chronicles/the-secure-way-to-release-an-npm-package #development #javascript #npm #security #ci #supply-chain #evilMartians

postmortem.io · the library of real postmortems postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов. https://postmortem.io/ #development #sre #devops #postmortem #reliability

Дайджест за 2026-08-10 - 2026-08-14 Announcing TypeScript 7.0 Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались. TanStack Charts TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков. Investigating three real-world incidents in our cybersecurity evaluations Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

Investigating three real-world incidents in our cybersecurity evaluations Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные. Anthropic проводят исследование возможностей моделей, ставя им задачу в стиле CTF: флаг спрятан на другой машине, найди и достань. Модели говорилось, что она работает в симуляции и интернета нет. Однако из-за мискоммуникации с партнёром (видимо, тем, кто давал инфру) интернет всё-таки был (и эти люди будут нас учить секьюрити). Поэтому из 141 000 запусков в трёх из них модель вышла в интернет и сделала что-то плохое. Кейс №1 В задании агенту дали название фиктивной фирмы и сказали, что флаг у неё. Однако, как говорилось выше, был доступ к интернету. А в интернете был вебсайт у одноимённой компании, который Claude и взломал — получил креды и доступ до продовой БД. Кейс №2 В задании агент нашёл док для онбординга, в котором сказано, что сотруднику надо ставить определённый пакет с PyPI. Claude решил опубликовать этот пакет в PyPI, завернув туда зловред. Зловред скачали, он украл креды, Claude ими воспользовался. Отдельно интересно, что Mythos сказал: если бы это был реальный мир — это НЕ ОК, но т.к. это симуляция, то ничего страшного. Кейс №3 Модель не нашла фейковую цель и пошла искать её в интернете. Просканировала 9000 хостов и взломала одно приложение, но поняла, что вышла за рамки задачи, и остановилась. https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals #development #ai #anthropic #security #claude

TanStack Charts TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков. Что обещают из коробки: - Строгий TypeScript - Framework-agnostic ядро + адаптеры: React, Vue, Solid, Svelte, Angular, Preact и другие - SVG по умолчанию, Canvas опционально - Отдельно делают скиллы или инструкции для ИИ. Прямо на главной в общем-то можно скопировать какой-то промпт для агента, чтобы он собрал демо-график. https://tanstack.com/charts/latest #development #typescript #javascript #charts #tanstack #react

Announcing TypeScript 7.0 Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались. Конечно же сразу идём смотреть цифры. По скорости тайпчека крупные проекты стали проверяться в 7–12 раз быстрее (TS 6 → TS 7): - vscode: 125.7s → 10.6s (11.9x) - sentry: 139.8s → 15.7s (8.9x) - bluesky: 24.3s → 2.8s (8.7x) - playwright: 12.8s → 1.47s (8.7x) - tldraw: 11.2s → 1.46s (7.7x) А если увеличить количество воркеров — можно выйти примерно на 16x. По памяти также есть улучшение, хотя и не такое заметное. Потребление памяти в этих же проектах падает на 5%-25%. Также и все фишки typescript стали работать быстрее — проверка конкретного файла, go to definition и другие. Отдельно радует фидбек разработчиков крупных компаний. Он одновременно хвалебный и показывает, какой же, извините, мрак у некоторых на проектах: - Slack: typecheck в CI с ~7.5 мин до ~1.25 мин, merge queue быстрее на 40% - Microsoft News Services: экономия 400 часов в месяц на ожидании CI - Canva: first error в редакторе с ~58 сек до ~4.8 сек В любом случае, проделана огромная работа, которая ускоряет один из важнейших инструментов для современной фронтенд-разработки. Это, конечно же, очень круто. Что ещё интересного в релизе: Я уже выше упоминал воркеров. Так вот, процесс тайпчека теперь идёт параллельно в 4 воркера по умолчанию, но можно сделать больше. Воркеры частично повторяют работу друг друга, т.к. у них изолированная память, но для разных целей может потребоваться работать с одними и теми же объектами. Поэтому для окружений, где нужно оптимизировать использование ОЗУ, можно оставить одного воркера. Для работы watch-режима сделали порт @parcel/watcher, который отлично себя показывает в vscode, на Go. Для кейсов, где важна совместимость с TS6, оставили отдельный бинарь с реализацией ts6. В частности, совместимость нужна тем, кто использует typescript через API, т.к. у ts7 его ещё нет (ждём в 7.1). Кто-то уже поставил себе? https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/ #development #typescript #javascript #tsgo #performance #releaseNotes

Дайджест за 2026-07-13 - 2026-07-17 Deno 2.9 Вышел Deno 2.9. Пропустил бы релиз, т. к. в целом всё как обычно — улучшают перформанс, улучшают DX, делают лучше интероп с другими пакетными менеджерами. Но в этом релизе добавили сборку desktop-приложений — можно получить GUI без Electron и других обвязок, Deno уже имеет всю инфраструктуру для этого. Iterating faster with TypeScript 7 Статья от VS Code о том, как они мигрируют на новый TS 7. Т. к. VS Code и TypeScript принадлежат одной материнской компании (Microsoft), им очень удобно коллаборировать друг с другом. Более того, VS Code изначально был на TypeScript и шёл с ним рука об руку весь свой путь. В статье рассказывается, как за полгода они переехали на TS 7. Node.js CLI Apps Best Practices Сборник best practices от Liran Tal по Node.js CLI. 37 рекомендаций в 10 группах — от техники и безопасности до удобства работы в терминале. В каждом бест практисе есть описание, почему это важно и как не напортачить, ссылки на источники или готовые решения (например, в виде npm-пакетов). Также есть скилл, чтобы встроить все эти бест практисы в агента. MUST READ, если хотите делать крутые cli. Сборник очень хороший. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

Node.js CLI Apps Best Practices Сборник best practices от Liran Tal по Node.js CLI. 37 рекомендаций в 10 группах — от техники и безопасности до удобства работы в терминале. В каждом бест практисе есть описание, почему это важно и как не напортачить, ссылки на источники или готовые решения (например, в виде npm-пакетов). Также есть скилл, чтобы встроить все эти бест практисы в агента. MUST READ, если хотите делать крутые cli. Сборник очень хороший. 1. Command Line Experience — UX в терминале: - Поддерживайте POSIX-аргументы (-abc = -a -b -c, короткие и длинные флаги) - Проектируйте CLI так, чтобы им было легко и удобно пользоваться - Запоминайте данные и настройки между запусками - Поддерживайте цвета и их отключение - Поддерживайте rich interactions — select, autocomplete, spinner/progress bar - Делайте кликабельные hyperlinks в терминале (URL и file:line:col) - Zero configuration — запуск без конфига и умный детект - Обрабатывайте SIGINT 2. Distribution — как упаковать: - Минимум зависимостей - Фиксируйте версии в npm-shrinkwrap.json - Cleanup конфигов при uninstall 3. Interoperability — CLI как часть unix toolchain: - Умейте обрабатывать STDIN в пайпах (curl … | your_cli) - Умейте выводить structured output (--json) для парсинга и пайпов - Несколько советов для поддержки кросс-платформенности - Уважайте приоритет конфигурации: CLI args → env → project → user → system 4. Accessibility - Docker-образ для тех, у кого нет Node.js - Graceful degradation / --json для CI и слабых терминалов - Поддержка актуальных Node.js версий, понятная ошибка на старых - #!/usr/bin/env node в shebang 5. Testing — не доверяйте locale в assert'ах на текст help/output 6. Errors — ошибки, которые помогают: - Используйте коды ошибок (например, E4002) - Сообщения об ошибках должны вести к действию — не «что-то сломалось», а «сделай X» - Предоставьте дебаг режим - Используйте правильные exit codes - Упростите репортинг багов 7. Development — package.json hygiene: - Советы по использованию поля bin - Используйте относительные пути - Не тащите в files лишнее 8. Analytics — должна быть опциональной 9. Versioning - Всегда предоставляйте флаг --version - Используйте semver - Показывайте версию в help/errors и package.json - Старайтесь быть обратно совместимыми - Публикуйте релизы в npm - Пишите понятные release notes 10. Security — минимизируйте возможность argument injection Также в приложении есть сравнительная таблица CLI-фреймворков и ссылки на обучающие материалы. https://github.com/lirantal/nodejs-cli-apps-best-practices #development #nodejs #cli #best-practices

Iterating faster with TypeScript 7 Статья от VS Code о том, как они мигрируют на новый TS 7. Т. к. VS Code и TypeScript принадлежат одной материнской компании (Microsoft), им очень удобно коллаборировать друг с другом. Более того, VS Code изначально был на TypeScript и шёл с ним рука об руку весь свой путь. В статье рассказывается, как за полгода они переехали на TS 7. Зачем вообще это понадобилось VS Code: - Хотели как можно скорее переехать на новый TS 7, который написан на Go и работает быстрее - Переезжать по шагам легче, чем делать большой прыжок с большим переездом — особенно в большом проекте TS 7 анонсировали весной 2025. Летом уже был работающий typecheck, который команда VS Code активно тестировала. Команда VS Code репортила проблемы, команда TS тут же их чинила. Также команда VS Code сделала расширение для работы с TS 7, которое позволяет легко переключать TS между версиями и легко репортить проблемы. Далее проект VS Code переехал на TS 6. TypeScript 6 — версия, которая всё ещё написана на TypeScript, но поведение которой близко к будущему TS 7. Далее подключили TS 6 и TS 7 параллельно. Сборку всё ещё делали как раньше, но начали проводить typecheck расширений дополнительно через TS 7 — и оба билда и проверки должны всегда проходить в CI. Так находили расхождения в поведении. Самая частая ошибка, из-за которой ломался CI — различие в форматировании. Я правда не понял, в чём именно, если TS 7 делал лишь typecheck. К началу 2026 TS 7 уже стал более-менее стабильным. Расширения на него мигрировали по одному. Во время переноса упростили тулы для сборки: Было: - tsc — тайпчек и dev-сборка - webpack — prod-сборка - esbuild — быстрый emit Стало: - tsgo — тайпчек и dev-сборка - esbuild — prod-сборка На текущий момент весь проект переключился на TS 7. Цифры: Typecheck основного проекта:

# TS 6
tsc --noEmit -p src/tsconfig.json  →  36 сек

# TS 7
tsgo --noEmit -p src/tsconfig.json  →  5 сек

npm run watch (main + ~50 extensions): - TS 6: ~80 сек - TS 7: ~20 сек - re-check после initial watch: ~1 сек Language tooling в редакторе: - было ~60 сек - стало ~10 сек https://code.visualstudio.com/blogs/2026/06/26/iterating-faster-with-ts-7 #development #typescript #tsgo #vscode #performance

Deno 2.9 Вышел Deno 2.9. Пропустил бы релиз, т. к. в целом всё как обычно — улучшают перформанс, улучшают DX, делают лучше интероп с другими пакетными менеджерами. Но в этом релизе добавили сборку desktop-приложений — можно получить GUI без Electron и других обвязок, Deno уже имеет всю инфраструктуру для этого. Как это работает: вы, как обычно, пишете веб-приложение:

Deno.serve(() =>
  new Response(
    "<!DOCTYPE html><h1>Hello from Deno desktop 👋</h1>",
    { headers: { "content-type": "text/html" } },
  )
);

Собираете его:

deno desktop main.ts

Получаете бинарь. Кликаете на него и видите Hello World в GUI. Что умеет из коробки: - Сборка для Windows, macOS, Linux - Системное webview по умолчанию, но можно забандлить CEF (Chromium Embedded Framework) - Управление иконкой в Tray и Dock - Управление окном Звучит прикольно. https://deno.com/blog/v2.9 #development #javascript #typescript #deno #releaseNotes

Дайджест за 2026-07-06 - 2026-07-10 eslint-plugin-unicorn Как-то я упустил момент, когда eslint-plugin-unicorn начал активно развиваться. А тем временем там уже больше 300 правил! Правила всякие разные — от специализированных до тех, которые можно использовать в любом проекте. Skills for coding agents Набор скиллов для coding-агентов от BuilderIO. Наборов скиллов много, но здесь мне понравились /visual-plan и /visual-recap, с помощью которых агент может создать план и отчёт, которые удобно читать и в которых используется канвас с диаграммами, мокапами и всем таким. Выглядит круто. The Goldilocks customizable select height Относительно недавно браузеры разрешили полностью кастомизировать <select>. Но, как обычно, чтобы получить идеальное решение, нужно добавить щепотку своего CSS. Jake Archibald в статье показывает, как добавить эту щепотку CSS и получить хороший select. В статье есть интерактивное демо каждого улучшения и видео для тех, у кого браузер не поддерживает все требуемые фичи. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

The Goldilocks customizable select height Относительно недавно браузеры разрешили полностью кастомизировать <select>. Но, как обычно, чтобы получить идеальное решение, нужно добавить щепотку своего CSS. Jake Archibald в статье показывает, как добавить эту щепотку CSS и получить хороший select. В статье есть интерактивное демо каждого улучшения и видео для тех, у кого браузер не поддерживает все требуемые фичи. Проблема 1: picker упирается в край viewport По умолчанию список опций упирается в край экрана, и непонятно — это конец списка или есть что-то ещё. Решение банальное — добавить отступ от края:

.custom-select::picker(select) {
  margin-block-end: 1em;
}

Но: - в Firefox это просто не работает - в Chrome/Safari margin снизу выглядит плохо, когда picker переворачивается и список выпадает вверх Для Firefox: считаем вручную через calc(100% - var(--viewport-margin)). Chrome & Safari: используем position-try-fallbacks: flip-block, flip-inline, … — при перевороте picker'а margin тоже «переворачивается». margin-block-end сверху становится margin-block-start. Проблема 2: picker становится слишком маленьким У Chrome дефолт min-block-size: 1lh. Если упереть select в край экрана, список сжимается и становится неюзабельным. Решение банальное — поднимаем минимальный размер:

.custom-select::picker(select) {
  min-block-size: 12em;
}

Но тогда короткий список из пары опций начинает выглядеть странно — появляется пустое пространство. Тут Jake использует расчёт размера на основе контента:

.custom-select::picker(select) {
  min-block-size: calc-size(fit-content, min(size, 12em));
}

В Firefox и Safari нет calc-size(), там используется :has() для определения количества элементов. Проблема 3: picker становится слишком большим Picker всегда растягивается на всю возможную высоту. Решение: второй max через calc-size(stretch, …):

.custom-select::picker(select) {
  --max-size: 30em;
  max-block-size: calc-size(stretch, min(size, var(--max-size)));
}

Итоговый CSS Итого 5 простых строчек (и около 30, если считать фолбек для браузеров, не поддерживающих эти 5 строчек) для улучшения кастомизированного select:

.custom-select::picker(select) {
  min-block-size: calc-size(fit-content, min(size, 12em));
  max-block-size: calc-size(stretch, min(size, 30em));
  margin-block-end: 1em;
}

https://jakearchibald.com/2026/goldilocks-select-height/ #development #css #html #select #web #jakeArchibald

Skills for coding agents Набор скиллов для coding-агентов от BuilderIO. Наборов скиллов много, но здесь мне понравились /visual-plan и /visual-recap, с помощью которых агент может создать план и отчёт, которые удобно читать и в которых используется канвас с диаграммами, мокапами и всем таким. Выглядит круто. Также есть скиллы для организации группы агентов, но они уже менее интересны. https://github.com/BuilderIO/skills #development #ai #agents #cursor #skills

eslint-plugin-unicorn Как-то я упустил момент, когда eslint-plugin-unicorn начал активно развиваться. А тем временем там уже больше 300 правил! Правила всякие разные — от специализированных до тех, которые можно использовать в любом проекте. https://github.com/sindresorhus/eslint-plugin-unicorn #development #eslint #javascript #typescript #lint

Why does tsgo use so much memory? Вот и подъехали разборы работы tsgo, на который все мы скоро переедем. На больших проектах он жрёт гигабайты памяти. Автор разбора погонял его на проекте с Next.js и Zod и сделал анализ, куда же уходит память. Короткий ответ: при мультипоточности tsgo создаёт отдельный type checker на каждый поток. У каждого свой state, который не шарится. Также вычисленные типы никогда не освобождаются. При запуске tsgo на 4 потоках 45% памяти уходит на AST, 30% на Checker (400 МБ). При запуске в один поток потребление Checker падает до 50 МБ. У каждого Checker свой state и данные. При запуске tsgo в несколько потоков создаётся несколько Checker, каждый из которых несёт свои данные. Также конструкции Zod вида const emailSchema = z.string().email().min(5).max(120).toLowerCase(); генерируют очень много типов, хотя по итогу нужен только последний. Из хороших новостей: это всё можно оптимизировать и можно ожидать снижение потребления памяти в будущих релизах. https://zackoverflow.dev/writing/why-does-tsgo-use-so-much-memory #development #typescript #tsgo #performance #compiler

Дайджест за 2026-06-15 - 2026-06-19 Deprecating a React component using TypeScript Overload Статья про хитрый способ ввести breaking change в компонент, не создавая ComponentNameV2. Автор использует трюк с TypeScript overloads и @deprecated. ESLint – React – You Might Not Need An Effect ESLint-плагин, который ловит лишние useEffect. Создан по мотивам официальной статьи React You Might Not Need An Effect. Целый набор антипаттернов с конкретными подсказками и ссылками на доку. The Orchestration Tax Addy Osmani рассказывает про «orchestration tax» — налог, который приходится выплачивать, работая с кучей агентов. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы