#javascript #css #reactjs #material-ui #css-in-js
Вопрос:
https://www.infoq.com/news/2020/01/css-cssinjs-performance-cost/ и https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/ объясните невидимые затраты на производительность CSS-в-JS.
Мы разрабатываем веб-приложение React, основанное на данных, которое требует большой обработки JS. Мы пытаемся оптимизировать приложение, уменьшив нагрузку на основной поток JS. Для этой цели, в дополнение к распараллеливанию некоторых процессов на других веб-рабочих, мы подумываем о замене всего кода CSS в JS статическими таблицами стилей на основе классов, которые мы вручную пишем и просто импортируем в каждый компонент. Проблема в том, что чрезвычайно сложно вручную переопределить некоторые стили пользовательского интерфейса Material, потому что он вводит стиль в элементы, и мы не можем просто переопределить их с помощью классов.
Что еще вы предлагаете нам сделать, чтобы уменьшить перегрузку производительности JS, обрабатывая весь CSS с помощью статических таблиц стилей, а не перегружая обработку JS для создания таблиц стилей во время выполнения?
Комментарии:
1. Отличный Вопрос! Пришли ли вы к решению этой проблемы?
2. Я все еще не уверен, но, похоже, emotion.sh/docs/introduction может решить эту проблему, и именно поэтому команда Material UI продвигает ее mui.com/blog/mui-core-v5 А ты как думаешь?
3. Спасибо за ваш ответ. Как я понял
css, функция эмоций также будет генерировать стили во время выполнения. Посмотрев на текущие проблемы Github с тегомperformance, я не уверен, что они исправили проблемы с производительностью для более крупных приложений. Жаль, что они не переключились на решение CSS-in-JS со статическим/временем сборки с почти нулевым временем выполнения, таким как стежки или экстракт ванили, при замене решения CSS-in-JS для v5.4. Мне очень нравится MUI, и я думаю, что это самый продвинутый набор пользовательского интерфейса только для React из-за поддержки более продвинутых компонентов, таких как
<Autocomplete />или<Datepicker />которые отсутствуют у многих других (прямо сейчас). Поэтому в конце концов я решил пока использовать Tailwind для управления всеми элементами компоновки и простыми компонентами и использовать MUI только для некоторых более сложных компонентов, о которых я упоминал выше. Я стараюсь как можно больше избегать использования их подхода CSS-in-JS. Также относительно легко настроить конфигурацию темы и использовать ее как для Tailwind, так и для MUI.5. Таким образом, приложение не будет работать медленно (по крайней мере, я надеюсь на это)), и из-за встряхивания дерева пакет остается относительно небольшим. Но в конце также следует упомянуть кое-что положительное: одна многообещающая функция, которую они реализуют прямо сейчас, — это предоставление безголовых версий компонентов. Это позволило бы еще больше сократить количество CSS-в-JS, привязанных к их компонентам (и, следовательно, в приложении), так что, возможно, это тоже может быть интересно для вас. Вот вопрос о прогрессе .