Хороший сайт для создания простых перформанс бенчмарков на js. Не уверен, что это прям самый лучший сервис для бенчмарков, но он достаточно удобный, и если вам не нужна супер большая точность - то выглядит гуд.
Приятный интерфейс и возможность делиться ссылкой на конкретный бенчмарк без авторизации.
Достаточно эмоциональная статья (чего стоит одно только название), которая подсвечивает проблему роли архитектора в разработке в индустрии.
Архитектор - это звучит гордо. Но во многих компаниях эта роль закрывает собой некоторые организационные проблемы, но создает другие. Также, часто бывает так, что архитекторы перестают программировать. Это две крупных проблемы, с которыми необходимо бороться.
В статье рассматривается, как правильно работать с архитектурой.
В целом, архитектура - это необходимый навык для любого разработчика, если мы хотим создавать крутые масштабируемые и поддерживаемые системы. Поэтому запирать этот навык в одном человек - путь в никуда.
Как следствие, есть смысл взращивать этот навык во всех разработчиках, а не замыкать на одном человеке.
Как этого достичь:
Неплохая статья про то, почему web компоненты переживут все современные фреймворки. Если коротко, то автор ведёт свой блог довольно давно (около 15 лет) и за это время он понял, что привязываться к конкретным инструментам в вопросе ведения блога - это путь в никуда, т.е. если технология сейчас кажется перспективной, то через 5 лет она, скорее всего, окажется аутсайдером, а через 10 про неё уже и не вспомнят
Поэтому автор хранит свои заметки в чистом markdown. И при переезде на новые технологии (сейчас он использует Astro) особых проблем не возникает т.к. markdown абстрагирован от инструментов. Но у markdown есть одна крутая фишка - в нем можно писать html и большинство инструментов его отрисуют. Это дает возможность вставлять в markdown всякое, для чего он не предназначен (графики, интерактивные примеры). А если что-то и вставлять - то web-компоненты, потому что они будут работать и сейчас и через 10 лет.
В общем, если вы делаете что-то, что должно работать без правок и через 10 лет - то нативные веб-компоненты - лучший выбор. Они точно будут работать везде и еще долго будут с нами
Вышел Yarn 4.0 с новыми фичами
Прежде всего, на мой взгляд, интересно, что Yarn реализовали на своей стороне решение проблемы безопасности npm: в блоге уже была статья про то, что в npm можно залить пакет и метаданные пакета с разным содержимым, что является валидным вектором атаки на приложения через пакеты. Yarn теперь умеет самостоятельно это проверять, что, конечно, замедляет установку и рекомендуется использовать только в CI
Следующая интересная фича: теперь в yarn можно описывать ограничения или правила для пакетов. Ну т.е. можно декларативно описать, например, что все пакеты в моно-репо должны использовать друг друга как peerDependency, или что React должен быть 18 версии, или что пакеты должны явно указывать что работают с nodejs определенной версии. Это все описывается на JS и можно описывать свои проверки.
Из других изменений:
Либа, которая прямо в браузере убирает задний фон с картинок. Попробовал на своей фотке - результат весьма годный. Судя по скачиваемым ресурсам - решение реализовано на каком-то другом языке и скомпилировано в WASM.
Может быть полезно в ваших проектах
Очень крутая и интерактивная статья, наглядно объясняющая как работают разные retry стратегии.
В рамках статьи объяснения про то, зачем нужны retry и почему наивная реализация "повторить запрос через секунду" сопровождаются интерактивными примерами: в них визуально моделируется отправка запросов клиентами на сервера, а вы, как читатель, можете контролировать rate ошибок сервера, количество серверов и прочие параметры.
Некоторые примеры можно использовать как эталон для обучения. Мне очень сильно понравился кейс, где при переключении рейта ошибок на 100% сервера складываются, но при включении обратно в 0% они не поднимаются - клиенты отправляют слишком много запросов за раз, вновь поднятые инстансы не успевают их обработать. Но там можно добавлять новые сервера и автор ставит вопрос "как думаете, сколько нужно дополнительных серверов, чтоб система снова начала работать?", что прямо таки мотивирует сначала подумать, а потом и испытать свою догадку
Статья про то, почему сложно расти будучи менеджером и какие паттерны можно применить, чтобы найти точки роста
У разработчика, как правило, направление для роста в целом понятно, хотя для старших грейдов могут быть сложности с определением конкретных шагов. У менеджмента же нет четких критериев для роста. Чтобы вырасти как менеджмер - нужно задрайвить что-то, а чтобы задрайвить - надо чтобы была возможность это сделать (ну, например, новый интересный проект). Однако, здесь начинает работать парадокс навыков и возможностей - чтобы прокачать навык, нужна возможность для его прокачки. Чтобы получить возможность, нужны навыки. В целом этот парадокс актуален для любой профессии
Чтобы обойти это правило, необходимо самому создавать возможности. Для того чтобы их создавать, автор выделяет 6 паттернов:
Вдохновляющий лидер - такой лидер способен вдохновить и мотивировать команду, скоуп её ответственности будет расти, вместе с ростом лидера.
Крутой тренер - работает с каждым членом команды отдельно, развивая каждого из них и исключая лоу-перформеров из команды. Таким образом из среднечковой команды можно вырастить крутую командду
Бизнес-стратег - видит возможности для бизнеса, более менее хорошо в предсказывании будущего, занимается приоритезацией и не боится рисков. Такой человек может сфокусировать работу команды на важных или ценных задачах
Инноватор технологий - замечает проблемы в техническом развитии и технологическом стеке. Решая эти проблемы, он увеличивает перформанс команды.
Оркестратор - умеет организовывать работу своей команды и организовывать совместную работу разных команд, увеличивая эффективность работы всей системы
Вышла 1 версия rspress - генератора статичных сайтов для документации с использованием rspack. Обещают что поддерживают основные фичи, необходимые для документации - скорость сборки. MDX, поиск, мультиязычность, система плагинов
Судя по страницу, Rspress собирается в разы быстрее docusaurus
Статья от Vercel про вред от паттерна barrel file. В статье vercel рассказывают, как они оптимизировали импорты в next.js чтобы избежать обработки таких файлов и как ускорили сборку и старт приложения на 30-40%
barrel-file - это когда, например, в корне библиотеки лежит index.js, который ре-экспортит кучу сущностей из других вложенных файлов. Проблема в том, что не смотря на то, что в коде используется всего лишь 1 ре-экспортируемая сущность, бандлерам и некоторым тулам, например jest, приходится сначала обработать все файлы. Что снижает скорость работы инструмента
Каноничный пример
export { default as module1 } from './module1';
export { default as module2 } from './module2';
export { default as module3 } from './module3';
Некоторые библиотеки имеют около десяти тысяч ре-экспортящихся сущностей, что значительно влияет на скорость импорта такой библиотеки.
Команда next.js ввела новую опцию в конфиг: optimizePackageImports, которая заставляет фреймворк просканировать barrel-file и в рамках сборки поменять импорты на более точечные. Это изменение позволило ускорить сборку на 15-70%. Например, импорт @material-ui/icons ускорился с 10 секунд до 2.9 секунды.
Также в статье указана ссылка на eslint-плагин, который умеет оптимизировать импорты barrel-файлов
Хорошая статья про применение storybook на проекте. Частое заблуждение - что storybook - это инструмент чисто для дизайн-систем. Однако, любое приложение может извлечь пользу от использования storybook
В статье рассматривается, какое API есть у storybook и как использовать его с пользой.
Статья начинается с предоставления глобальных зависимостей. Допустим, ваши компоненты зависят от Context'ов или каких-то глобальных переменных. В этом случае у вас 2 пути. Первый - это отделить чистый компонент от связи со всем глобальным. Но тогда мы теряем возможность проверять корректность связи компонент и контекста. Второй путь - это запровайдить контекст через storybook. Для этого есть Decorators API. Можно весь контекст сложить в декоратор и подключить его глобально для всех историй. Кроме того, этот декоратор можно сделать настраиваемым для каждой истории, используя фичу передачи параметров в историю.
Также storybook очень хорош для тестирования, т.к. компонент запускается в реальном браузере, а это, во-первых, дает возможность удобно дебажить и инспектировать компонент прямо в браузере, а во-вторых, позволяет быть уверенным что компонент реально работает и выглядит в браузере так, как нам нужно
В storybook есть встроенное API для тестирования - через play поле в истории можно взаимодействовать с компонентами (через testing-library) и также делать проверки. Storybook умеет запускать play функции как тесты на jest+playwright
Кроме того, есть инструменты, позволяющие проверить как выглядит компонент, через скриншот-тестирования. Storybook имеет платный нативный (для storybook) chromatic, но также есть и бесплатные аналоги (при желании можно написать их ручками)
Также автор делится простыми лайфхаками для улучшения качества тестов в storybook
Новая статья про ускорение JS экосистемы. На этот раз автор не разбирает какой-то конкретный кейс, а в целом рассказывает об одном паттерне, который замедляет исполнение кода.
Паттерн сегодняшней статьи - это index-файлы с ре-экспортами. В сообществе есть консенсус большинства, что у библиотек или модулей должен быть index.js, который содержит все публичное API, и дальше лезть никому не нужно. А если вы используете не все из этого API, то tree-shaking вырежет все лишнее.
В целом, это так и есть, но не всегда. Tree-shaking актуален только для кода, который был обработан бандлером. Если же код не обрабатывается бандлером, то рантайм вынужден все import'ы обработать, что увеличивает время выполнения кода.
Например, если код не бандлить и просто поставлять модулями в браузер, то браузеру придется обработать все дерево зависимостей index.js файла, даже если вам нужна одна простая утилка.
Также это проблема, с которой я сталкиваюсь при написании тестов в jest. Код импортирует 1 утилку, но она импортируется из index.js файла, поэтому jest тратит 5-10 секунд на резолв всех зависимостей, и 100мс на запуск самих тестов.
При этом index.js файлы - это не анти-паттерн. Да, у него есть минусы, но они проявляются только если они используются в окружениях, где код запускается без бандлинга и если таких файлов неприлично много. Если index.js используются к месту или в проекте, который не живет без бандлинга - то такие файлы не будут создавать негативный эффект.
Обзор на разные метрики для оценки продуктивности команды разработки.
В статье обсуждается зачем нужны такие метрики и какие подходы есть в индустрии для сбора этих метрик
Зачем нам нужно замерять команды разработки:
Но как правильно померить команду разработки? Это нетривиальная задача и подходы к решению этой задачи менялись с течением времени
Когда то давно, достаточно было замерять строчки кода (например, в книжке "мифический человекомесяц" часто встречаются кейсы, где проекты замеряются по строчкам кода).
Затем перешли на измерение velocity и cycle time. Velocity замеряет объем поставляемых в итерацию задач. Cycle time - время от "взяли задачу в проработкуработу" до "поставили ценность клиенту". Эти метрики уже намного ближе к бизнесу, чем строчки кода. Они проверяют, насколько команда гибкая (насколько быстро она проверяет гипотезы)
Позже, DevOps движение принесло DORA (DevOps Research and Assessment) - 4 ключевых метрики, по которым можно понять эффективность команды:
Эти метрики направлены на то, чтобы команды могли поставлять изменения как можно чаще с как можно большим качеством. Метрики DORA основаны на эмпирических данных кучи команд. Эти данные были собраны и затем выделены средние, лучшие и худшие результаты. Вы всегда можете загуглить текущий отчет DORA и сравнить свои показатели метрик с табличками оттуда и сделать выводы, что вам следует развивать.
Следующий набор метрик - SPACE.
Тут уже делается акцент на уровне счастья разработчика и на эффективности процессов. Но при этом, в статье (я не понял это прям в SPACE предлагается или в статье так интерпретировали этот набор метрик) предлагается замерять скорость и эффективность Code Review, что, на мой взгляд, не очень хорошо
В этом году появился DevEx, который предлагает замерять циклы обратной связи, когнитивную нагрузку и возможность для потоковой работы в разрезе персональной работы, системы и KPI
В общем, оценивать эффективность разработки очень сложно и есть разные подходы, которые можно комбинировать.
Наличие плана для онбординга инженеров - стандарт индустрии. Такой план значительно повышает скорость интеграции нового человека в команду и повышает его эффективность. Однако, почему то в компаниях редко есть план онбординга для менеджеров. Для этого есть веские причины: менеджеров меньше, у них у всех разный бекграунд, из-за чего онбординг каждого нового менеджера может отличаться от предыдущих. Но в целом, наличие общего плана было бы полезным
Статья рассказывает, как сделать план онбординга для менеджеров
Команда React работает над своим компилятором React Forget. Внезапно на reddit'е задались вопросом "не забыла (forget) ли команда React о React Forget?". И в комментарии пришел разработчик из команды React и рассказал немного подробностей про разработку компилятора.
Разработчик объясняет сложность создания своего компилятора на достаточно простом примере компилирования использования переменных в компоненте в код с useMemo.
Короткая заметка про разные стили работы тестовых фреймворков в JS (в целом актуально и не только для JS)
Есть 2 типа тестовых тулзов: spec и tap. Spec - это когда мы тесты обозначаем специальной функцией и когда она выкидывает исключение - мы считаем что тест упал. Если же исключение не было выкинуто - тест прошел. Tap - это когда есть специальное API для проверок и проверки либо проходят либо нет.
Типичный пример в spec-подходе:
describe('account', () => {
it('has a balance of zero when first created', () => {
// if this throws, the test fails
expect(new Account().balance).to.equal(0)
})
it('has an empty list of initial addresses', () => {
expect(new Account().addresses).to.match([])
})
})
Типичный пример в tap-подходе:
t.test('account', async t => {
const a = new Account()
t.equal(a.balance, 0, 'balance of zero when first created')
t.match(a.addresses, [], 'empty list of addresses')
t.test('credits', async t => {
a.credit(100)
t.equal(a.balance, -100, 'negative balance after credit')
a.debit(200)
t.equal(a.balance, 100, 'positive balance after debit')
})
})
В первом сниппете кода границы тесты - это describe и it.
Во втором же сниппете используется объект t, который умеет делать проверки и композировать их через test. При этом "тестов" в привычном понимании там нет, только проверки. Минимальный tap тест выглядит так t.ok(cond, message)
То есть, разница подходов - разница в абстракции, вокруг которых они крутятся. Для spec - это тесты, для tap - проверки.
Автор также указывает на разницу, что в spec-подходе it и describe определяются тест-ранером (а значит нельзя запустить тесты на чисто nodejs) и обязательно нужно выделять describe => it, но, кажется что в реальности это не так (т.к. все таки есть тулы, где эти функции нужно импортировать явно, а тесты могут запускаться без отдельного тест-ранера)
Пререлиз Lit 3.0. Короткое напоминание: Lit - это инструмент для облегчения работы с веб-компонентами.
Релиз выглядит достаточно интересным: отказ от поддержки IE11, переход на новые декораторы из стандарта языка, обновления компилятора (неожиданно для меня, шаблоны Lit компилируются через Typescript) и, самое для меня неожиданное, интеграция с Preact Signals.
Статья рассматривает 3 различных стандарта для сжатия файлов: gzip, brotli (решение от Google) и ZStandard (решение от Facebook). Рассматриваются эти стандарты с точки зрения распаковки npm-пакетов. В целом, неплохой обзор на разные инструменты для сжатия контента
В рамках сравнения получились следующие выводы: ZStandard эффективнее сжимает чем gzip и быстрее распаковывается. Brotli же сжимает еще эффективнее, но не так быстр в запаковке и распаковке контента.
Но при этом для сжатия npm пакетов используется gzip. Почему так, если другие форматы эффективнее? Все дело в обратной совместимости. Brotli поддерживается нативно с npm 10 (если я правильно понял статью), а значит, пока есть клиенты с более мелкими версиями npm - включать brotli как решение по умолчанию - нельзя. Так что к 2027 году можно будет переходить на brotli по-умолчанию. А поддержки ZStandard в npm пока еще нет, поэтому вряд ли стоит ожидать его применения
PS: отдельно порадовала отсылка в названии статьи к фильму "Дорогая, я уменьшил детей", который был у меня в детстве на кассете :)
Чеклист из 15 пунктов про обеспечение безопасности в nodejs приложении. В каждом пункте в статье раскрывается зачем и как это делать
Islands Architecture набирает популярность и появляются статьи про разные нюансы работы с этой архитектурой. В данной статье рассматривается, как шарить данные между островами. В целом, ничего нового в рамках статьи нет (т.к. проблема существует еще с jquery-виджетов), но неплохо визуализировано и объяснено, какие паттерны шаринга данных есть и какой из них лучше
В целом в статье рассматриваются следующие паттерны, от худшего к лучшему:
Есть статьи Дэна Абрамова и Кент Си Доддса, объясняющие, как правильно композировать компоненты в React, чтобы не требовалось использование React.memo. Но в чем проблема React.memo?
Статья разбирает, почему использование React.memo приводит к усложнению кода. Если коротко, то React.memo использует для сравнения Object.is, что влечет за собой требование прокидывания стабильных ссылок на объекты и функции в пропсы. А это, в свою очередь, требует заворачивания в useMemo всех объектов, вместо простого их прокидывания, даже если они не изменяются.
Например, в коде <ExpensiveTree style={{ backgroundColor: 'blue' }} /> при каждом рендере style будет новый, поэтому, чтобы не вызывать ререндер, нужно либо вынести style в константы за компонент (что не всегда возможно), либо завернуть объект в useMemo
Также, если компонент принимает children, то JSX разметка тоже не является стабильной ссылкой, из-за чего при каждом рендере children будет отличаться
Поэтому, вместо использования мемоизации следует рассматривать другие альтернативы: правильная композиция компонентов или стейт-менеджеры
Хорошая статья про то, что микросервисы переоценены. Начиная с какого-то времени и по сей день, микросервисы считаются лучшим выбором для создания новых продуктов. Обязательно надо делить все на микросервисы, это позволяет изолировать контексты, легко масштабировать инстансы, разделить код по командам. Но, почему-то, все упускают сложность, которую привносят микросервисы.
Микросервисы обладают намного большей сложностью, чем обычные приложения, а сложность - это самый главный враг для эффективной разработки. При этом большинство компаний не ощущают преимуществ от микросервисов (т.к. для этого надо быть реально огромной компанией), но "платят" за сложность подхода - разрабатывают сервисы управления микросервисами, копируют бойлерплейт, не имеют возможности удобно дебажить и тестировать весь флоу.
При этом многие крупные технологические компании достигли коммерческого успеха, будучи монолитами (Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, WhatsApp), а некоторые из них и по сей день имеют монолитное ядро. А некоторые компании уходят от микросервисов к более крупным сервисам (Uber)
В общем, микросервисы необходимы, когда вы разрабатываете что-то гигантское типа Google. В иных случаях делайте обычные сервисы или монолиты и живите счастливо. В целом, индустрия бы лишилась многих проблем, если бы не повторяла в слепую то, что делает Google и другие крупные и передовые компании.
Также все это, хоть и в меньшей степени, справедливо и для микрофронтендов: микрофронтенды привносят в проект определенную сложность, поэтому решение об их использовании должно приниматься только если эта сложность окупается преимуществами от введение микрофронтендов
Хорошая статья, объясняющая на простых примерах практики для взаимодействия с сервером, который отдает ошибки. Наверняка, вы сталкивались с ситуацией, когда сервер иногда отвечает ошибкой, но если повторить запрос - то ответит корректно. Решение на поверхности - просто влепить retry. Что может пойти не так?
Статья как раз и объясняет что может пойти не так. Если коротко, то retry может привести к тому, что нагрузка на сервер вырастет и он перестанет справляться с обработкой запросов. После этого количество ошибок возрастет, количество retry увеличится, что приведет к еще более печальным результатам. В статье рассказывается как правильно делать обращения к нестабильному серверу
Первая практика: retry. Если все клиенты будут использовать retry с одинаковым таймаутом между запросами, то если серверу станет плохо - ретраи его добьют. Чтобы этого не случилось, используют exponential backoff retry - это когда ретраи делаются не через фиксированные отрезки времени, а эти отрезки увеличиваются. Грубо говоря, если сервер не смог ожить за первые 2 быстрых ретрая, то вряд ли он оживет в ближайшее время, поэтому есть смысл увеличивать с каждой попыткой интервал между попытками.
Если все клиенты будут ретраить с одинаковыми таймаутами, то нагрузка на сервер будет происходить волнами. Чтобы это устранить, добавляют jitter - случайную задержку к интервалам между ретраями.
Но в целом, при долгом отказе сервера, даже "умные" ретраи не спасают - они лишь откладывают пик нагрузки. Поэтому применяют и другие практики: Retry circuit breaker и Retry budget.
Практика Retry circuit breaker говорит о том, что ретраи допускается делать если количество ошибок от сервера не превышает порог. Если превышает - мы считаем что сервис немножко нездоров и долбить его ретраями - значит делать хуже
Практика Retry budget говорит о том, что ретраев не должно быть больше определенного порога от количества успешных запросов. Например, не больше 10% от запросов.
Но и это еще не все. Еще существует практика deadline propagation. Это когда клиент в запросе передает значение таймаута и сервер, получая запрос на обработку из очереди обработки, может принять решение - есть ли смысл его обрабатывать. Или прекратить обрабатывать запрос, ответ на который клиент уже не ждет.
В общем, крутая статья с хорошими примерами и графиками про основные паттерны борьбы с нагрузкой на нестабильный сервер
В Redis 7.2 появится возможность писать внутренние триггеры и функции на JS. Раньше поддерживался только Lua. Redis - это СУБД для быстрой работы с данными key-value. Оказывается там есть возможность не просто складывать и читать данные, но еще и делать кастомную логику на языке программирования
Функции и триггеры покрывают разные кейсы. Функции - это про быструю обработку данных на стороне СУБД. Например, я хочу получить ФИО всех клиентов, но вместо полных имен - инициалы. Можно выгрузить всех клиентов в приложение и там сделать обработку, а можно сделать функцию, которая сразу вернет готовые данные. Триггеры же позволяют подписаться на события в БД и реагировать на них. Например, дополнять всем данным определенного типа колонку lastUpdated
Еще из интересного, что redis предусмотрели, что разработчики захотят делиться друг с другом скриптами, поэтому добавили возможность конфигурировать этот код
Redis используют движок v8 для запуска JS. Жаль, конечно, что не приводятся данные по перформансу этого всего (и сравнительный анализ с решением на lua например). Но, тем не менее, круто что появилась возможность писать такой функционал на JS
Примеры:
Подсчет количества слов во вставляемых данных
function wordsCounter(client, data){
text = client.call('hget', data.key, 'content');
words = text.split(' ').length;
client.call('hset', data.key, 'cnt', words.toString());
//This log is for demo purposes, be aware of spamming the log file in production
redis.log('Number of words: ' + words.toString());
Логирование изменения данных
function alertUserChanged(client, data) {
// detect the event and log an audit trail
if (data.event == 'hset'){
redis.log('User data changed: ' + data.key);
}
else if (data.event == 'del'){
redis.log('User deleted: ' + data.key);
}
var curr_time = client.call("time")[0];
// add the current timestamp to the Hash
client.call('hset', data.key, 'last', curr_time);
}
Skott - библиотека для анализа графа зависимостей. Альтернатива Madge. Авторы обещают что она работает очень быстро.
Можете попробовать на своем проекте запустив skott --displayMode=webapp --trackThirdPartyDependencies --ignorePattern="test/**/*". Возможно, потребуется поправить команду чуть под себя
Я попробовал на текущем проекте. Анализ действительно более менее быстрый, но воспользоваться результатом в веб-UI я не смог т.к. там ничего непонятно и на графе из 1300 узлов он подлагивает (первый рендер занимает где-то полминуты). Так что я знаю что у нас 43 циклических зависимостей, но Skott, как почтальон Печкин, мне их не покажет.
Короткая статья про кеширующие хедеры. При настройке заголовков ответа на сервере или CDN можно указать правила кеширования. Если их правильно настроить, это сильно поможет и пользователю и приложению.
Автор разбирает 2 простых сценария: кеширование до изменения и вечное кеширование.
Если у вас есть ресурс, который иногда меняется, то имеет смысл выставить следующее значение заголовка Cache-Control: public, max-age=0, must-revalidate. В этом случае браузер при повторном указании ресурса будет спрашивать у веб-сервера, изменился ли указанный ресурс или нет. И если не изменился - сервер ответит 304 кодом, что означает, что браузер может взять контент из кеша. В этом случае выигрывают все - пользователь не скачивает лишний трафик, не ожидает загрузки. Сервер же не тратит свои ресурсы на раздачу файла
Если у вас есть ресурс, который никогда не меняется (например, JS-статика с хешом в имени), то в заголовок можно передать public, max-age=31560000, immutable.
public означает что ресурсы может быть закеширован как на устройстве так и на посредниках
max-age=31560000 указывает, что ресурс кешируется на 1 год
immutable означает, что браузер не должен перезапрашивать ресурс, если он уже есть в кеше.
В целом эти 2 совета могут быть верны для многих случаев, но в реальности могут быть случаи между двумя этими крайностями. Разработчику следует подумать о кешировании своих ресурсах т.к. правильная стратегия кеширования является вин-вин ситуацией: и пользователь и сервер выигрывают от правильно настроенного кеширования
Достаточно большая статья, иллюстрирующая большую проблему TypeScript. В большинстве случаев TypeScript помогает разработчику, отлавливая проблемы и баги, заставляя описывать документацию (типы как часть документации). Но также есть ряд кейсов, когда полностью рабочий код не проходит проверку TS и необходимо как-то убедить TS, что я, разработчик, не дурак и знаю что делаю.
В целом в сообществе разработчиков на это есть 2 лагеря. Первый - если TS просит, значит надо. Кажется, это те же люди, которые ненавидят any и ts-expect-error в коде. Второй лагерь - если TS просит, а я не дурак - значит TS дурак и надо его "убедить". Например, поставить as или ts-expect-error
Я лично во втором лагере - я не борюсь с TS больше необходимого, но в сложных случаях предпочитаю делать тайпкасты через as.
В статье автор разбирает свою личную боль - TS плохо справляется с функциональных подходом, например с pattern matching. В статье автор достаточно подробно описывает свою борьбу с TS, в которой ему удалось победить ценой написания кучи дополнительного кода с нетривиальным решением
Грядет обновление Storybook. Самое интересное в нем: альфа-тестирование аддона для визуального тестирования. Естественно на Chromatic - инструменте от Storybook. В посте есть гифки с демонстрацией, выглядит интересно
Также ускорили react-docgen в 2 раза. Этот аддон позволяет, например, генерировать контролы к истории в storybook на основе типов. А еще улучшили ошибки и туториалы
В stage 3 дошли методы группировки массивов. Также это уже реализовано в Chrome 117.
Раньше, для группировки элементов массива нужно было либо тащить либку, либо вручную писать цикл или reduce. Теперь же в метод groupBy будет встроен прямо в язык.
Примеры применения:
Можно получить объект
const peopleByAge = Object.groupBy(people, (person) => person.age);
А можно Map
const peopleByManager = Map.groupBy(people, (person) => person.reportsTo);
Стоит отметить, что Object.groupBy возвращает объект, у которого prototype - null. Это значит, что у него нет встроенных в объект методов
const peopleByAge = Object.groupBy(people, (person) => person.age);
console.log(peopleByAge.hasOwnProperty("28"));
// TypeError: peopleByAge.hasOwnProperty is not a function
Метод не стали встраивать в прототипа массива т.к. есть либки, которые уже добавляют его в прототип массива, поэтому метод сделан статичным у класса.
Скоро выходит TypeScript 5.3 и можно глянуть что там нового завезли
Во первых, Import Attributes достигли stage 3 в tc39 и будут реализованы в TS 5.3.
Это новая фича ES, которая позволяет указать, например, корректные MIME типы для загрузки модулей
import json from './foo.json' with { type: 'json' };
Во вторых, занесли новую опцию в TS: isolatedDeclarations. Она указывает, что TS следует рассматривать типы пакетов изолированно. Например, если у вас есть монорепа, где пакет А, испольует Б, а тот использует В, а тот использует Г, то TS сначала компилирует типы Г, затем В, затем Б и только потом проверяет типы А. Это долгий и медленный процесс, поэтому сообщество предложило внести опцию для изменения механизма сборки типов. Это значительно ускоряет работу TS в монорепо с пакетами
Также пофиксили уточнение типов в условиях внутри дженериков. Сейчас есть кейс, когда TS не может корректно уточнить тип в условиях в дженериках, что мешает разработчикам экспериментировать с дженериками. В 5.3 кейс будет исправлен
Починили проблему в DX при автокомполите union'а, который расширялся до очень широкого типа Например, если в коде был такой тип
То TS language server не давал вариантов small medium и large в автокомплите т.к. тип расширялся до string. Однако такая запись типов часто используется в коде, например в случае с иконкой мы можем указать пресет или кастомный размер. В целом этот кейс очень популярен в ui-kit-ах. Например type Color = 'primary' | 'secondary' | string позволяет указать основной и дополнительный цвет или любой кастомный
