弥合 CSS 和 JavaScript 之间的差距：CSS-in-JS

在本文中，我们将深入探讨 CSS-in-JS 的概念。如果您已经熟悉此概念，您可能仍然会喜欢浏览这种方法的哲学，您可能对下一篇文章更感兴趣。

Web 开发是一个高度跨学科的领域。我们习惯于与多种语言密切合作。而且，随着 Web 应用程序开发变得越来越普遍和细致入微，我们经常寻找创造性的方法来弥合这些语言之间的差距，以使我们的开发环境和工作流程更轻松、更高效。

最常见的示例通常是在使用模板语言时。例如，一种语言可以用来生成更冗长的语言（通常是 HTML）的代码。这是前端框架的关键方面之一 - 操纵 HTML 应该是什么样子？这方面的最新变化是 JSX，因为它实际上不是模板语言；它是 JavaScript 的语法扩展，它使使用 HTML 变得非常简洁。

Web 应用程序会经历许多状态组合，仅管理内容通常具有挑战性。这就是为什么 CSS 有时会被忽视 - 尽管通过不同的状态和媒体查询管理样式同样重要且具有挑战性。在本系列的两个部分中，我想重点关注 CSS 并探索它与 JavaScript 之间的桥梁。在本系列中，我将假设您正在使用像 webpack 这样的模块打包器。因此，我将在示例中使用 React，但相同或类似的原理也适用于其他 JavaScript 框架，包括 Vue。

CSS 领域正在向许多方向发展，因为有很多挑战需要解决，而且没有“正确”的路径。我一直花了很多精力尝试各种方法，主要是在个人项目中，所以本系列的意图只是为了**通知**，而不是规定。

CSS 的挑战

在深入代码之前，有必要解释为 Web 应用程序设置样式的最显著挑战。我将在本系列中讨论的挑战包括作用域、条件和动态样式以及可重用性。

作用域

作用域是众所周知的 CSS 挑战，它指的是编写不会泄漏到组件之外的样式的理念，从而避免意外的副作用。我们希望在理想情况下实现它，同时又不影响创作体验。

条件和动态样式

虽然前端应用程序中的状态开始变得越来越复杂，但 CSS 仍然是静态的。我们只能有条件地应用样式集 - 如果一个按钮是主按钮，我们可能会应用“primary”类，并在单独的 CSS 文件中定义它的样式，以应用它在屏幕上的外观。拥有几个预定义的按钮变体是可以管理的，但如果我们想要有各种各样的按钮，比如为 Twitter、Facebook、Pinterest 等定制的按钮呢？我们真正想做的是简单地传递一种颜色并使用 CSS 定义状态，比如悬停、聚焦、禁用等。这称为动态样式，因为我们不再在预定义样式之间切换 - 我们不知道接下来会发生什么。内联样式可能会出现在脑海中以解决这个问题，但它们不支持伪类、属性选择器、媒体查询或类似的东西。

可重用性

重用规则集、媒体查询等一直是我最近很少见到的一个话题，因为 Sass 和 Less 等预处理器已经解决了这个问题。但我仍然想在本系列中重新讨论它。

在本系列的两个部分中，我将列出一些处理这些挑战的技术及其局限性。没有一种技术优于其他技术，它们甚至不是互斥的；您可以根据决定哪些内容可以提高项目质量来选择一种或多种技术。

设置

我们将使用名为Photo的示例组件演示不同的样式技术。我们将渲染一个自适应图像，该图像可能具有圆角，同时显示替代文本作为标题。它将像这样使用

<Photo publicId="balloons" alt="Hot air balloons!" rounded />

在构建实际组件之前，我们将抽象掉srcSet属性以使示例代码简洁。因此，让我们创建一个utils.js文件，使用Cloudinary生成不同宽度的图像的两个实用程序

import { Cloudinary } from 'cloudinary-core'

const cl = Cloudinary.new({ cloud_name: 'demo', secure: true })

export const getSrc = ({ publicId, width }) =>
  cl.url(publicId, { crop: 'scale', width })

export const getSrcSet = ({ publicId, widths }) => widths
  .map(width => `${getSrc({ publicId, width })} ${width}w`)
  .join(', ')

我们设置了 Cloudinary 实例以使用 Cloudinary 演示云的名称，以及它的url方法以根据指定的选项为图像publicId生成 URL。我们只对在本组件中修改宽度感兴趣。

我们将分别使用这些实用程序来处理src和srcset属性

getSrc({ publicId: 'balloons', width: 200 })
// => 'https://res.cloudinary.com/demo/image/upload/c_scale,w_200/balloons'

getSrcSet({ publicId: 'balloons', widths: [200, 400] })
// => 'https://res.cloudinary.com/demo/image/upload/c_scale,w_200/balloons 200w,
      https://res.cloudinary.com/demo/image/upload/c_scale,w_400/balloons 400w'

如果您不熟悉srcset和sizes属性，我建议先阅读一些关于自适应图像的信息。这样，您在阅读示例时会更容易理解。

CSS-in-JS

CSS-in-JS 是一种样式方法，它将 CSS 模型抽象到组件级别，而不是文档级别。这个想法是，CSS 可以作用于特定的组件 - 而且只有那个组件 - 在这种程度上，这些特定的样式不会与其他组件共享或泄漏到其他组件，并且只有在需要时才会被调用。CSS-in-JS 库通过在<head>中插入<style>标签来在运行时创建样式。

最早使用此概念的库之一是JSS。下面是一个使用其语法的示例

import React from 'react'
import injectSheet from 'react-jss'
import { getSrc, getSrcSet } from './utils'

const styles = {
  photo: {
    width: 200,
    '@media (min-width: 30rem)': {
      width: 400,
    },
    borderRadius: props => (props.rounded ? '1rem' : 0),
  },
}

const Photo = ({ classes, publicId, alt }) => (
  <figure>
    <img
      className={classes.photo}
      src={getSrc({ publicId, width: 200 })}
      srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
      sizes="(min-width: 30rem) 400px, 200px"
    />
    <figcaption>{alt}</figcaption>
  </figure>
)
Photo.defaultProps = {
  rounded: false,
}

export default injectSheet(styles)(Photo)

乍一看，styles对象看起来像是用对象表示法编写的 CSS，具有额外的功能，比如传递一个函数来根据道具设置值。生成的类是唯一的，因此您永远不必担心它们与其他样式冲突。换句话说，您可以免费获得作用域！大多数 CSS-in-JS 库的工作方式就是这样 - 当然，在功能和语法上有一些变化，我们将在后面的内容中介绍。

您可以通过属性看到，渲染图像的宽度从200px开始，然后当视口宽度至少为30rem时，宽度增加到400px。我们生成了一个额外的800源来覆盖更大的屏幕密度

1x 屏幕将使用200和400
2x 屏幕将使用400和800

styled-components是另一个 CSS-in-JS 库，但它使用更熟悉的语法，巧妙地利用了标记模板文字而不是对象，使其看起来更像 CSS

import React from 'react'
import styled, { css } from 'styled-components'
import { getSrc, getSrcSet } from './utils'

const mediaQuery = '(min-width: 30rem)'

const roundedStyle = css`
  border-radius: 1rem;
`

const Image = styled.img`
  width: 200px;
  @media ${mediaQuery} {
    width: 400px;
  }
  ${props => props.rounded && roundedStyle};
`
  
const Photo = ({ publicId, alt, rounded }) => (
  <figure>
    <Image
      src={getSrc({ publicId, width: 200 })}
      srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}
      sizes={`${mediaQuery} 400px, 200px`}
      rounded={rounded}
    />
    <figcaption>{alt}</figcaption>
  </figure>
)
Photo.defaultProps = {
  rounded: false,
}

export default Photo

我们经常创建语义上中立的元素，比如<div>和<span>，仅仅是为了样式化目的。这个库以及许多其他库允许我们以单一操作的方式创建和设置它们的样式。

我最喜欢的这种语法的优点是它就像普通的 CSS 一样，只是没有插值。这意味着我们可以更轻松地迁移我们的 CSS 代码，并且可以使用我们现有的肌肉记忆，而不是不得不熟悉用对象语法编写 CSS。

请注意，我们可以将几乎任何东西都插值到我们的样式中。这个具体的示例演示了如何将媒体查询保存到变量中并在多个地方重用它。自适应图像非常适合这种情况，因为sizes属性基本上包含 CSS，因此我们可以使用 JavaScript 使代码更加DRY。

假设我们决定要视觉上隐藏标题，但仍然让屏幕阅读器可以访问它。我知道一个更好的方法是使用alt属性，但为了这个示例，让我们使用另一种方法。我们可以使用一个称为polished的样式混合库 - 它与 CSS-in-JS 库配合得很好，非常适合我们的示例。这个库包含一个称为hideVisually的混合，它正好满足我们的需求，我们可以通过插值它的返回值来使用它

import { hideVisually } from 'polished'

const Caption = styled.figcaption`
  ${hideVisually()};
`

<Caption>{alt}</Caption>

即使 hideVisually 输出一个对象，styled-components 库也懂得如何将它作为样式进行插值。

CSS-in-JS 库拥有许多高级功能，例如主题、供应商前缀，甚至内联关键 CSS，这使得完全停止编写 CSS 文件变得容易。在这一点上，你开始明白为什么 CSS-in-JS 变得如此吸引人。

缺点和局限性

CSS-in-JS 的明显缺点是它引入了运行时：样式需要通过 JavaScript 加载、解析和执行。CSS-in-JS 库的作者添加了各种智能优化，例如 Babel 插件，但仍然会存在一些运行时成本。

同样重要的是要注意，这些库不会被 PostCSS 解析，因为 PostCSS 不是为了被引入运行时而设计的。因此，许多人使用 stylis 作为替代，因为它速度更快。这意味着我们不幸地不能使用 PostCSS 插件。

我将提到的最后一个缺点是工具。CSS-in-JS 正在快速发展，文本编辑器扩展、代码检查器、代码格式化器等需要赶上新功能才能保持同步。例如，人们正在使用 VS Code 扩展 styled-components 来使用类似 styled-components 的 CSS-in-JS 库，例如 emotion，即使它们并不都具有相同的特性。我甚至看到提出的功能的 API 选择受到保留语法高亮的目標的影响！

未来

有两个新的 CSS-in-JS 库，Linaria 和 astroturf，它们通过将 CSS 提取到文件中实现了零运行时。它们的 API 与 styled-components 相似，但在功能和目标上有所不同。

Linaria 的目标是模仿 styled-components 等 CSS-in-JS 库的 API，通过内置功能（如作用域、嵌套和供应商前缀）来实现。相反， astroturf 是基于 CSS 模块构建的，插值能力有限，鼓励使用 CSS 生态系统而不是依赖 JavaScript。

如果你想尝试使用它们，我为这两个库构建了 Gatsby 插件。

使用这些库时，请牢记两点。

拥有实际的 CSS 文件意味着我们可以使用熟悉的工具（如 PostCSS）来处理它们。
Linaria 在幕后使用自定义属性（也称为 CSS 变量），请务必考虑它们在浏览器中的支持情况，然后再使用此库。

结论

CSS-in-JS 是用于弥合 CSS 和 JavaScript 之间的差距的一体化样式解决方案。它们易于使用，并包含有用的内置优化——但所有这些都需要付出代价。最值得注意的是，通过使用 CSS-in-JS，我们实际上是从 CSS 生态系统中退出，并依赖 JavaScript 来解决我们的问题。

零运行时解决方案通过带回 CSS 工具来缓解一些缺点，这将 CSS-in-JS 的讨论提升到了一个更有趣的层次。与 CSS-in-JS 相比，预处理工具的实际限制是什么？这将在本系列的下一部分中介绍。

文章系列

CSS-in-JS（本文）
CSS 模块、PostCSS 和 CSS 的未来

chris craig

# 2018 年 12 月 3 日

如果你使用以下元标记：http-equiv=”Content-Security-Policy” content=”default-src ‘self'”，以尝试阻止 XSS 攻击，那么如果你使用这种系统，这是否会阻止注入的内联样式起作用？反过来说，您是否通过注入内联样式创建了漏洞？

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

有趣，请告诉我更多！举例说明？此外，CSS-in-JS 不会注入内联样式，你是指 style 标签吗？
chris craig

评论永久链接# 2018 年 12 月 4 日

感谢您的回复，Matija。举个例子，这个元标记：被用在这个网站上： http://www.nown.org.au/ 是为了防止 XSS 攻击——恶意代码的注入。详细信息/原因可以在这个链接中找到： https://developers.google.com/web/fundamentals/security/csp/
以这种方式使用内容安全策略会阻止浏览器使用任何不是来自存储 HTML 的服务器的代码，据我所知。
然而，结果是，浏览器将无法识别或运行任何内联 js 代码（例如：onclick=”myFunction()”）或任何内联 CSS（例如 style =”color:black;”）。并且头部部分的 style 标签也会失效；根本不起作用。
所有你的 JS 和 CSS（以及 JQuery）都必须来自与页面存储在同一服务器上的单独文件；即“self”。
所以这就是我的问题：CSS-inJS 注入（例如）style 标签是否与使用严格的内容安全策略（如“self”）兼容？
如果是，这是否会创建一个漏洞？
或者我完全搞错了？
Matija Marohnić

评论永久链接# 2019 年 2 月 14 日

抱歉回复得这么晚，我一直把这个放在我的收件箱里，因为我想查看一下。确实，它会阻止注入样式，我刚刚试过了！不过，似乎可以使用 nonce 来解决它。我不知道这个问题有多大，因为安全不是我的强项。但是 styled-components 有关于此的资料。

Ben

我强烈反对 CSS-in-JS，主要是因为它违背了关注分离原则。
CSS-in-JS 试图解决的问题很大程度上是由于开发人员对 CSS 的知识和经验不足造成的。样式不会“泄漏”。CSS 中的 C 代表“级联”，这意味着 CSS 的全部精神是“向下泄漏”。这是一个特性，而不是弱点，你只需要学习如何使用它。有一些技巧和方法可以做到这一点，而且它们可以完美地扩展。

一个象征？你导入的“hideVisually”。你正在导入一个 JS 对象，它旨在将一个预制类插入到你的组件中，并将其与页面上的其他部分隔离开来。你难道不认为这正是 CSS 的用途吗？将这个类作为标准 CSS 类，在整个页面上可用，在需要它的组件上调用它？它将被共享，没有处理时间，只是纯粹的 CSS。

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

CSS-in-JS 的确切好处在网络上的其他地方有更好的说明，它们不适合放入一篇文章中。这更像是一个概述，为第二部分做铺垫。

本系列的两个部分密切相关，你可能更喜欢第二部分。;)

unleashit

所以如果 CSS in JS 的发展趋势是在编译时提取它（我同意），为什么不直接使用 SASS 呢？与组件级 CSS 模块结合使用，你会得到 CSS in JS 的所有功能，但没有大量的额外样板/语法、性能开销和无数实现。当你需要它时，你还有一个一流的级联系统可用，因为，嗯……你正在设计一个主题，它应该为某个东西提供独特的品牌。

我相信这听起来很生气（是的，我见过那些聪明、爱炫耀的时髦人士的模因），但在我见过的所有前端变化中，大多数都让我兴奋，但这件事让我感到沮丧，以至于我时常怀疑我是否还想要继续做前端开发。我绝对讨厌进入一个使用 CSS in JS 的项目。它会将组件变成一团乱麻，如果不分离关注点或无法快速迭代和重用 20 年的社区 CSS，就很难推理。更不用说它的各种架构了。它会极大地减慢我的速度，而且不好玩。我是一个热爱优质代码的全栈开发人员。

主要问题是 CSS 模块的出现太晚了，很多人都没有注意到。CSS 模块证明了关于封装的论点是虚假的，这种论点不应该再被用来作为论点。SASS、LESS 拥有你需要的灵活性。它们所做的很多事情在运行时是不必要的。使用 CSS in JS，你既在运送大量额外的字节，又在做比使用简单样式元数据更多的处理。

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

我理解你的沮丧。作为一个样式爱好者，我一直在拼命地寻找最佳实践，虽然我很享受 CSS-in-JS 的灵活性，但我无法跟上它。这让我找到了本系列的第二部分，我建议你看一下。;)

TheSanta (@TheHanna)

严肃问题：与简单地替换一两个类或使用构建工具来实现相同效果相比，CSS-in-JS 的用例是什么？也许我参与的应用程序规模还不够大，无法看到其益处，但我就是不相信这是一个好主意。

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

这条 Twitter 线程可能会有所帮助。

Dmitri

# 2018 年 12 月 4 日

我是一个有点老派的开发者。我记得我们曾经为了将 HTML、CSS 和 JS 分开而进行了艰苦的斗争，当人们开始分别存储 HTML、JS 和 CSS 时，这在 web 开发中是一场伟大的胜利。如今，新一代的 web 开发者登场了，一切都回到了我们大约 15 年前开始的地方。抱歉，但对我来说，CSS-in-JS 的想法是不可接受的。我已经看到了它可能导致的结果。

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

CSS-in-JS 只是其中一种方法，本系列的第二部分介绍了一种现代方法来处理老式的 CSS。;)

Bob Hamblok

CSS-in-JS 肯定可以帮助很多人。某些实现方式可能工作得很好……如果并且只有如果它们以一种明智的方式实现。
然而，CSS-in-JS 的实现方式，尤其是在本文中提到的从“props”中注入值（作为 JS 变量）的方式，可能会直接影响我们心爱的浏览器的渲染循环的性能！

这是因为，不幸的是，并非所有开发者都了解浏览器的内部工作原理。大多数人读完这篇文章后甚至不会记得其中提到的缺点。因此，在 W3C 等标准化组织提出一个适当的解决方案之前，请不要提倡使用 CSS-in-JS。
这篇文章有可能让“互联网”变得更糟，而不是更好。
想想用户的幸福，而不是开发者的幸福！

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

有很多因素需要考虑。例如，内联关键 CSS 也能让用户满意，但这很难做到，所以许多开发者都没有这样做。CSS-in-JS 可以免费为您提供它。:)

请注意，CSS-in-JS 库的作者一直在优化它们，甚至去除了运行时！重要的是检查 CSS-in-JS 实际编译后的内容。
Ashley Sheridan

评论永久链接# 2018 年 12 月 6 日

Matija Marohnić，你无法完全去除运行时，那样整个东西就会退回到普通的旧 CSS。CSS-in-JS 的确存在性能损失，这将永远存在。
Matija Marohnić

评论永久链接# 2018 年 12 月 6 日

Ashley，大多数 CSS-in-JS 库确实有运行时，是的，但 astroturf 和 Linaria 没有运行时，这就是我所指的。自己看看，它们编译成实际的 CSS 文件。现在，这是否是一个好主意，取决于你。;)

Ramon

我真想弄清楚这一点，但我一直想：如果你了解 CSS，CSS“泄漏”就永远不会成为问题。我遇到的唯一问题是库中存在不好的 CSS。我只要删除这些样式，然后快速重写以适合项目。

如果你真的不喜欢级联的东西，为什么不使用 ID？React 由模块构成，给该模块一个 ID，然后从那里进行样式化——完成了。样式将永远不会泄漏。我认为这是一种不好的做法，但它本质上与将 CSS 模块化相同？这是否也意味着模块化是一种不好的做法？你仍然需要一些全局样式，对吧？

我仍然不明白 CSS-in-JS 应该带来的好处。我一直在想我是不是忽略了什么，我真的很想理解。

Matija Marohnić

评论永久链接# 2018 年 12 月 4 日

好处远不止模块化，这条 Twitter 线程可能会有所帮助。就我个人而言，我正在寻找替代方案，所以请查看本系列的第二部分。;)

Jason Jon Derifaj

# 2018 年 12 月 5 日

JS 组件中的 CSS 越来越受欢迎，因为传统主义者正在被挤出 FED 游戏，纯 JS 程序员正在取代他们，而不是因为这是一个更好的主意……实际上它并不是。

这感觉像是一种潮流，而且是一个糟糕的主意……因为它就是。

Scott Williams

# 2018 年 12 月 7 日

Javascript 中的 CSS 是一个糟糕的主意！层叠样式表的真正优势之一是层叠，大多数现代开发者都不理解它带来的强大功能。如今，人们不再将 CSS 视为皮肤，也不再将 HTML 视为脚手架。将关注点分离还可以让开发者并行工作，一个人负责脚手架，另一个人负责皮肤。还有人记得http://www.csszengarden.com吗？展示了 CSS 的真正力量！（我可以写一篇关于这个主题的文章，也许我将来会写。;)

jiveturkeyJay

# 2018 年 12 月 10 日

只使用过一次 CSS-in-JS，使用的是 styled components，那是一次糟糕且令人沮丧的体验，比使用普通样式表复杂得多，但可重用性更低。我们使用了 3 个库来实现比只使用 CSS 更复杂的解决方案，在我看来，这显得非常过度设计，而且违背了关注点分离的旧原则。

我同意这里其他人的观点，CSS in JS 被推崇的原因是许多开发者不想学习如何正确使用 CSS，这很不幸，因为精通 CSS 并结合合理的 HTML 可以使用最少的代码创建最优雅、最简单的解决方案。似乎开发者体验正变得比用户体验更重要，即事情都是为了让开发者受益，而不是用户。

我猜我是在对牛弹琴。