样式-组件与SASS (SCSS)或更少

Question

我偶然发现了一个ReactJS样板，它有很好的代表，并且是社区驱动的。样式部分更强调样式化组件CSS，但从未停止切换到常规CSS样式化方法。虽然这吸引了我的兴趣，是什么使样式组件CSS脱颖而出，以及为什么需要采用它。

我对样式组件CSS 的理解

1. 组件驱动的思想。您的CSS现在也是一个组件。-，这太酷了！
2. 加载您需要的内容，当您需要时，有些懒惰的CSS
3. 主题提供程序、皮肤、模块化和动态--这也可以通过其他lib实现。
4. 组件DOM及其样式的服务器端构造。

我的问题是：

1. 浏览器被进化成独立于Javascript解析的CSS解析，为什么我们试图偏离这一点，把所有的东西都放在Javascript中呢？
2. 样式组件CSS将其javascript库传递到客户端，客户端实际上在运行时解析样式，并在每个组件按需加载时将其放入<style />标记。这意味着额外的负载和逻辑最终导致浏览器上的执行周期。为什么需要这个？ (我的意思是，对于加载的每个组件，通过style标记/多样式标记-重新发明CSS解释器，计算、创建并插入相应的CSS )。
3. 通过头标签中的<style />连续计算样式文本是否会导致浏览器再流/重新绘制？
4. 我从这个节目中得到了什么表现优势？
5. 使用附加库/选项，如后CSS & SCSS类散列，用于动态类名，这很大程度上解决了每个人都认为的问题。为什么SC还在？

社区，请为我清除空气或纠正我如果我是错的。

一些关于重新绘制或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/
• 信息

Answer 1

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

我两样都爱，Styled-Components觉得，对我来说，这是向前迈出的一步：

造型.部件. Pros

1. 完全的样式隔离；在团队中工作时防止潜在的错误，当一个团队成员永远不能覆盖另一个样式时。(除非多个地方共享相同的样式组件)
2. 删除需要手动处理的类名，因为它们是自动生成的(取名组件要比类名容易一些)。
3. 我发现在JSX文件本身内使用CSS更容易(多年前我一直反对我的判断)
4. 在样式中轻松使用javascript变量(消除了对2组主题变量的需求)

造型.部件.锥

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

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

   li{
     ...
   }

   img{...}

   navigation{...}
`

并不总是希望将每个单独的HTML元素提取到自己的样式组件中。这主要是为组件，是或可能重复整个应用程序。

关于SASS混合，可以将它们转换为javascript函数，因此在这里SASS没有多大的优势。

总的来说，使用样式组件是很有趣和容易的，但是有一个副作用，就是样式和框架/组件之间的耦合更紧密，而且它显然有一些性能上的损失(没有什么能真正减慢您的速度，但仍然如此)。

Answer 2

浏览器被进化成独立于Javascript解析的CSS解析，为什么我们试图偏离这一点，把所有的东西都放在Javascript中呢？

当您将Javascript和HTML (即JSX)和CSS (JSS或其他组件)混合在一起时，您可以使组件成为一个适合于单个文件的坚实模块。您不再需要将样式保存在单独的文件中了。

然后，函数魔术发生了:由于JSX是一个纯函数的原始数据，返回"HTML“(不完全)，同样的CSS-in-JS是一个纯函数或原始数据，返回"CSS”(也不是真的)。从这一点出发，我认为值得阅读JSX和也是关于CSS in JS的。。

样式组件CSS将其javascript库传递到客户端，客户端实际上在运行时解析样式，并在每个组件按需加载时将其放入<style />标记。这意味着额外的负载和逻辑最终导致浏览器上的执行周期。

不只是在跑步的时候。因为CSS只是返回CSS的数据函数，所以您可以在任何平台上使用它。以Node为例，添加SSR，然后将style元素在响应体中传递到浏览器中，因此进行解析，就像在最初获得CSS传递的情况下一样。

为什么需要这个？

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

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

通过头标签中的<style />连续计算样式文本是否会导致浏览器再流/重新绘制？

有太多的东西会迫使我们重新流动。

浏览器很聪明。如果样式没有改变，他们甚至不会尝试重新油漆。这并不意味着他们不计算差额，这需要花费CPU时间。

有一个很好的介绍样式计算的范围和复杂性，它真的值得阅读，以更深入地理解这一主题。