Styled-component CSS比SASS还是LESS更好？

Question

我遇到了一个反应良好的ReactJS Boilerplate,并且是社区驱动的.样式部分更多地强调了样式化组件CSS,但从未停止过切换到传统的CSS样式方法.虽然这引起了我的兴趣,但是什么使得Styled-Component CSS脱颖而出,为什么需要采用它.

我对Styled组件CSS的理解:

1. 组件驱动的思想.您的CSS现在也是一个组件.- 这很酷!
2. 加载你需要的东西,当你需要时,有点懒惰的CSS
3. 主题提供者,皮肤,模块化和动态 - 这也可以通过其他库来实现
4. 组件DOM的服务器端构造及其样式.

我的问题是:

1. 浏览器的发展是为了解析CSS与Javascript解析分开,为什么我们试图偏离这个并适合所有Javascript？

2. Styled-component CSS将其javascript库发送到客户端,它实际上在运行时解析样式,并<style />在每个组件按需加载时放入内部标记.这意味着额外的负载和逻辑最终会导致浏览器的执行周期.为什么需要这个？

   (通过上面的问题,我的意思是每个组件加载相应的CSS计算和创建并通过style标签/多个样式标签插入头部- 重新发明CSS解释器)

3. <style />在head标记中连续计算的样式文本是否导致浏览器重排/重绘？

4. 我从中获得了哪些性能优势？

社区,请为我清空或纠正我,如果我错了.

---

一些关于重绘或DOM的好文章重新介绍了修改CSS样式时浏览器的性能代价.

• https://developers.google.com/speed/articles/reflow
• http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/
• https://www.sitepoint.com/10-ways-minimize-reflows-improve-performance/
• https://www.phpied.com/rendering-repaint-reflowrelayout-restyle/
• https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Using_dynamic_styling_information

Answer 1

我已经使用SCSS( SASS) 多年了，并且还Styled-Components用于一些项目，一些大型项目。

我喜欢两者，Styled-Components对我来说，感觉就像向前迈进了一步：

样式组件 - 优点

1. 完全造型隔离；防止在团队中工作时潜在的错误，当一个团队成员永远不能覆盖另一个团队成员的风格时。（除非多个地方共享相同的样式组件）
2. 无需手动处理类名，因为它们会自动生成（恕我直言，选择名称的组件比类名更容易）

3. 我发现在JSX文件本身中使用CSS更容易（多年来反对我的判断）

4. 在样式中轻松使用 javascript 变量（消除对 2 组主题变量的需要）

样式组件 - 缺点

1. 每个样式组件都是另一个包装函数，许多样式组件意味着更多的功能，这意味着效率较低，因为所有代码都需要“编译”等等。
2. 最大的缺点：对样式的更改需要重新编译包，并且应用程序的状态可能会重置。

缺点只能在某些情况下被视为这样，但不一定是全部。

SCSS/LESS优点可以被视为与上面列出的缺点相反，同时还有一些缺点，例如在使用变量时混合和更快的开发（恕我直言）。定义局部选择器变量可能会变得“丑陋”：

比较这些简化的例子：

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 可能由样式化的子组件组成，看起来更像 CSS：

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

   li{
     ...
   }

   img{...}

   navigation{...}
`

并非总是希望将每个单独的 HTML 元素提取到其自己的样式组件中。它主要用于在应用程序中重复或可能重复的组件。

关于SASS混合，它们可以转换为javascript函数，所以这里SASS没有太大的优势。

总体而言，使用 Styled-Components 既有趣又容易，但在样式和框架/组件之间具有更紧密的耦合的副作用，并且它显然有一些性能损失（实际上并不会减慢您的速度，但仍然如此）。

Answer 2

浏览器进化为将 CSS 与 Javascript 解析分开来解析，为什么我们试图偏离这一点而将所有内容都放在 Javascript 中？

当您混合使用 Javascript 和 HTML（即 JSX），然后混合使用 CSS（JSS 或其他）时，您可以使您的组件成为适合单个文件的可靠模块。您不再需要将样式保存在单独的文件中。

然后，功能魔法发生了：由于 JSX 是返回“HTML”的原始数据的纯函数（不是真的），同样的方式 CSS-in-JS 是返回“CSS”的纯函数或原始数据（也不是真的） ）。从这一点来看，我认为关于 JSX和CSS-in-JS 都值得一读。

Styled-component CSS 将其 javascript 库发送到客户端，它实际上在运行时解析样式并<style />在每个组件按需加载时放入标签。这意味着额外的负载和逻辑最终会影响浏览器的执行周期。

不仅在运行时。因为 CSS-in-JSS 只是一个返回 CSS 的数据函数，所以你可以在任何平台上使用它。以 Node 为例，添加SSR，然后您将style元素传递到响应正文中的浏览器，因此解析就像在获取 CSS 传递的原始情况下发生的那样。

为什么需要这个？

因为它在开发中很方便，就像 React 或 Redux，就像 jQuery，就像任何其他 lib 一样，它以网络负载和浏览器性能为代价。

你拿图书馆是因为它解决了一个问题。如果似乎没有问题，为什么要使用库，对吗？

<style />在 head 标签中连续计算的样式文本是否会导致浏览器回流/重绘？

有这么多的事情，力回流。

浏览器很聪明。如果样式没有改变，他们甚至不会尝试重新粉刷。这并不意味着他们不计算差异，这会消耗 CPU 时间。

有一个关于样式（重新）计算的范围和复杂性的很好的介绍，非常值得阅读以更深入地了解该主题。