原因是你的 user 是同一个，你虽然设置了 addresses ，但是实际的 user 是没有变化的。

你要做的是把 user 里的 addresses 也设置 signal 。

@chnwillliu #9 我觉的跟 user 的 object reference 变没变没关系，因为这种写法是可以更新视图的

```
addresses = computed(() => {
const user = this.dataService.user();

// 直接返回 user.addresses ，页面会更新
return user.addresses;
});
```

@Mirachael #11
你这个返回的是 object 了，后面改变的也是 object ，那么不管它来自哪里，都能触发更新。

我倒是没注意这个新的 Feature ，但我觉得它可能会性能差。怎么说呢，我在做一个白板应用，用 Angular 管理成千的节点渲染出来，目前没有使用 Push 模式，有一次我大量将 field 改成了 getter/setter ，结果性能直线下降产生了明显卡顿感。所以我后面的实践都是能直接给 Field 就直接给，哪怕 getter 这种不计算的也是需要调用后才知道是否改变，会导致性能下降。

你的这个 Feature 就算没导致性能下降，但会导致写法过于混乱，跟直接绑定对象或属性比，不够简洁直观。

@chnwillliu #9 你说的对，浅拷贝还不行，必须使用深拷贝，因为在 computed 里使用的都是 addresses ，我使用 lodash 的 cloneDeep 方法就可以

```
addAddress() {
this.user.update((u) => {
const addr = new Address('test', '20000');
u.addAddress(addr);

return cloneDeep(u);
});
}
```

@Mirachael #14
我知道启用 Push 会更好，但我的问题是我在未遇到性能问题前我只想保持简洁高效，能用 Push 最好但比较繁琐，带来不必要的心智负担。我的 Default 模式下，将 Field 改成了 getter/setter 之后，直接导致性能严重下降：这已经明确证明了是与之前 Angular 能直接拿到对象或值相比，getter/setter 需要 Angular 每次都调用才能拿到值对比，而不是值就已经在它的处理层，只需要看值是否改变而已。

我目前基于 Default 模式做了很多框架简化开发，并没有引起性能问题，我又不是做专业组件所以从来没弄过 Push 模式。

@Mirachael #14

我做了很长时间的 WPF 和 Xamarin 应用，它们使用的就是 MVVM 设计，而且只有 Push 模式，我倒是羡慕 Angular 有主动检查而且不太影响性能的这种做法，这样能使很多事情大大简化。我做的白板需要同时渲染上千个节点在 SVG 面板中，实现各种效果，目前一点儿也不卡顿，同时还保留了架构和数据的简洁。在做这个项目过程中，最简单地检测是否卡顿的方式就是选中若干个对象，能拖多快就拖多快，看拖动是否平滑（因为会带着箭头什么的一起变动）。目前说真的，Default 模式就足够高性能。

@Mirachael 一个 signal 只有脏了才会 push dirty 的 notification 给下游的 computed ，effect 或者 view ，signal update 后脏不脏由 signal equality function 决定，默认用的 Object.is 检测前后两个值。所以并不需要 deep clone ，shallow clone 一样可以。

直接返回 address 能 work 只是因为你在 app component 里没用 onPush strategy ，默认在 UI event 后更新 component 的 view ，而 view 中使用了 address ，address push 了新值自然能在 view 中体现出来，和 signal 没关系，你就是写个普通 get 函数一样 work 。

@wunonglin #19

试过了，不是设置 true ，应该时设置为 false ，确实可以更新视图

```

user = signal<User>({} as User, {
equal: () => false,
});
```