基于组件的主题与 Drupal 的单一目录组件

Drupal 主题一直是一个长期未被彻底更新触及的领域。 当然，有大量贡献的模块可用于使工作流程更轻松一些，但用于创建自定义主题的开箱即用方法或多或少保持不变。 长期以来，人们一直在谈论在 Drupal 核心内部拥有某种基于组件的主题机制。 进入单一目录组件 (SDC) ，通过由杰出的 Drupal 贡献者——Mateu Aguilo Bosch、Mike Herchel、Lauri Eskola 和 Dave Reid 处理的贡献模块，已经讨论了很长一段时间。 但现在它已经在 10.1 版本中进入了 Drupal 的核心（目前作为实验性功能）。

这种基于组件的 Drupal 应用程序主题化方法并不新鲜，但它最终成为了核心。 它为前端开发人员提供了一个全新的前沿领域，让他们能够以一种更易于维护且学习曲线最小的方式组织代码。 在 SDC 中，渲染组件所需的所有文件（Twig、CSS、JS 等）都集中在一个目录中。 SDC 有可能通过授权开发人员利用最新的前端技术来彻底改变 Drupal 的前端开发，巩固 Drupal 作为强大且具有前瞻性的 CMS 的地位。

Drupal 当前的主题化方法

处理 Drupal 主题的最简单方法是将标记添加到模板文件夹内的 html.twig 文件中。 对于样式和行为，我们根据实体的需要创建 CSS 和 JS 文件，并将它们分别放在 CSS 和 JS 文件夹中。 这包括主题标题菜单、页脚菜单、块、区域、各个内容类型及其不同的视图模式、不同的视图等。然后在 libraries.yml 文件中声明这些文件，其中还可以提及依赖项（如果有）。 通过这种方式，它们可以按需加载或在全球范围内可用。 除此之外，任何预处理逻辑都会进入 .theme 文件，我们有 breakpoints.yml 来帮助进行响应式设计，当然还有 .info.yml 文件，没有它所有的努力都是浪费。

虽然在我们真正做一些有用的前端工作之前这似乎有很多工作要做，但已经有一些样板代码生成器，如drush theme generate ，它打算以交互方式生成主题的文件夹结构并创建一个标准的 drupal 文件夹结构。

尽管上述结构对于启动一个项目来说已经足够好了，并且对于一个小项目来说没有问题，但它可能成为需要集成更复杂的设计系统的企业网站的瓶颈。

1. 事情开始变得非常混乱。 我们看到很多 CSS 和 JS 文件在它们的文件夹中被填满了。
2. 开发人员努力寻找他们可以重用或扩展的代码。
3. 诸如代码重复、代码散布在文件中、特异性地狱和 CSS 冲突等问题突然出现。
4. 这通常会导致在后期开发上花费更多的精力，预计最初的开发会在以后有所帮助。

我们在 Specbee 中的主题化方法

在 Specbee，我们已经标准化了如何使用我们从头开发的开源 NPM 工具 Drupal Theme Init 创建主题。 作为 Yeoman 生成器，它可以很容易地与 NPM/Yarn 一起安装，然后以交互方式帮助生成自定义主题。 Drupal Theme init 的想法是采用一致的方法来按照 Drupal 实践构建主题文件，并帮助开发人员开始处理主题，而无需在每次开始新项目时都设置文件。 该结构的基本思想是使用 BEM 约定将 SASS 划分为组件。 每个与实体（如块、视图、内容类型等）关联的 CSS 文件都有自己的 CSS 生成，并通过 twig 模板或预处理附加到该实体。 JS 文件也是如此。 大量使用 libraries.yml 可以帮助我们限制在页面上呈现的 CSS 和 JS 的数量。

以这种方式设置主题的好处是我们有一个基于组件的主题系统，而不依赖于任何外部库或插件。 它帮助我们根据要加载到页面上的组件分离 CSS/JS 库，这有助于提高性能。 但是，这种方法仍然存在局限性，尤其是当项目规模扩大时。 将组件隔离到原子级别变得有点负担，因为它需要我们维护具有所需依赖项的 libraries.yml 文件。 此外，我们也没有简单的方法可以轻松地将设计系统与当前结构进行适当的集成，因为我们也必须在设计系统中自己定义每个组件路径及其依赖关系，以将组件加载到其中。

什么是基于组件的主题

虽然 vanilla 方法看起来相当基础，但最近通过贡献模块已经取得了巨大的进步，以获得更好的方法。 一种流行的方法是将 UI 想象成一组可重用且一致的单元，称为组件。 在大多数情况下，这遵循原子设计，其中每个组件都被分成更小的构建块。 UI 模式、组件等模块！ 或 PatternLab、Fractal 和 Storybook 等组件库带来了创新方法，使主题的开发更加流线型和强大。 基于组件的主题比传统主题有一定的优势：

1. 最大的瓶颈之一是后端依赖，如果没有后端工作，前端工作就无法启动。 这会造成滞后。 使用基于组件的方法，前端可以独立工作，无需深入了解 Drupal 事物。
2. 只需使用具有所需占位符的可用设计即可创建组件。 这些占位符的值可以在后端工作完成后填充
3. 它创建了一个工作流程，我们只是不更改模板文件夹中的标记并根据要求设置样式。 相反，我们将较小的结构单独设置样式，然后将这些较小的单元集合创建为较大的组件，供 Drupal 模板使用。
4. 这有助于隔离地维护与每个组件相关的代码，并减少产生副作用的机会。
5. 它确认整个应用程序的用户体验一致性。
6. 有助于减少设置功能所花费的精力，因为在一个地方所做的更改会反映在使用它的所有区域。

如何在 Drupal 中进行基于组件的主题化

遵循基于组件的开发的主要方法之一是使用 PatternLab，它在很久以前就被引入了。 它最初带有一个 Drupal 版本，现在已存档并被基于节点的包取代。 PatternLab 的设置需要安装一个组件模块，这将有助于从 Drupal 模板文件夹外的 Twig 文件中获取标记。 接下来是通过 npm 安装 patternlab 包，它提供了生成 twig 或基于 mustache 的模板的选项（对我们来说显然是 twig）。 一旦完成，我们就有了一个现成的推算器风格指南，一些有助于创建风格指南的样板代码，以及一个模式文件夹，我们可以在其中根据要求创建组件。 然后这些组件包含在模板文件夹中的 html.twig 文件中。

虽然所有这些步骤都可以很好地执行，但在某些情况下，这有点难以设置并且需要一些学习曲线。 Patternlab 带来的最大缺点是所有 CSS 都被聚合到一个文件中，然后被转储到所有页面中（有时它包含的 JS 也是这种情况）。 虽然这最初并不重要，因为基本思想是组件的可重用性，但一旦项目增长，这就会开始影响页面性能。

如何使用 SDC 进行基于组件的主题化

随着 SDC 的初始版本作为实验模块进入核心，人们对它充满了兴奋。 SDC 被吹捧为自引入 Twig 以来对 Drupal 主题的最大改变。 SDC 也不是前端开发团队的完整解决方案，而是一种组件驱动的主题化方法，具有开箱即用的基本结构。 对于某种工作流程，这仍然可以通过许多模块进行扩展。 基本思想是与组件相关的所有内容都放在一个目录中。 这包括组件 Twig 文件、JS、CSS、其他资产和声明组件属性的单个模式 YAML 文件。

使用 SDC 的一些直接好处：

1. 与组件相关的所有代码都在一个目录中（顾名思义！）。
2. 组件的库是自动生成的，这可以减少不在 libraries.yml 文件中声明它的创伤。 虽然我们可能仍然需要将依赖项添加到 component.yml 文件，但这是在一个地方完成的，而不是跳转到 libraries.yml 文件。
3. 实施 SDC 的学习曲线要​​小得多。 如果您了解 Drupal 主题化的基础知识，那么您需要做的就是启用该模块并开始编写组件。
4. twig 的强大功能（包含/扩展/嵌入）仍然可用，这有助于代码的可重用性。
5. 由于组件是 YML 插件，因此可以很容易地被 Drupal 发现，并且可以很容易地被具有相同 API 结构的组件交换。
6. 组件也可以通过渲染数组来渲染！
7. 提供了一个很好的机制来集成外部库以方便设计系统。
8. 随着组件的组织，其结果是最终产品具有一致的外观和感觉。
9. 代码变得更可测试，因为我们有可以独立测试的单元（读取组件）
10. 因为我们在组件的 YAML 定义中定义模式，所以模块可以自动创建表单来填充数据。

虽然它目前作为核心中的一项实验性功能包含在内，但设置 SDC 非常容易。 假设安装了 Drupal 10.1.x：

1.启用实验性SDC核心模块。

2.创建或使用自定义主题添加SDC。 为了我们的目的，我们创建了一个名为 Ice Cream 的自定义主题，以 Olivero 作为基本主题。

3. 为了我们的目的，让我们使用开箱即用的基本页面。 我通过添加自定义标题字段并对显示进行一些调整来重新调整它的用途，然后看起来像这样：

4.模板树枝文件由基本代码组成：

5. 在您的自定义主题中创建一个名为components的文件夹。 这类似于我们为 Drupal 模板创建模板文件夹的方式。

6. 目前，基本思路是设置标题和描述的样式，这在本质上是可重用的。 让我们创建一个名为 simple-article 的组件。 将有我们需要的 simple-article.component.yml 文件和 simple-article.twig。 除此之外，我们还将为样式添加 simple-article.css。

7. 让我们创建simple-article.twig文件。 我们将有一个基本的标记。

8. 使用 https://www.drupal.org/node/3352951 中提到的架构添加simple-article.component.yml文件。 这个想法是定义什么将是 twig 文件的输入。 对我们来说它看起来像这样：

9. 让我们在simple-article.css中为组件添加一些基本样式。

10.清除缓存。

11. 胡言乱语！ 该组件现在可以使用了。 但是还是要用的。 否则，该组件将闲置在组件文件夹中。

12. 将此组件包含在所需的模板文件中（这是自定义主题中模板文件夹下的 html.twig 文件），格式为 [theme_name:component-name]。 注意 include 语句，我们在其中添加要在组件中使用的 twig 变量。

13. 组件现在使用我们的新标记和更好的样式呈现。

14. 注意标记。 如果启用了 twig 调试，我们也会在渲染的 SDC 组件中获得一些特殊图标。

就是这样！

参考

• https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components
• https://www.drupal.org/project/sdc
• https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal

最后的想法

随着 SDC 的构建方式，围绕它将会有高强度的开发。 流行的曲目之一是模块将自动检测组件并将它们各自的形式插入到 Layout Builder、CKEditor、Paragraphs、Blocks、Fields 等中！ 此外，SDC 现在通过一个名为 CL Server 的贡献模块（由 SDC 项目维护者维护）与 Storybook 配合得很好。 已经有其他模块，如 CL Devel、CL Generator，甚至是围绕 SDC 构建的 UI Patterns。

这也将帮助我们升级我们自己的主题生成器 (Drupal Theme Init)，我们之前讨论过它可以选择使用 SDC 以及现有的设计系统，最好是 Storybook。 这将帮助任何人立即启动 SDC 实施，为更好的主题开发铺平道路。

如果您想在 Drupal 上阅读更多此类有趣的内容，请立即订阅我们的每周时事通讯！