关于 Angular 应用错误日志 1 rules skipped due to selector errors

错误日志 1 rules skipped due to selector errors，可以翻译为“由于选择器错误，跳过了一条规则”。在 Angular 应用中，类似的日志通常与 CSS 选择器相关联。这个错误日志表明 Angular 在服务端渲染过程中，解析某些 CSS 规则时出现了选择器错误，导致这些规则没有被应用。这类日志往往意味着应用中的某些样式未能正确渲染，从而影响页面的最终展示效果。

为了深入理解这个错误，我们需要从以下几个角度进行推理与分析：

1. 什么是 CSS 选择器，以及为什么它们会产生错误？
2. 在 Angular 中，如何处理 CSS 选择器，特别是在 SSR 环境下？
3. 具体有哪些可能导致选择器错误的原因？
4. 如何调试和解决这个问题？
5. 举例说明。

什么是 CSS 选择器以及选择器错误

CSS 选择器的定义

CSS 选择器是用来选取 HTML 文档中元素的模式。常见的 CSS 选择器包括标签选择器、类选择器、ID 选择器、属性选择器等。CSS 选择器的规则定义了浏览器如何应用样式到对应的 HTML 元素上。例如：

div {
  background-color: blue;
}

上述代码中的 div 是一个选择器，它选择所有的 <div> 元素并应用背景色。

选择器错误的概念

当我们说选择器有“错误”时，通常是指选择器的语法不正确或者选择器指向的元素不存在，导致解析时失败。例如，以下的选择器：

div[!invalid-attr="test"] {
  color: red;
}

这里 !invalid-attr 是无效的属性名，这样的选择器会导致解析错误，无法应用样式。

在 Angular SSR 中如何处理 CSS

Angular SSR 是 Angular 的服务端渲染解决方案，它使用 Angular Universal 来在服务器端生成应用的 HTML，随后发送给客户端。这种方式对 SEO 和首屏加载性能有显著帮助。然而，在 SSR 模式下，处理样式和选择器与在浏览器中有所不同。

在客户端渲染中，CSS 是直接由浏览器解析和应用的；而在 SSR 中，Angular 必须在服务器端预处理这些样式。服务器端在解析时无法“看到” DOM，因此会遇到一些选择器无法解析的情况。这种情况下，Angular Universal 可能会在服务端渲染过程中跳过这些错误的 CSS 规则，从而生成 1 rules skipped due to selector errors 的日志。

Angular 的样式隔离机制

Angular 组件使用 View Encapsulation（视图封装）来隔离各个组件的样式，通常有三种封装模式：

1. Emulated（默认）：通过为每个组件的 DOM 元素添加唯一的属性来模拟 Shadow DOM 的效果。
2. None：所有样式都全局生效，不进行任何封装。
3. Shadow DOM：使用浏览器的原生 Shadow DOM 来实现样式封装。

在 SSR 环境下，如果 CSS 选择器使用了一些服务器端无法理解的选择器，或者在特定 View Encapsulation 模式下 Angular 无法正确生成样式规则，就可能会出现选择器错误。例如，使用 Shadow DOM 的组件在 SSR 环境中可能无法被正确解析，因为服务端无法模拟浏览器的 Shadow DOM 环境。

选择器错误的原因分析

下面列出一些可能导致选择器错误的具体原因：

1. 非法或不支持的选择器

某些 CSS 选择器是特定于浏览器环境的，而在服务器端渲染时，Angular 使用 platform-server 来模拟浏览器的部分行为，但它并不完全支持所有 CSS 选择器。例如：

• 伪元素选择器：如 ::before、::after。这些伪元素的实际存在是浏览器渲染的一部分，而在服务端是不存在这些伪元素的。
• 高级选择器：如 :has() 或者使用了复杂的 :not() 规则的选择器。这些选择器可能在服务端渲染时解析失败。

2. 浏览器特定的 CSS 特性

某些 CSS 规则是依赖于浏览器特性的，例如，基于属性的选择器可能依赖于动态的属性值，而这些属性在服务端并不总是可用。这会导致 Angular 在服务端渲染时无法正确应用规则。例如：

input[type="text"]:focus {
  border-color: blue;
}

在服务端，input 元素没有“聚焦”这个状态，导致该选择器无法被解析。

3. 动态生成的内容

某些组件的样式规则依赖于动态生成的内容，例如，通过 JavaScript 动态添加的类名。如果类名是在客户端渲染时才添加的，服务器端的渲染过程则无法识别这些类名，从而导致选择器匹配失败。例如：

// 动态添加类名
element.classList.add('dynamic-class');

.dynamic-class {
  color: green;
}

当样式依赖于 dynamic-class 这样的动态类名，而类名在 SSR 渲染阶段并不存在时，服务器端就会跳过这条样式规则。

如何调试和解决这个问题

1. 检查 CSS 选择器的兼容性

首先，需要确认使用的 CSS 选择器是否被服务器端渲染环境支持。可以通过查阅选择器的兼容性文档，或者在本地的浏览器开发工具中测试选择器。如果发现选择器在某些情况下无效，建议简化选择器的逻辑或者使用更兼容的替代方案。

例如，可以把复杂的属性选择器替换为简单的类名选择器，以确保服务器端可以顺利解析。

2. 使用 Angular 的错误日志调试工具

Angular 提供了多种工具帮助调试 SSR 的问题。例如，在 SSR 中，可以通过捕捉服务器端的错误日志，分析具体是哪些选择器导致了问题。为此，可以修改 server.ts 文件，增加日志级别，捕获更详细的错误信息。

import { enableProdMode } from '@angular/core';
import { ngExpressEngine } from '@nguniversal/express-engine';
import { AppServerModule } from './src/main.server';
import * as express from 'express';

enableProdMode();

const server = express();

server.engine('html', ngExpressEngine({
  bootstrap: AppServerModule,
}));

// 捕获详细的 SSR 渲染日志
server.use((req, res, next) => {
  console.log(`Request URL: ${req.url}`);
  next();
});

通过增强日志，可以获取更多关于选择器错误的信息。

3. 检查组件的封装模式

如果使用了 ViewEncapsulation.ShadowDom，考虑将其改为 ViewEncapsulation.Emulated 或 None，以减少选择器错误的可能性。因为在服务端渲染过程中，Shadow DOM 不易被模拟，而 Emulated 模式相对更兼容。

4. SSR 预渲染与客户端补偿

一种解决方案是在 SSR 渲染的基础上，确保客户端补偿。例如，SSR 生成基础的静态内容，而由客户端的 JavaScript 负责添加动态类名和应用对应的样式。这样，即使选择器在 SSR 中失效，客户端依然可以补偿这些样式，使得最终的 UI 保持一致。

举例说明

示例一：非法选择器

假设你在 Angular 应用中编写了如下 CSS：

div[invalid^="test"] {
  color: red;
}

在这个选择器中，invalid 不是一个合法的 HTML 属性，^= 表示选择属性值以 test 开头的元素。由于这个选择器在 HTML 中找不到匹配项，在 SSR 渲染中它会产生错误并被跳过，从而记录 1 rules skipped due to selector errors。

示例二：浏览器特性依赖

考虑如下的样式规则：

button:focus-visible {
  background-color: yellow;
}

:focus-visible 是一个浏览器特定的伪类，表示当前元素获得焦点且对用户可见。在服务端渲染时，无法模拟用户的交互行为（如键盘导航或者鼠标点击），所以这个伪类的样式规则在 SSR 渲染过程中无法生效并会被跳过。

示例三：动态内容依赖

假设你有一个 Angular 组件，组件内使用 JavaScript 动态为某个元素添加类名：

ngAfterViewInit() {
  const element = this.elementRef.nativeElement.querySelector('.my-div');
  element.classList.add('dynamic-class');
}

并且你在样式中写了如下规则：

.dynamic-class {
  font-weight: bold;
}

在 SSR 渲染时，ngAfterViewInit 钩子不会被执行，因为它是依赖浏览器环境的钩子。结果是，dynamic-class 并不会被添加到元素上，导致与这个类名相关的 CSS 规则无法匹配，进而被跳过并记录日志。

实际解决方案

1. 选择器替代与优化

如果遇到服务端无法识别的复杂选择器，可以尝试简化。例如，使用类名来替代复杂的属性选择器：

/* 原始 */
div[invalid^="test"] {
  color: red;
}

/* 优化 */
.invalid-selector {
  color: red;
}

通过将选择器逻辑放在模板中控制，可以更好地适应 SSR 的需求。

2. 增加 SSR 与客户端的协作

使用 Angular 的 SSR 与客户端的协作模式。比如，将关键样式规则简化并预渲染，而对于更复杂的动态样式，依赖客户端 JavaScript 来补充。

3. SSR 中跳过特定样式

对于某些仅在客户端渲染中生效的样式，可以使用 Angular 的平台检测来区分 SSR 和客户端环境。例如：

import { isPlatformBrowser } from '@angular/common';

constructor(@Inject(PLATFORM_ID) private platformId: Object) {}

ngAfterViewInit() {
  if (isPlatformBrowser(this.platformId)) {
    const element = this.elementRef.nativeElement.querySelector('.my-div');
    element.classList.add('dynamic-class');
  }
}

通过这种方式，可以确保动态样式仅在浏览器中应用，而不会在 SSR 中产生选择器错误。

总结

1 rules skipped due to selector errors 这样的错误日志在 Angular SSR 环境中并不少见，其主要原因是服务器端渲染环境与浏览器渲染环境的差异，特别是在对复杂选择器、动态内容、以及依赖于浏览器特性的选择器的处理上。通过理解选择器错误的可能原因，优化 CSS 规则，适当调整 Angular 组件的封装模式，并确保客户端与服务端的合理协作，可以有效地解决这些问题。