Телеграм канал «WebDev+ | Веб-разработка»

Хватит делать эти (до смешного простые) ошибки в TypeScript. Не используй String. Серьезно. String (с большой буквы) - объект-обертка из JS (плохая идея) string (с маленькой) - примитивный тип (вот так правильно) То же самое касается Number и Boolean. Всегда используй типы с маленькой буквы. @WebDev_Plus

Next.js 16: cacheLife Настройка времени, в течение которого: • заранее подгруженные данные могут переиспользоваться на клиенте без повторного запроса • заранее отрендеренные данные могут переиспользоваться на сервере без повторного рендера Документация: https://nextjs.org/docs/app/api-reference/functions/cacheLife @WebDev_Plus

API Popover выводит ваш UI на отдельный верхний слой, так что вам больше не нужно мучиться с управлением фокусом. Плюс оформление затемнения настолько короткое, что помещается прямо сюда: [popover]::backdrop { background: rgb(52, 168, 83); backdrop-filter: blur(3px); } Создавайте больше, тратя меньше кода → https://goo.gle/3XvDUZk @WebDev_Plus

Google запустила CodeWiki — платформу, где можно выбрать любой GitHub-репозиторий и получить к нему нормальную документацию с визуализациями, объяснениями и даже видео. Там еще есть встроенный чат, где можно спрашивать что угодно про репозиторий: архитектуру, функции, связи файлов и прочее. Скоро появится поддержка приватных реп в GitHub, так что можно присмотреться заранее 🙂 codewiki.google @WebDev_Plus

GitFlow одна из самых старых и формализованных схем ветвления, про которую до сих пор говорят. Модель появилась в 2010 году и стала популярной, потому что чётко разделяла разработку, релизы, фичи и хотфиксы — то, чего многим командам тогда сильно не хватало. В GitFlow у каждой ветки есть своя роль: main — прод-готовый код develop — интеграционная ветка feature/ — разработка новых фич release/ — подготовка релизов hotfix/ — срочные правки в проде Такой подход отлично подходит командам с плановыми релизами, поддержкой нескольких версий продукта или строгими QA/Compliance процессами. Всё движется по понятной схеме, и долгосрочная поддержка становится проще. Но у GitFlow есть и минусы. Он добавляет лишнюю сложность, поощряет долгоживущие ветки и замедляет доставку, потому что каждый этап требует координации. Поэтому команды, которые работают быстро или практикуют continuous deployment, обычно его не используют. GitFlow всё ещё полезен, но сегодня это не универсальный вариант — он оправдан только там, где действительно нужен высокий уровень контроля и разделения процессов. @WebDev_Plus

Иногда я встречаю людей, которые слишком зацикливаются на количестве строк кода (и, если честно, у меня тоже такое бывает). Но посмотри на этот компонент. Он вроде бы длинный, НО: ✓ полностью изолированный редактор ✓ стандартные действия: сохранить / сбросить / закрыть ✓ три вспомогательных метода для работы со списками чипов Если свернуть детали и смотреть только на текущее состояние и API, он получается очень простой, понятный и легко читаемый. @WebDev_Plus

Довольно дико, насколько лучше Angular стал со временем благодаря treeshaking. 610 KB, но там уже есть всё, что нужно для нормальной разработки: ✅ NgRx signals store (с events plugin, по сути как redux) ✅ Tailwind для адаптивной сетки и стилей ✅ Angular Material 3 + тема ✅ Signal forms @WebDev_Plus