浅谈 tailwindcss 的原理

7,183 阅读3分钟

起源看到 earlyBirdCamp 用到了 tailwindcss,然后顺势了解一番

tailwindcss 是什么

如果打开 tailwindcss 的 github仓库,大概会一脸蒙,怎么 css 框架一堆 js ,而且 css 文件也是奇怪的atrule?可以说,tailwindcss对 postcss 的使用真的上了一个层次,之前我也没想到可以这么玩!通过 js 配置,postcss-js 和 postcss-nested 去解析我们的配置,生成 node,然后最后再用 postcss 去生成 css,甚至还可以使用 puregecss 去裁剪生成的 css ,或者用比较熟悉的话术说,就是可以 tree shaking 我们的 css,听上去很高级的样子。这里不会细致,大概挑几个比较有特色的讲一下。

经典的 tailwind.css

首先看下面三个比较经典的 atrule ,atrule是 postcss 里面 ast 的一个节点,代表 css中的@节点,其中后面跟随的是这个节点的 params ,具体可以去 astexplorer 以及结合 postcss 的api文档去理解

@tailwind base;

@tailwind components;

@tailwind utilities;

在 tailwindcss 里面,这样经典的节点,会起两个作用,拿@tailwind base;这个来说,postcss插件遇到这个 atrule 的时候,识别 params 是 base ,会把 pluginBase 中的节点内容生成 css ,同时会修复 source ,这样 sourcemap 就不会出错了,具体可以看下面,可以看到,现在 atRule 前面插入内容,移除这个 atRule

css.walkAtRules('tailwind', atRule => {
      if (atRule.params === 'preflight') {
        // prettier-ignore
        throw atRule.error("`@tailwind preflight` is not a valid at-rule in Tailwind v1.0, use `@tailwind base` instead.", { word: 'preflight' })
      }

      if (atRule.params === 'base') {
        atRule.before(updateSource(pluginBase, atRule.source))
        atRule.remove()
      }

      if (atRule.params === 'components') {
        atRule.before(postcss.comment({ text: 'tailwind start components' }))
        atRule.before(updateSource(pluginComponents, atRule.source))
        atRule.after(postcss.comment({ text: 'tailwind end components' }))
        atRule.remove()
      }

      if (atRule.params === 'utilities') {
        atRule.before(postcss.comment({ text: 'tailwind start utilities' }))
        atRule.before(updateSource(pluginUtilities, atRule.source))
        atRule.after(postcss.comment({ text: 'tailwind end utilities' }))
        atRule.remove()
      }

      if (atRule.params === 'screens') {
        includesScreensExplicitly = true
        atRule.before(postcss.comment({ text: 'tailwind start screens' }))
        atRule.after(postcss.comment({ text: 'tailwind end screens' }))
      }
    })

    if (!includesScreensExplicitly) {
      css.append([
        postcss.comment({ text: 'tailwind start screens' }),
        postcss.atRule({ name: 'tailwind', params: 'screens' }),
        postcss.comment({ text: 'tailwind end screens' }),
      ])
    }

至于修复 sourcemap 指向,可以看下面这段函数,让新生成的所有节点都指向了原来 atRule 的source,完美~

function updateSource(nodes, source) {
  return _.tap(Array.isArray(nodes) ? postcss.root({ nodes }) : nodes, tree => {
    tree.walk(node => (node.source = source))
  })
}

再讲一个 screen atRule

Instead of writing a raw media query that duplicates that value like this:

@media (min-width: 640px) {
  /* ... */
}

you can use the @screen directive and reference the breakpoint by name:

@screen sm {
  /* ... */
}

上面这个英文,是从文档里面拷贝出来的, 就是常见的媒体查询,我们可以写死到 css,但是如果过段时间又要改呢?这里抽离出来到js配置里面,我们通过读取配置文件,默认是 tailwind.config.js,里面的 theme.screens 对应 atRule 中的 params 的值,生成我们具体的 css,简直不要太方便啊

import _ from 'lodash'
import buildMediaQuery from '../util/buildMediaQuery'

export default function({ theme }) {
  return function(css) {
    css.walkAtRules('screen', atRule => {
      const screen = atRule.params

      if (!_.has(theme.screens, screen)) {
        throw atRule.error(`No \`${screen}\` screen found.`)
      }

      atRule.name = 'media'
      atRule.params = buildMediaQuery(theme.screens[screen])
    })
  }
}

关于 tailwindcss 插件的写法

tailwindcss 插件的写法,具体怎么写,这里不具体展开,这里讲讲原理。插件其实主要的作用就是把我们写的 js css 配置生成一个初步的 css,然后再根据配置文件,进行一个二次处理,最后生成实际的 css,拿一个内置的 zIndex 的插件当例子,主要是这个插件也写了测试用例,结合文档,介绍起来简直不要太方便

首先我们看看这个插件是怎么写的

import _ from 'lodash'
import prefixNegativeModifiers from '../util/prefixNegativeModifiers'

export default function() {
  return function({ addUtilities, e, theme, variants }) {
    const utilities = _.fromPairs(
      _.map(theme('zIndex'), (value, modifier) => {
        return [
          `.${e(prefixNegativeModifiers('z', modifier))}`,
          {
            'z-index': value,
          },
        ]
      })
    )

    addUtilities(utilities, variants('zIndex'))
  }
}

其实我们要关心的就是 addUtilities(utilities, variants('zIndex')) 这块到底干嘛了,简单地说,就是 zIndex 塞到 pluginUtilities 里面,也就是说,最后是对应 @tailwind utilities; ,可以看看测试用例中生成的是什么,如下,就是这个样子,其中 utilities 还好理解,variants 是什么?variants 的使用可以看文档的时候,说白了,就是会有 @variants responsive 把我们utilities中生成的代码包住,这样就初步生成我们的 css,然后 substituteResponsiveAtRules 这个会二次处理这个 atRule,生成最终的 css

expect(addedUtilities).toEqual([
    {
      utilities: {
        '.-z-20': { 'z-index': '-20' },
        '.-z-10': { 'z-index': '-10' },
        '.z-10': { 'z-index': '10' },
        '.z-20': { 'z-index': '20' },
      },
      variants: ['responsive'],
    },
  ])

最后说一句

tailwindcss 还有很多玩法,具体可以去文档挖掘,这里只是简单说下它实现的原理,它给我带来的震撼是,没想到 postcss 或者说 css 还可以这么玩,脑洞太大了, ps: 为了了解这货,基本把主要依赖库的文档瞄了一遍,:逃)