我遇到了一个ReactJS样板，它有很好的代表并且是社区驱动的。 样式部分更多地强调样式化组件 CSS，但从未停止切换到传统的 CSS 样式方法。虽然这引起了我的兴趣，但是什么让样式组件CSS脱颖而出，为什么需要采用它。
我对样式化组件 CSS 的理解：
- 组件驱动理念。您的 CSS 现在也是一个组件。-这很酷！
- 加载你需要的东西，当你需要的时候，有点懒惰的CSS
- 主题提供程序，皮肤，模块化和动态 - 这也可以通过其他库实现
- 组件 DOM 及其样式的服务器端构造。
我的问题是：
-
浏览器被进化为独立于Javascript解析CSS。 解析，我们为什么要试图偏离这一点并适应所有内容 Javascript？
-
样式化组件 CSS 将其 JavaScript 库发送到客户端， 它实际上在运行时解析样式，并在每个组件按需加载时放入
<style />标记中。这意味着额外的负载 和逻辑最终有助于浏览器上的执行周期。 为什么需要这个？(通过上面的问题，我的意思是对于加载的每个组件，通过
style标签/多个样式标签 - 重新发明 CSS 解释器计算、创建并插入到头部中) -
连续计算样式文本是否通过
<style />头标签导致浏览器重排/重绘？ -
我从中获得了哪些性能优势？
-
使用附加库/选项，如动态类名的Post-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/
- https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Using_dynamic_styling_information
我已经使用SCSS(SASS)很多年了，并且一直在一些项目中使用Styled-Components，其中一些是大型的。
我两者都喜欢，对我来说，Styled-Components感觉就像向前迈出了一步：
样式化组件 - 优点
- 完全样式隔离;防止在团队中工作时的潜在错误，当一个团队成员永远无法覆盖另一个团队成员的样式时。(除非多个位置共享同一样式组件)
- 无需在自动生成类名时手动处理类名(恕我直言，选择名称组件比类名更容易) 我
发现在JSX文件本身中使用CSS更容易(反对我多年前的判断)
在样式中轻松使用javascript变量(无需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是有趣和容易的，但有一个副作用，即样式和框架/组件之间更紧密的耦合，并且显然有一些性能损失(没有什么会真正减慢你的速度，但仍然如此)。
浏览器被进化为将CSS与Javascript解析分开解析，为什么我们试图偏离这一点并适合Javascript？
当你混合Javascript和HTML(即JSX)和CSS(JSS或其他)时，你使你的组件成为一个适合单个文件的固体模块。您不再需要将样式保存在单独的文件中。
然后，函数魔术发生了：由于JSX是返回"HTML"(不是真的)的原始数据的纯函数，就像CSS-in-JS是返回"CSS"的纯函数或原始数据一样(也不是真的)。从这一点来看，我认为值得一读JSX和CSS-in-JS。
样式化组件 CSS 将其 javascript 库交付到客户端，客户端实际上在运行时解析样式，并在每个组件按需加载时放入
<style />标记中。这意味着额外的负载和逻辑最终会导致浏览器上的执行周期。
不仅在运行时。因为 CSS-in-JSS 只是返回 CSS 的数据函数，所以你可以在任何平台上使用它。以 Node 为例，添加 SSR，您将style元素在响应正文中传递到浏览器，因此解析就像在原始交付 CSS 的情况下发生的那样。
为什么需要这个？
因为它在开发中很方便，就像 React 或 Redux 一样，就像 jQuery 一样，就像任何其他库一样，它以网络负载和浏览器性能为代价。
你拿一个库，因为它解决了问题。如果似乎没有问题，为什么要使用库，对吧？
通过 head 标签中的
<style />连续计算样式文本是否会导致浏览器重排/重绘？
有很多东西迫使回流。
浏览器很聪明。如果样式没有改变，他们甚至不会尝试重新绘制。这并不意味着他们不计算差异，这会消耗 CPU 时间。
对样式(重新)计算的范围和复杂性有一个很好的介绍，非常值得一读以更深入地理解该主题。