🙂 Как проверить, что попадёт в бандл Писать эффективный frontend — это очень важно. Во времена, когда Интернет имеет достаточно высокую скорость, разработчики не сильно заморачиваются на тему того, каким будет размер их приложения. А зря. С моей точки зрения, быстрый Интернет — это когнитивное искажение, которое возникает вследствие постоянного обитания в таковом. Когда в больших города с Интернетом чаще всего всё в порядке, в городах поменьше можно наблюдать картину, в которой существует какой-нибудь slow 4G, а то и 3G. Если вспомнить про страны, в которых Интернет в принципе не сильно развит, то проблема встаёт ещё острее. Именно по этой причине я всегда смотрю на то, сколько трафика качает пользователь. Чтобы это приходилось реже перепроверять, важно понимать, как бандлер работает с импортами, а еще перепроверять, как реализованы используемые библиотеки. Это не значит, что нужно идти и лезть в исходный код библиотек, достаточно использовать сервис, о котором расскажу дальше. Вот вам пример одного и того же намерения, но потенциально разного результата: import { string } from 'valibot'; console.log(string); import as v from 'valibot'; console.log(v.string); Вы можете сходу сказать, что из этого тяжелее? Скорее всего второй вариант. Почему? Потому что такой способ импорта потянет за собой все side-effect-ы, которые есть в библиотеке. Почему "скорее всего"? Потому что зависит от того, как разработчик реализовал эту библиотеку. Чтобы проверить, какой трафик вы потянете из этой библиотеки, можно использовать сервис bundlejs.com. Используйте там код, упомянутый выше, жмите кнопку Build, и справа в консоли увидите объем трафика, который скачает пользователь, чтобы заиспользовать этот функционал. Важно: не забывайте использовать импортированные значения, иначе они будут tree-shake-нуты (удалены) бандлером, и размер будет невалидный. Для этого я использовал console.log. Какие выводы следует сделать из этого поста? 1. Пишите библиотеки без side-effect-ов. Это отдельный здоровый топик, который я разбирал тут, тут и тут. Просто придерживаетесь определенных правил, и у тех, кто использует библиотеку, проблем не будет. 2. Проверяйте то, что используете. Зная про проблемы импорта import as N, я решил на всякий случай проверить, не потяну ли действительно всю библиотеку просто из-за одного значения. А использую я иногда такой импорт, потому что он чуть удобнее прямого импорта сущностей. Хорошо писать библиотеки — это искусство. Нужно понимать, что является side-effect-ом, а что нет, понимать, как подсказать сборщику разработчика, что указанный вызов или функция являются чистыми, знать, как разбить код таким образом, чтобы связанность была как можно меньше, и сборщик мог откинуть ненужный код. Но именно в этом и кроется профессионализм — в способности максимально эффективно закрыть боль пользователя. ——— Стрим сегодня вечером. Ориентировочно в 17:00 Мск. До встречи! 👋