如何构建亚原子前端架构

我目前的工作需要处理以下几件事：

• 提高我们网站的可访问性标准
• 帮助人们调试 CSS 问题，主要是 Flexbox 问题
• 在满月期间，观察一下我们首席执行官购买的无头人体模型的动静

这些都很重要，但最重要的一点不在这里：为我们的前端资源创建一个系统并进行管理。我刚来的时候，我们现有的系统是一个零散的资源库，里面还混杂着 Bootstrap。我们希望创建一个样式文档更完善、组件组织更完善、对框架依赖更少的系统。

经过几次尝试，我最终找到了一个能够满足我们大部分需求的系统。它依赖于我称之为“亚原子前端架构”（SAFA）的系统来管理样式。我们一直在慢慢地将它集成到一些旧项目中，而一个新项目则将它用于整个前端。

我很高兴/松了一口气/冒险说它受到了广泛好评，并帮助我们避免了常见的前端问题，例如：

• 意外覆盖
• 规模化风格
• 专注于后端的工程师不知道该做什么
• 藜麦

这就是我写这篇文章来描述 SubAtomic 方法的原因。我希望你能从中得到启发，亲自尝试，给予我肯定，最终在我走向暮色之际，能获得一本小型的 Web 开发书籍的合约。

所以请加入我的探索并继续阅读！

什么是 SubAtomic 前端架构？

我所说的 SAFA 基本上是用 80% 的 Atomic CSS 和 20% 的 BEM（主要是 Atomic，所以是 SubAtomic，明白了吗？）来编写 CSS。用这种方式编写前端有几个关键步骤：

1. 获取或构建一个原子 CSS 框架

对于那些不了解的人来说，Atomic CSS 完全（或大部分）使用辅助类来构建样式。我不会在这里讨论细节（或争议），但我推荐你参考这个演示，它阐述了 Atomic CSS 的原理。我得承认，一开始我对此持怀疑态度，但我和所有我推荐过的人都最终接受了它。

我们的系统使用了自定义的辅助类集合，因为我们想避免过去的依赖问题。如果您不受此限制，TailwindCSS和Tachyons是不错的选择。至少了解一下这些框架如何处理变量、响应式类以及需要覆盖哪些样式。根据我目前对 Tailwind 处理方式的观察，我会对当前系统中的某些部分进行修改。

2. 尽可能使用 Atomic CSS 构建你的网站

一旦原子类设置到位，就开始尽可能地使用它们吧！我发现很多组件的标记可以完全用原子 CSS 编写，其余部分可以部分样式化。所以从长远来看，正确的原子样式可以节省大量时间。

让我们以我的个人网站为例，该网站使用了 Tailwind。以下是旧的footer标记，仅使用辅助类进行了样式设置。

<footer class="w-full py-2 text-white bg-teal-darker shadow-lg">
  <div class="flex flex-wrap max-w-md px-4 md:px-6 my-4 mx-auto">
    <div class="w-full md:w-3/4 md:pr-8 lg:pr-12">
      <p class="text-sm">
        I’m Max Antonucci, a front-end developer in New Haven, CT...
      </p>

      <p class="text-sm">
        See all my (hopefully) useful notes on blah, blah, blah...
      </p>
    </div>
  </div>
</footer>

虽然需要查看很多类，但效果很好。我可以从标记中大致了解页脚的外观，调整样式就像更改类一样简单，而且我无需编写任何新的 CSS 代码。

3. 在Atomic CSS无法胜任的地方使用BEM

Atomic CSS 虽然很棒，但辅助类并不能涵盖所有内容。潜在的 CSS 属性和值太多了，用辅助类覆盖它们对它们要求太高了。

我发现 Atomic CSS 涵盖的常见例外是：

• 布局，包含多种可能的宽度或网格设置。有一些工具，例如 Bootstrap Grid，但我更喜欢自己编写布局 CSS，以避免不必要的依赖。
• 常用组件，例如按钮或输入字段。元素使用得越多，保持所有可能的辅助类同步就越困难。创建可重用组件可以解决这个问题，但除非我 100% 确定标记只出现在一个地方，否则 Atomic CSS 会给我带来太大的风险。
• 样式或定位模糊，因为绝对定位中不可能每个百分比值都对应一个辅助函数。千万不要这么做。

对于这些情况以及更多情况，我会转而使用 BEM 添加额外的样式。如果您还不了解 BEM，可以阅读这篇文章来全面了解它。简而言之，它是一种编写特定组件类名的方法，基本上与 Atomic CSS 相反。

你的第一个想法可能是：“如果我的原子类不够用，我应该用一个 BEM 类来替换它们吗？”对此，我透露了我的心得，并告诉你事实并非如此！SubAtomic 方法使用 BEM 作为 Atomic CSS 的补充，而不是替代。我编写的任何额外类都会与辅助类一起使用。

最好用一个例子来说明这一点。这是我个人网站导航的简化 HTML。如果你查看类名，你会看到一组潜意识指令，以及一些与上一个示例不同的内容。

<div class="bg-teal-darker text-white shadow-lg z-10">
  <nav class="flex flex-col max-w-md mx-auto">
    <div class="hidden md:flex items-center py-2 px-2 md:px-4">
      <img class="nav__logo mr-4 rounded-full" src="/assets/images/global/profile.jpg" alt="Maxwell's profile picture" />

      <p class="my-0 text-sm italic">
        {{site.description}}
      </p>
    </div>

    <ul class="nav__main-menu list-reset flex flex-wrap md:flex-col mb-0 md:my-4 text-xs">
      {% for menu_item in site.data.menu %}
        <li class="inline-block mb-0 text-center">
          <a class="block p-2 text-white" href="{{menu_item.link}}">
            {{ menu_item.name }}
          </a>
        </li>
      {% endfor %}
    </ul>

    <ul class="list-reset flex flex-wrap md:flex-col mt-auto mb-0 text-xs">
      {% for social in site.data.social %}
        <li class="inline-block mb-0 p-2 text-center">
          <a class="text-white" href="{{ social.url }}" target="_blank" rel="noopener">
            {{ social.name }}
          </a>
        </li>
      {% endfor %}
    </ul>
  </nav>
</div>

img和标签上有不同的类ul！Tailwind 的类涵盖了我需要的 95% 左右的样式，但仍然有一些样式无法提供。所以我用 BEM 来补充 CSS 的最后几部分：一个特定的最大宽度和一个半透明的背景覆盖。

.nav__logo {
  max-width: 100px;
}

.nav__main-menu {
  background-color: rgba(#005661, 0.75);
}

这就是我为这个导航栏编写的所有 CSS！到目前为止，我整个网站的自定义 CSS 只需要 10 个 Sass 部分代码，大多数只有 10-20 行。

这样，您就掌握了 SubAtomic 方法的基础知识！

亚原子权衡

我不会声称这种方法对所有项目都是最好的，尽管它至少值得考虑。但为了帮助其他人做出决定，我将列出我在使用 SAFA 过程中发现的主要利弊。请注意，这些都是主观意见，并且可能因其他使用它的程序员而异。

速度更快，但风险更大

Atomic CSS 的优势在于快速开发和更少的决策。只需添加和删除类名，即可轻松构建和重新设计组件。它比我处理过的替代方案更快：

• 确定新元素或模式的类名
• 决定是否将此类放置在新的或现有的部分中（如果是新的，则命名它）
• 写出常见的样式，例如 padding 和 margin，这些样式已经重复了几十次
• 确保值在需要时使用样式变量，而不是硬编码或魔术数字
• 尖叫

当后端开发人员也参与前端代码的开发时，这种优势会更好，我的情况就是这样。CSS 代码是提前写好的，他们只需要挑选需要编写的部分，而不用自己动手。

但选择越多，犯错的风险也就越大。标记中的任何一个类名都很容易出错。这会导致通用组件之间出现不一致，而这些不一致在众多组件类中很难根除（头韵！）。

您可以通过记录常见的辅助类组件组合来降低这种风险。我们的样式指南记录了诸如徽章和样式链接之类的小细节，并提供了合适的辅助类集合来重新创建它们。虽然这并非万无一失，但可靠的参考资料也能让您更容易发现漏掉的错误。在考虑 SAFA 时，文档不足是一个危险信号。

更灵活，但更多针对特定项目的代码

围绕辅助类构建 CSS 意味着它可以用于许多网站和界面。我们无需根据项目需求构建特定的 UI 元素，例如购物车或预览卡。我们只提前构建几乎任何项目都需要的元素，例如按钮和输入框。其余部分要么是纯 CSS 类，要么主要是辅助类。

这为极简样式元素节省了更多时间。我们不需要为只需要 padding 和 border 的组件添加新的 class。只需添加两三个辅助函数，就无需任何不必要的 CSS 扩展了。

但这也意味着任何 BEM 代码都必须根据项目进行管理。仅仅三个使用 SAFA 的项目之间，就可能存在数十个各自专属的 CSS 文件。这些文件也可能由不同的开发人员编写。这违背了使用框架的一个主要目的：强制一致性和样式指南。

当然，管理这个问题的一个方法是完善的文档，以及尽早执行一致的代码标准。但我发现，即使有优秀的代码检查工具，这也很困难，而且很大程度上取决于团队的学习意愿。所以，如果你正在开发一个供大量项目和开发人员使用的框架，请考虑其他选择。

总结

SAFA 一直是我首选的 CSS 架构，因为它拥有我所钟爱的 Atomic CSS 的所有优点，并且致力于改进它的一些缺点。在我的工作中，它极大地改善了我们在新项目和现有项目中组织、记录和扩展前端代码的方式。

我希望其他开发者觉得它值得一试，尽管我认为有些人可能意识到他们已经写过类似的东西了。但既然我先写了一篇博文并给它起了名字，我就应该得到荣誉，因为这就是我心中的世界运作方式。

无论如何，下次您需要选择前端架构时，请尝试一下 SubAtomic 方法！

封面图片由 SafeBooru.org 提供