posts/angular-features-19-to-21/ #25

2026-04-17T02:53:11Z

giscus[bot]
Bot Apr 17, 2026

posts/angular-features-19-to-21/

Angular 19-21 标志着框架的成熟期——Signals 全面稳定、Zoneless 正式落地、resource/httpResource 响应式数据获取、增量水合等特性让 Angular 焕然一新。

https://rowanliu.com/posts/angular-features-19-to-21/

llccing · 2026-04-17T02:53:13Z

llccing
Apr 17, 2026 — with giscus
Maintainer

理解 linkedSignal 的关键在于：它是一个**“有记忆、但服从上级命令”**的可写信号。

针对你的三个疑问，我们逐一拆解：

1. `linkedSignal` 变更了，会更新 `source` 吗？

答案是：不会。

linkedSignal 和 source 之间是单向绑定的关系。

向上无关：当你调用 sortBy.set('rating') 时，它只会改变自己的值，完全不会去修改 this.category 的值。
向下重置：只有当 source（即 category）发生变化时，linkedSignal 才会像被“格式化”了一样，强制执行 computation 逻辑并覆盖掉你之前手动设置的值。

比喻：source 是“省份”，linkedSignal 是“城市”。
你手动把城市从“西安”改成了“延安”（在同一个省内改），省份不会变。
但如果你把省份从“陕西”改成了“广东”，城市会强制重置为广东的默认值“广州”。

2. `sortBy` 的例子里是不是少了 `price` 字段？

其实并没有少。这正是 linkedSignal 最常见的用法：设定默认重置值。

在你的代码中：

sortBy = linkedSignal({
  source: this.category,
  computation: () => 'price' // 这里的 'price' 是字符串常量
});

这里的逻辑是：

初始状态：sortBy 的值是 'price'。
用户操作：用户在下拉框选了“评分”，此时调用 sortBy.set('rating')，界面显示“评分”。
触发重置：一旦用户切换了“商品分类”（比如从电子产品换到图书），linkedSignal 监测到 source 变了，它会立刻执行 computation。
结果：因为 computation 返回的是 'price'，所以 sortBy 又回到了 'price'。

为什么看起来“少了”？ 因为这个例子中，无论分类怎么换，它都固定重置为 'price'。但在实际业务中，你可能会根据分类不同返回不同的默认排序：

sortBy = linkedSignal({
  source: this.category,
  computation: (cat) => cat === 'books' ? 'name' : 'price' 
  // 如果切到图书，默认按名称排；其他切过来默认按价格排
});

3. `computation` 到底是干嘛用的？

computation 的核心作用是：定义“当依赖源变化时，我该如何计算我的新初值”。

它有两个特性：

自动触发：只要 source 里的信号值发生了改变（引用变化或值变化），computation 就会运行。
获取最新源数据：computation 函数接收一个参数，即 source 的当前值。

`computed` vs `linkedSignal` 的本质区别：

特性	`computed`	`linkedSignal`
可写性	只读 (没有 `.set()` 方法)	可写 (有 `.set()` 和 `.update()`)
值来源	永远 100% 依赖于内部引用的信号	初始/重置时依赖 `computation`，平时可以手动修改
适用场景	派生状态（如：总价 = 单价 * 数量）	带默认值的状态（如：重置表单、分页重置）

总结

在你的代码例子中：

page 的 computation: () => 1：意思是不管你分类怎么换、排序怎么调，只要它们一动，页码就强制回到第 1 页。这非常符合搜索筛选的逻辑。
如果你手动点了“下一页”（page.update(p => p + 1)），这属于手动修改，不会影响 category 或 sortBy。

一句话总结： linkedSignal 就是一个**“一旦监听到源头变化，就会根据 computation 逻辑自我重置”**的增强型可写信号。

你现在明白为什么在切换分类时，要把页码重置为 1 了吗？

0 replies

llccing · 2026-04-17T03:30:35Z

llccing
Apr 17, 2026 — with giscus
Maintainer

这是一个非常棒的切入点！在 Angular 全面拥抱 Signal 的时代，引入了 resource 和 httpResource。理解它们的底层机制和设计初衷，对于架构选型至关重要。

我们直接切入核心：传统上，Angular 的 HttpClient 底层确实默认使用的是 XMLHttpRequest (XHR)。但现在的 Angular 提供了一种更现代的选项。

为了帮你彻底梳理这部分知识，我们将从“底层技术”到“主流方案”，再到“Angular 官方的设计考量”层层递进。

一、 `HttpClient` 的底层到底是什么？

虽然 HttpClient 过去多年一直死死绑定着 XMLHttpRequest，但在较新的 Angular 版本（v15+）中，官方引入了基于 fetch 的支持。

默认情况 (XHR)： 如果你不做额外配置，HttpClient 底层依然是使用老牌的 XMLHttpRequest。
现代配置 (Fetch)： 如果你在 app.config.ts 中使用了 provideHttpClient(withFetch())，那么 HttpClient（以及依赖它的 httpResource）在底层就会切换为使用现代的 Fetch API。

二、 Fetch vs. XMLHttpRequest (XHR)：有什么区别？

为什么前端世界要从 XHR 转向 Fetch？我们可以通过下表一目了然：

特性	Fetch API	XMLHttpRequest (XHR)
设计时代	现代 Web 标准 (ES6+)	老旧的 Web 标准 (诞生于近 20 年前)
异步模型	基于 Promise，天然契合 `async/await`	基于事件回调 (`onreadystatechange` 等)
API 友好度	简洁、清晰、链式调用	冗长、复杂、容易产生回调地狱
流处理 (Streaming)	原生支持 `ReadableStream`	不支持真正的流，只能阶段性读取响应体
取消请求	通过 `AbortController` 实现	原生 `abort()` 方法
上传进度	相对较弱（目前难以直接追踪单次上传进度）	原生支持完整的上传/下载进度事件

三、主流方案是哪种？(Fetch 还是 XHR)

在整个前端行业（React, Vue, Node.js 等）：Fetch 是绝对的主流和标准。 XHR 正在被慢慢淘汰（除了极少数需要精确兼容古董浏览器，或需要极细粒度上传进度条的场景）。

在 Angular 生态中：
主流方案依然是 HttpClient。但趋势是配置 withFetch() 让其底层使用 Fetch。因为 HttpClient 不仅仅是一个发请求的工具，它为企业级开发提供了一套完整的生态（我们接着往下看）。

四、为什么 Angular 要同时提供 `resource` 和 `httpResource`？

这是你疑问的核心：既然都能发请求，为什么要设计两个 API？主要原因是灵活性与企业级生态继承的权衡。

1. `resource`：万能的异步数据加载器

定位： 它是 Angular Signals 时代最基础的异步原语。
特点： 它完全不在乎你的数据是怎么来的。你可以用 fetch 发请求，可以使用 GraphQL 客户端，可以调用 FirebaseSDK，甚至可以从浏览器的 IndexedDB 或 Web Bluetooth 读取数据。只要是个 Promise，它就能处理。
缺点： 它是“裸”的。如果你用它写 fetch，你就享受不到 Angular 生态里现成的功能。

2. `httpResource`：专为 Angular HTTP 生态打造的特种兵

定位： 它是 resource 的一个特定版本，内部强制绑定并调用了 Angular 的 HttpClient。
设计的根本原因 (The Main Decision Reason)： Angular 开发者在过去几年里写了海量的 拦截器 (HttpInterceptors)。比如：
- 在 Header 里自动塞入 JWT Token。
- 全局捕获 401 错误并跳转登录页。
- 统一的全局 Loading 动画。
  如果官方只提供 resource + fetch，那么所有现存的拦截器、测试工具（HttpTestingController）将瞬间失效，这会导致极其痛苦的破坏性更新。
优点： 完美继承了 HttpClient 的所有特性（拦截器、类型安全、测试模块），只是将结果包装成了响应式的 Signal。

五、总结与建议

如果你只是需要从一个开放的 API 随便拉点数据，或者你在调用第三方 SDK（返回 Promise），用 resource。
如果你在开发一个标准的 Angular 企业级应用，有统一的鉴权、错误拦截逻辑，并且已经配置了 HttpClient，毫无疑问应该首选 httpResource。

0 replies

llccing · 2026-04-17T06:43:30Z

llccing
Apr 17, 2026 — with giscus
Maintainer

这是一个非常好的问题，也是很多开发者在初接触 Angular Signals 时容易产生误解的地方。

直接回答你的问题：不会。如果你不主动调用 onCleanup，setInterval 会发生内存泄漏，Observable 的 subscribe 也不会被自动取消订阅（unsubscribe）。

为了彻底弄懂这个问题，我们需要详细梳理 Angular 中 effect 的“自动清理”到底清理了什么，以及 onCleanup 的真正运行机制。

1. 概念澄清：文档里说的“自动清理”指的是什么？

当 Angular 文档提到 effect 会“在组件销毁时自动清理”时，它指的是 Effect 这个监听器本身会被销毁。

它做了什么：因为 effect 是在组件的注入上下文（Injection Context）中创建的，Angular 内部把它和组件的生命周期绑定在了一起。当组件被销毁时，Angular 会自动断开这个 effect 与所有 Signal 之间的依赖追踪机制。这个 effect 函数以后再也不会被触发了。
它没做什么：Angular 不会去解析你在 effect 的回调函数里面写了什么原生 JavaScript 代码。它不知道你开启了定时器（setInterval）、发起了一个原生 DOM 事件监听（addEventListener），或者订阅了一个 RxJS 流（subscribe）。这些都属于“外部副作用”，Angular 无法自动追踪并销毁它们。

2. 为什么 Interval 和 Subscription 会泄漏？

在你的例子中：

effect(() => {
  const id = setInterval(() => {
    this.count.update(v => v + 1);
  }, 1000);
  // 如果没有下面这句，就会发生泄漏
  // onCleanup(() => clearInterval(id));
});

对于 setInterval：这是浏览器的 Web API。即使 Angular 销毁了组件和这个 effect 实例，浏览器依然会在后台每隔一秒执行一次回调。不仅消耗性能，而且如果回调里引用了组件的属性（比如 this.count），这个组件实例就无法被垃圾回收机制（GC）回收，导致严重的内存泄漏。
对于 subscribe：同理，当你调用 observable$.subscribe() 时，你和 RxJS 流建立了一个连接。如果不手动调用 .unsubscribe()，这个连接就会一直存在，流一旦有新数据就会继续推送，同样会引发内存泄漏和意外的逻辑错误。

3. `onCleanup` 的两个核心执行时机

onCleanup 提供的回调函数会在以下两种情况下被触发。理解这一点非常关键：

在 Effect 下一次重新执行之前：
如果你的 effect 内部依赖了某个 Signal（比如 this.userId()），当 userId 改变时，effect 需要重新运行。在重新运行之前，Angular 会先调用上一次注册的 onCleanup。
(用途：比如你的 effect 是根据 userId 去发起轮询请求，当 userId 变化时，你可以利用 onCleanup 清除旧用户的轮询，然后再开启新用户的轮询。)
当 Effect 所在的上下文（如组件）被销毁时：
这是最终的兜底清理，确保组件卸载时，外部副作用被彻底清除。

4. 最佳实践：如何处理 Effect 中的 RxJS 订阅？

虽然你可以在 effect 里面 subscribe 并使用 onCleanup 来 unsubscribe，但这极其不推荐。在 Angular 的新响应式模型中，混合使用 effect 和 subscribe 往往是反模式（Anti-pattern）。

如果你有 Observable 需要处理，请使用以下方法：

推荐做法 1：使用 toSignal（完全抛弃 subscribe 和 effect）
如果你的目的是将流的数据转换为页面状态，直接转成 Signal 即可，toSignal 内部会自动处理组件销毁时的 unsubscribe。

import { toSignal } from '@angular/core/rxjs-interop';

export class LoggerComponent {
  // 自动订阅，组件销毁时自动取消订阅，根本不需要 effect
  data = toSignal(this.dataService.getData$()); 
}

推荐做法 2：使用 takeUntilDestroyed（如果你确实需要执行一段独立逻辑）
如果你只是想监听 Observable 并在其触发时执行某个动作（而不是更新 Signal），你应该直接在 constructor 中订阅，并加上 takeUntilDestroyed 管道。

import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

export class LoggerComponent {
  constructor() {
    this.someObservable$
      .pipe(takeUntilDestroyed()) // 自动绑定当前组件的生命周期
      .subscribe((data) => {
        console.log(data);
      });
  }
}

总结

effect 本身的依赖追踪会自动清理。
effect 内部写的不受管理的副作用（如 DOM 事件、Interval、RxJS Subscribe 等）绝对不会自动清理。
只要在 effect 里面引入了外部系统的持续性任务，必须使用 onCleanup 来手动清除。
尽量避免在 effect 中直接 subscribe Observable，善用 @angular/core/rxjs-interop 提供的工具（如 toSignal 和 takeUntilDestroyed）。

0 replies

llccing · 2026-04-17T07:42:36Z

llccing
Apr 17, 2026 — with giscus
Maintainer

这是一个非常顺理成章的进阶问题！在 Angular 的 HttpClient 体系中，HttpResponse 代表的是一个完整的 HTTP 响应对象。

为了让你彻底搞懂，我们需要先了解 HttpClient 的一个“默认行为”。

1. 默认行为 vs. `HttpResponse`

在 Angular 中，当你发起一个普通的 HTTP 请求时，比如：

this.http.get<MyData>('/api/data').subscribe(data => {
  console.log(data); 
});

默认情况下，Angular 会非常贴心地帮你把外层的 HTTP 壳子剥掉，只把解析好的 JSON 数据体（Body）返回给你。 这在 90% 的业务场景下都是最方便的。但是，如果你不仅需要数据，还想看看响应头（Headers）里有什么，或者想看看 HTTP 状态码（Status Code）是多少，这时候默认的返回值就不够用了。

这就是 HttpResponse 登场的时刻。

2. 如何获取 `HttpResponse`？

如果你需要完整的响应信息，你必须在请求的配置项中明确告诉 Angular：observe: 'response'。

import { HttpResponse } from '@angular/common/http';

this.http.get<MyData>('/api/data', { 
  observe: 'response' // <-- 关键配置：告诉我你要观察完整的响应
}).subscribe((res: HttpResponse<MyData>) => {
  // 这时候你拿到的 res 不再只是数据体，而是一个完整的 HttpResponse 对象！
  console.log(res.status); // 打印状态码，例如 200
  console.log(res.headers.get('X-Total-Count')); // 读取自定义请求头
  console.log(res.body);   // 这才是你真正需要的数据
});

3. `HttpResponse` 对象里到底有什么？

HttpResponse 是 @angular/common/http 提供的一个类，它包含了服务器返回的所有重要信息。它的核心属性包括：

body: 数据体本身（通常是 JSON 转换后的对象或数组），其类型就是你泛型传入的类型（比如 <MyData>）。
headers: 一个 HttpHeaders 对象，包含了服务器返回的所有响应头。
status: HTTP 状态码（比如 200 表示 OK，201 表示已创建）。
statusText: 状态码对应的文本（比如 "OK" 或 "Created"）。
url: 最终响应此请求的 URL（有时请求会被重定向，这个属性会显示最终的 URL）。

4. 真实业务场景：我们什么时候必须用 `HttpResponse`？

虽然日常开发直接拿 body 就够了，但在以下几个经典场景中，你必须用到 HttpResponse：

场景一：读取分页信息。
很多后端 API 在返回列表数据时，不会把“总条数”放在 body 里，而是放在响应头（Header）里，比如 X-Total-Count: 100。你需要拿到完整的 HttpResponse 才能去解析 headers。
场景二：无痛刷新 Token (Refresh Token)。
有时候后端端会在响应头里默默带上一个新的 Token 给你（比如 Authorization: Bearer <new_token>），前端需要拦截请求，读取 HttpResponse.headers，拿到新 Token 并存入 LocalStorage。
场景三：下载文件。
当你请求下载一个文件（Blob）时，后端通常会把真实的文件名放在响应头的 Content-Disposition 里。为了在前端下载时保持正确的文件名，你必须获取完整的响应。

总结

如果只需要数据：默认写法，直接拿 Body。
如果需要看状态码、读响应头、处理文件下载：加上 { observe: 'response' }，拿到完整的 HttpResponse。

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

posts/angular-features-19-to-21/ #25

Uh oh!

{{title}}

Uh oh!

Replies: 4 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

posts/angular-features-19-to-21/ #25

Uh oh!

giscus[bot] Bot Apr 17, 2026

posts/angular-features-19-to-21/

Replies: 4 comments

Uh oh!

llccing Apr 17, 2026 — with giscus Maintainer

1. linkedSignal 变更了，会更新 source 吗？

2. sortBy 的例子里是不是少了 price 字段？

3. computation 到底是干嘛用的？

computed vs linkedSignal 的本质区别：

总结

Uh oh!

llccing Apr 17, 2026 — with giscus Maintainer

一、 HttpClient 的底层到底是什么？

二、 Fetch vs. XMLHttpRequest (XHR)：有什么区别？

三、 主流方案是哪种？(Fetch 还是 XHR)

四、 为什么 Angular 要同时提供 resource 和 httpResource？

1. resource：万能的异步数据加载器

2. httpResource：专为 Angular HTTP 生态打造的特种兵

五、 总结与建议

Uh oh!

llccing Apr 17, 2026 — with giscus Maintainer

1. 概念澄清：文档里说的“自动清理”指的是什么？

2. 为什么 Interval 和 Subscription 会泄漏？

3. onCleanup 的两个核心执行时机

4. 最佳实践：如何处理 Effect 中的 RxJS 订阅？

总结

Uh oh!

llccing Apr 17, 2026 — with giscus Maintainer

1. 默认行为 vs. HttpResponse

2. 如何获取 HttpResponse？

3. HttpResponse 对象里到底有什么？

4. 真实业务场景：我们什么时候必须用 HttpResponse？

总结

giscus[bot]
Bot Apr 17, 2026

llccing
Apr 17, 2026 — with giscus
Maintainer

1. `linkedSignal` 变更了，会更新 `source` 吗？

2. `sortBy` 的例子里是不是少了 `price` 字段？

3. `computation` 到底是干嘛用的？

`computed` vs `linkedSignal` 的本质区别：

llccing
Apr 17, 2026 — with giscus
Maintainer

一、 `HttpClient` 的底层到底是什么？

三、主流方案是哪种？(Fetch 还是 XHR)

四、为什么 Angular 要同时提供 `resource` 和 `httpResource`？

1. `resource`：万能的异步数据加载器

2. `httpResource`：专为 Angular HTTP 生态打造的特种兵

五、总结与建议

llccing
Apr 17, 2026 — with giscus
Maintainer

3. `onCleanup` 的两个核心执行时机

llccing
Apr 17, 2026 — with giscus
Maintainer

1. 默认行为 vs. `HttpResponse`

2. 如何获取 `HttpResponse`？

3. `HttpResponse` 对象里到底有什么？

4. 真实业务场景：我们什么时候必须用 `HttpResponse`？