LUPA开源社区 › 首页 ›业界资讯› 开源资讯 › 查看内容

Facebook：CSS的质量提升与展望

2016-9-5 14:07| 发布者: joejoe0332| 查看: 728| 评论: 0|原作者: merzoo|来自: 众成翻译

摘要: 与成千上万的facebook工程师在这纷繁复杂的产品线中相互协作, 代码质量通常面临独特的挑战。我们不仅需要处理庞大的数据库, 还需要跟上时代发展的节奏 —— 新增功能的上线、已有功能的改善, 甚至是产品重组的需要 ...

与成千上万的facebook工程师在这纷繁复杂的产品线中相互协作, 代码质量通常面临独特的挑战。

我们不仅需要处理庞大的数据库, 还需要跟上时代发展的节奏 —— 新增功能的上线、已有功能的改善, 甚至是产品重组的需要。

对于CSS来说,这意味着成千上万的文件在一个不断变化的状态中。

即使我们已经尽力通过代码回顾、风格指导，甚至是重构等方式去确保css代码的质量，然而无意的小错误依然可以让我们措手不及。

直到最近，我们使用的还是一款我们自主开发的CSS检测器（CSS linter）去获取一些基本的错误以保障代码风格的一致。尽管它已经达到了我们的目的，但我们需要的是更强大的解决方案。

正则是远远不够的

旧的css检测器基本上是一些正则表达式搜索和替换规则。正确解析CSS不是一个简单的问题，和供应商扩展和定制规格的变化，会计是更具挑战性。

下面是一个旧代码的例子：

preg_match_all(
    // 这条规则匹配的是没有前置选择器的属性选择器
    '/\/\*.*?\*\/|\{[^}]*\}|\s(\[[^\]]+\])/s',
    $data,
    $matches,,k
    PREG_SET_ORDER | PREG_OFFSET_CAPTURE);
    foreach  ($matches as $match)  {
        if (isset($match[1])) {
            raiseError(...);
        }

维护这种神秘的匹配规则维护是极其无趣的。且不说它很难改变和理解，性能也是一个问题。对于每个规则来说，我们不得不一遍又一遍的去遍历整个输入，匹配不同的正则表达式。

##抽象语法树

我们决定新的解决方案是基于一个真实的,遵循规范的CSS解析器。由于代码必须对这种类型的语法有效解析器工作,我们不能再把我们整个CSS代码库作为一个巨大的文本。这种新方法将显著改善CSS代码质量打字错误,否则他们就会被忽视,导致默默地进行不正确的视图呈现或行为。

什么样的行为呢?

一些潜伏在我们巨大代码库阴影中的代码可能向下面一样：

1

2

3

4

5

{
    display: none;
    background-color: #8B1D3;
    padding: 10px,10px,0,0;
    opacity: 1.0f;}

你能发现细微的差别吗? 属性名输入错误,不正确的十六进制,错误的分隔符——浏览器会忽略这些,这是与我们开发人员的意图相去甚远。

它意识到没多久 PostCSS 将是一个伟大的工作,一个合适的工具,基于标准的CSS解析器与一个优秀的模块化的体系结构。然后,我们选择 Stylelint 作为我们的CSS检测器。它基于PostCSS,非常灵活,并且有很好的支持。
类似于基于javascript解析器/过滤器的Esprima 和 ESLint，PostCSS Stylelint给你访问整个AST(抽象语法树)的权限。 AST节点可以方便地使用任何条件去访问任何节点:我们使用正确的类名了吗? 我们包括正确的抽象了吗? 有弃用或不受支持的扩展吗? 有本地化问题吗?

在下面这个例子中，我们将遍历所有的声明，并找到所有的首字母大写（"text-transform: uppercase"）的片段。

1

2

3

4

root.walkDecls(node =>  {
    if (node.prop === 'text-transform' && node.value === 'uppercase') {
        report({  ...  });
    }});

我们甚至可以解析和解构低级的函数例如linear-gradient。这里有一个更复杂的例子：找到linear-gradient函数,并检查它的第一个参数。

// disallow things like linear-gradient(top, blue, green) w. incorrect first valueroot.walkDecls(node => {
    const parsedValue = styleParser(node.value);
    parsedValue.walk(valueNode => {
        if (valueNode.type === 'function' && valueNode.value === 'linear-gradient') {
            const firstValueInGradient = styleParser.stringify(valueNode.nodes[0]);  
            if (disallowedFirstValuesInGradient.indexOf(firstValueInGradient) > -1) {
                report({  ...  });
            }
        }
    });});

所有无论这些CSS代码如何格式化,如何规则、声明和如何绑定，都非常容易理解和更新。

我们可以非常欣喜的看到，通过使用PostCSS and Stylelint，当我们处理起例如纠正错别字、关键帧数、！important、复杂选择器、非标准属性等任何常见及潜在问题时都变得得心应手起来~

##自定义规则

我们可以通过一个非常便利的内部插件机制（built-in plugin mechanism）来自定义我们的规则。我们现有的插件如下：

slow-css-properties to warn against performance-sensitive properties like opacity or box-shadow (just to be mindful of them)
filters-with-svg-files to warn against filters not being supported in Edge when referencing SVG files
use-variables to warn against values that could be replaced with existing constants (we use customvar(...) abstraction)
common-properties-whitelist to catch potentially nonexistent properties (i.e., typos)
mobile-flexbox to catch multi-value flex that's not supported in older mobile browsers
text-transform-uppercase to warn against "text-transform: uppercase" (which is not internationalization-friendly)

我们为这些Stylelint插件制定了很多和规则和附属条例，试图将它们释放给某个独立的仓库或者是某个线程的Stylelint团队。

##自动替换

我们的静态分析过程的一个非常重要方面是自动格式化。 linter支持修补,如果不一致时,它会询问你是否需要根据规则进行替换。这可能是一个强大和节省时间的概念。提交时你想要做的最后一件事是看到检测错误,然后回去修复它们,尤其当此项工作是非常平常的工作,比如字母重新排序规则。通常更好的做法是让一个自动格式化的工具去完成其工作,以节省开发时间。

不幸的是,Stylelint没有内置的自动格式化(可以说,linter不应该关心这样一个任务),所以我们必须重新添加及实现的一些现有Stylelint规则去提升我们对基础设施的支持。同时,我们正在开发一种潜在的，在未来可以为所有用户服务的通用Stylelint。

测试所有的事情

我们的老版的CSS检测器问题之一是,我们没有单元测试。这是一个至关重要的事情,因为我们需要对任意的文本进行解析。在使用Stylelint重写我们的检测器,我们添加了测试每一个规则,确保规则可以获取正确的东西,忽略了无关紧要的东西,并建议合适的替代品。

我们使用一个可信的且易于理解的Jest框架 ,测试起来是这样的:

1

2

3

4

test.ok('div { background-image: linear-gradient( 0deg, blue, green 40%, red ); }',
    'linear gradient with valid syntax');test.notOk('a { background: linear-gradient(top, blue, green); }',
    message,
    'linear-gradient with invalid syntax');

接下来是什么

这个高质量的CSS重写只是第一步。有很多有用的规则我们计划添加(内置和自定义的)——所有这些旨在抓住常见错误,执行最佳实践和控制代码风格惯例。我们已经使用JavaScript(通过ESLint)所以我们没有理由不应该用它去处理CSS。

目前检测器已经与Phabricator集成，成为了我们的代码协作工具，所有的的警告/建议都在修订当中。

这使得CSS检测器在工作流中迈进了非常大的一步。

有一个合适的CSS解析器的另一大好处是,它可以收集有关代码库的准确的统计数据。最近使用的属性/值是什么? 也许他们应该删除或替换(通过电线发送更少的字节)。最流行的颜色/字体大小/ 层级是什么? 也许他们应该被抽象成可重用的组件或变量。 “最重”选择器是什么? 这里也许有一个性能问题等。

所有的这些可以帮助它提高性能和维护。

关于react和内联样式?

值得一提的是CSS-in-JS概念在react社区逐渐流行起来。现在的情况是,一个CSS检测器的情况在很大程度上还是作为一个无关紧要的css文件检测器。它目前旨在解析传统CSS文件，以后可能渐渐的去适应解析在JS中定义为CSS代码段。不过，通过PostCSS的JS API,处理起这些来应该是相当简单的。

虽然我们正在Facebook中积极探索CSS-in-JS的方法,它还处在早期的实验阶段,我们仍然有很大的CSS代码库维护。