样式化组件与 SASS（SCSS）或 LESS [关闭]

Question

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

我对@9​​87654321@的理解：

1. 组件驱动的理念。您的 CSS 现在也是一个组件。 - 这很酷！
2. 加载你需要的东西，在你需要的时候，有点懒惰的 CSS
3. 主题提供程序、皮肤、模块化和动态 - 这也可以通过其他库实现
4. 组件 DOM 的服务器端构造及其样式。

我的问题是：

1. 浏览器已经进化为将 CSS 与 Javascript 分开解析 解析，为什么我们试图偏离这个并适应所有 Javascript？

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

   （通过上述问题，我的意思是对于加载的每个组件，通过style 标签/多个样式标签 - 重新发明 CSS 解释器来计算、创建和插入相应的 CSS） p>

3. 是否通过<style /> 在 head 标签导致浏览器重排/重绘？

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

5. 使用附加库/选项，如 Post-CSS 和 SCSS classname hashing 用于动态类名，这几乎解决了每个人所说的问题。为什么 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

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 元素提取到其自己的 styled 组件中。它主要用于在应用程序中重复或可能重复的组件。

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

总体而言，使用 Styled-Components 既有趣又简单，但有一个副作用是样式与框架/组件之间的耦合更紧密，而且显然会带来一些性能损失（实际上不会减慢您的速度，但仍然）。

Answer 2

浏览器已经进化为将 CSS 与 Javascript 解析分开来解析，为什么我们要尝试偏离这一点并适应所有 Javascript？

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

然后，函数式魔法发生了：因为 JSX 是返回“HTML”（不是真的）的原始数据的纯函数，就像 CSS-in-JS 是返回“CSS”的纯函数或原始数据一样（也不是真的）。从这一点来说，我觉得值得reading about JSX和also about CSS-in-JS。

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

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

为什么需要这个？

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

你选择图书馆是因为它可以解决问题。如果似乎没有问题，为什么还要使用库，对吧？

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

有so many things that force reflow。

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

the scope and complexity of style (re)calculations 有一个很好的介绍，非常值得一读以更深入地了解该主题。