Styled-компоненты против SASS (SCSS) или LESS

Ответ 1

Браузеры развиваются для разбора CSS отдельно от разбора Javascript, почему мы пытаемся отклониться от этого и поместим все в Javascript?

Когда вы смешиваете Javascript и HTML (а именно JSX), а затем также CSS (JSS или другой), вы делаете свой компонент сплошным модулем, который вписывается в один файл. Вам больше не нужно сохранять стили в отдельном файле.

Затем происходит функциональная магия: поскольку JSX является чистой функцией необработанных данных, которая возвращает "HTML" (на самом деле), так же, как CSS-in-JS - это чистая функция или необработанные данные, которые возвращают "CSS" ( тоже не очень). С этого момента я считаю, что чтение о JSX и также о CSS-в-JS.

Styled-component CSS отправляет свою библиотеку javascript на клиентский конец, которая фактически анализирует стили во время выполнения и помещает внутри тега <style />, когда каждый компонент загружается по требованию. Это означает, что дополнительная загрузка и логика в конечном итоге способствуют циклам выполнения в браузере.

Не только во время выполнения. Поскольку CSS-in-JSS - это просто функция данных, которая возвращает CSS, вы можете использовать ее на любой платформе. Возьмите Node, добавьте SSR, и у вас есть элементы style, доставленные в браузер в тело ответа, поэтому проанализированы так же, как это произойдет в исходном случае получения CSS.

Зачем это нужно?

Поскольку он удобен в разработке, так же как и React или Redux, как и jQuery, и точно так же, как и любая другая библиотека, это связано с нагрузкой на сеть и стоимостью браузера.

Вы берете библиотеку, потому что она решает проблему. Если нет проблем, зачем использовать библиотеку вообще, правильно?

Значит ли непрерывный вычисленный текст в стиле <style /> в заголовке заголовка вызывает перезагрузку/перерисовку браузера?

Есть так много вещей, которые заставляют оплатить.

Браузеры умны. Они даже не пытаются перерисовать, если стили не изменились. Это не означает, что они не вычисляют разницу, которая стоит процессорного времени.

Там хорошее введение в масштаб и сложность расчетов стиля (пере), это действительно стоит прочитать, чтобы понять тему глубже.

Ответ 2

Я использую SCSS (SASS) уже много лет, а также использую Styled-Components для нескольких проектов, в том числе крупных.

Я люблю и то, и другое, и Styled-Components считает для меня шаг вперед:

Styled-Компоненты - Плюсы

1. Полная укладка изоляции; предотвращает возможные ошибки при работе в командах, когда один член команды никогда не может переопределить стиль другого.
2. Удалена необходимость вручную обрабатывать имена классов, поскольку они генерируются автоматически

3. Я обнаружил, что легче работать с CSS внутри самого файла JSX (я был против этой идеи много лет)

4. Возможность легко использовать переменные JavaScript в стилях

Styled-Компоненты - Минусы

1. Каждый компонент стиля представляет собой еще одну функцию-обертку, и многие стилизованные компоненты означают больше функций, что означает меньшую эффективность, так как все это код должен быть "скомпилирован" и так далее.
2. Самый большой недостаток: изменения в стилях требуют повторной компиляции пакета, и состояние приложения может сбрасываться.

Минусы можно рассматривать как таковые только в некоторых сценариях, но не обязательно во всех.

Профессионалы SCSS/LESS можно рассматривать как противоположность минусам, перечисленным выше, хотя у них есть и другие минусы, такие как микширование и более быстрая разработка при работе с переменными (IMHO). он может стать "уродливым", определяя локальную переменную селектора:

Сравните эти упрощенные примеры:

Пример SCSS:

.icon{
  $size: '20px';
  width: $size;
  height: $size;
  margin-left: $size/2;
}

Пример локальной области применения Styled-Components:

const Icon = styled.i(props => {
  const size = 20; // easier to use Number instead of String for calculations 
  return '
    width: ${size}px;
    height: ${size}px;
    margin-left: ${size/2}px;
'});

Очевидно, что переменная могла быть определена вне обертки в стиле Icon а затем внутренне использована, но это не сделает ее изолированной, поскольку CSS-компонент styleled-компонента может состоять из подкомпонентов в стиле и выглядеть больше как CSS:

const Header = styled.header'
   > ul{
     ...
   }

   li{
     ...
   }

   img{...}

   navigation{...}
'

Не всегда желательно извлекать каждый отдельный элемент HTML из его собственного стилизованного компонента. это делается в основном для компонентов, которые повторяются или могут повторяться в приложении.

Что касается микширования SASS, они могут быть преобразованы в функции javascript, поэтому здесь нет большого преимущества для SASS.

В целом, работа со Styled-Components - это весело и легко, но имеет побочный эффект более тесной связи между стилями и каркасом/компонентом и, очевидно, имеет некоторое снижение производительности (ничего, что на самом деле не замедлит вас, но все же),

Ответ 3

Два из четырех ключевых пунктов упомянутой вами статьи Google Reflow были следующими:

• Минимизируйте правила CSS и удалите неиспользуемые правила CSS.

• Избегайте ненужных сложных CSS-селекторов - в частности, потомков-селекторов - которые требуют больше ресурсов процессора для сопоставления селекторов.

При правильном использовании это побочный продукт использования Styled-Components в React.

При традиционных подходах к стилизации, особенно в больших командах, неиспользуемые/дублированные правила CSS имеют тенденцию накапливаться. Разработчик может не знать, что данное правило будет работать, и поэтому добавит новое. Или компонент будет удален, и используемый им CSS может быть не удален, поскольку они не уверены, использовался ли он где-либо еще.

А поскольку стили, как правило, изолируются от компонента с помощью Styled Components/CSS-in-JS, мы обычно избегаем этих ужасных потомков.

Кроме того, когда я полагаю, что "используется должным образом", я имею в виду не иметь стили, разбросанные по всему приложению, а вместо этого создать набор компонентов, который содержит все стилизованные базовые компоненты, используемые приложением, возможно, реализуя тему.

Существует пример React/React-Bootstrap для Code Sandbox, использующего стилизованные компоненты для такой изоляции CSS, и статью, подробно описывающую подход к CSS-хитростям. Основное внимание было уделено тому, как стилизованные компоненты могут помочь вам перейти от быстрой и грязной реализации React-Bootstrap к пользовательской теме, которая в конечном итоге реорганизует зависимость React-Bootstrap. Но это также полезно для демонстрации того, как его можно использовать для достижения тех двух ключевых оптимизаций перекомпоновки, которые упомянуты в статье Google.

Другие два момента менее актуальны для обсуждения CSS против CSS-in-JS:

• Уменьшите ненужную глубину DOM. Изменения на одном уровне в дереве DOM могут вызвать изменения на каждом уровне дерева - вплоть до корня и вплоть до потомков модифицированного узла. Это приводит к увеличению времени, затрачиваемого на выполнение оплавления.

• Минимизируйте правила CSS и удалите неиспользуемые правила CSS. Если вы делаете сложные изменения рендеринга, такие как анимация, делайте это из потока. Используйте абсолютное положение или фиксированное положение для достижения этой цели.

Те, которые вы бы посоветовали, независимо от стиля. Но первые два, я думаю, вы можете охватить, используя стилизованные компоненты, как я описываю, то есть создать набор компонентов и сохранить все ваши стили в его компонентах. Затем создайте свое приложение с помощью этого комплекта.