Comments 9
Спасибо за статью, интересный контент!
Жалко не осветиили самый интересный момент, переключение между React и AngularJS. Как загружали фреймворки, оба сразу, или как-то по-ленивому?
Моя ошибка — использование в данном проекте CSS Modules.
Аргументы понятные, но спорные
Проблемы с кешированием – если делать иммутабельные файлы (с хешем контента в имени), то все будет кешироваться как надо?
Возможность отладки – решается сохранением исходных имен, просто дописываем уникальный хеш в конец (плюс React Devtools приходят на помощь, если что не так)
Переиспользование классов – так вместо классов теперь нужно переиспользовать компоненты! Это имеет смысл еще и потому, что редко требуется переиспользовать класс в одиночку (за такими штуками лучше к tailwind), а какой-то набор с состояниями. Завернуть их в переиспользуемый dumb component, даже если это будет один html-тэг, очень даже оправдано
У нас в проекте используются CSS-модули, уже 2 года как, и мы счастливы. Давайте обсуждать!
Привет! Спасибо за конструктив, я уж думал зря всё это писал :)
К сожалению, даже сейчас ещё на странице остаётся старый фронт с фильтром и для него всё ещё используется старый Angular. Надеюсь, скоро дойдёт и до него очередь.
Поэтому да, грузятся обе библиотеки одновременно.
Впрочем мы и React на страницу не добавляли - он там присутствует уже для других отдельных фронтов, например для шапки сайта.
Спорить не готов, потому как если честно, не очень сильно меня они беспокоят :)
Просто лёгкое раздражение от избыточности.
Что смогу - отвечу.
С иммутабельными файлами - да, всё верно. Смущает, что таким образом мы добавляем два места с потенциальными ошибками - вычистка старых версий и передача бэкенду информации об имени сборки. Способов там довольно много, но даже самый (для нас) экономный приводит к лишнему чтению с диска.
Сейчас мы обычно используем часто подход с SSI включением html, который генерируется вместе с фронтом и содержит <script src> на нужные файлы.
Но всё-таки хотелось бы жить без подобных костылей.
Исходные имена и хэш отлично, но (я понимаю, это звучит немного упорото) я экономил байты :)
Как раз для этого изначально определены приоритеты проекта были.
Про переиспользование.
У нас 13 команд, в которых есть фронт и фронтендеры. CSS Modules дали свободу в плане "не портить друг другу жизнь больше никогда", это большой плюс.
Но и это же (в совокупности с рядом других проблем, вроде множества версий одинаковых компонентво) привело к тому, что на любой странице сайта можно найти пять-десять стилей одинаковых для кнопки, например. Это уйма мусорного траффика.
Поэтому сейчас мы двигаемся в сторону разделения визуала и поведения - библиотека компонентов + свой css-framework, которые в ближайшем будущем будут заменять все старые компоненты так, чтоб стили были определены и подгружены единожды.
Понятно, что при этом индивидуальные какие-то истории останутся в проектах.
И там будут всё те же хэшированные имена, как и везде.
Бандлеры
В момент старта проекта выбрали webpack. Если бы начинали проект сейчас — это гарантированно был бы esbuild, swc или другие экспериментальные проекты. Возможность срезать лишнюю минуту из билда, если помножить её на годы работы — бесценна.
а вы не рассматривали варианты предварительной сборки компонентов(правда, тогда придется где то хранить собранные версии) с целью ускорения процесса сборки всего проекта?
Если я правильно понял, получится что-то очень сильно напоминающее инкрементальный ребилд, который есть во всех основных инструментах сборки.
Выгода будет только при первой сборке таким образом, но при этом мы получаем возможность совершенно фантастических ошибок с кэшированными файлами, дебажить такое бывает непросто.
Сложность выглядит избыточной когда есть уже готовые инструменты, которые работают молниеносно и всё что мне требуется там уже есть :)
Были вопросики к module federation (давно не смотрел за обновлениями), но это не критично.
Если я правильно понял, получится что-то очень сильно напоминающее инкрементальный ребилд, который есть во всех основных инструментах сборки.
Нет, я не про это.
Я говорю про сборку пакетов и публикацию их во внешние источники(к примеру azure artifacts, ну или npm).
1) Вы собирате пакет
2) Публикуете его
3) Устанавливаете его к себе в проект(как обычный пакет из npm) и используете.
ага, теперь понял.
Не могу сказать за всех, но мне бы так не хотелось работать в данном случае.
Если бы эти компоненты активно использовались ещё где-то - тогда есть понятные резоны.
А так, текущий процесс: поправил любой файл, переключился на браузер - посмотрел изменения.
Переходим на пакеты: поправил любой файл, git commit, git push, билд пакета, пуш пакета, npm i, ребилд проекта, пошёл посмотрел изменения.
Да, можно всё это костылями как-то обложить, чтоб работало само, но зачем.
В момент старта проекта выбрали webpack. Если бы начинали проект сейчас — это гарантированно был бы esbuild, swc или другие экспериментальные проекты.
Не рассматривали вариант webpack + swc-loader? Так сказать, совместить приятное с полезным. У меня в проекте по флагу можно переключать сборку с ts-loader на swc-loader. Прирост производительности, конечно, не в 2 раза, но процентов 30%, правда проверку типов надо делать в отдельном потоке.
я про него узнал пять секунд назад ¯\_(ツ)_/¯
спасибо, однозначно стоит попробовать
мне нравятся штуки, дающие лёгкий и быстрый профит
Вы, наверное, в курсе, но на всякий случай: проверку типов можно делать с помощью fork-ts-checker-webpack-plugin, что-бы не только на IDE полагаться.
Если попробуете, было бы интересно узнать результат. У меня проект небольшой, потому прирост, скорее всего, и не особо заметен.
А так мне webpack по-прежнему импонирует своей гибкостью, стабильностью и наработками, но упускать возможность ускорить процесс сборки не хотелось бы.
К слову, есть также esbuild-loader, но я его не пробовал, да и вряд ли на своих масштабах увижу большую разницу.
Как мы устранили страшное легаси незаметно для пользователей