@dwzrlp
新西兰就是这样的

@chnwillliu
那它这么折腾侵入性太强了，反而不如 wpf 的实现优雅了。后者实现接口通知属性变更就行，我在实际使用过程中是偷懒反射然后动态触发通知，也算简洁和入侵不强。

@hero1874
QQ 音乐会员，少打字了

我近期也在考虑不再续费 QQ 会员了，之前说好的免广告，结果现在只提供给最高档会员。你大可涨价，不要动不动改口。

可能是时候搞家庭 NAS 了。

@Mirachael #14

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

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

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

@ing995683
有福利的国家可能就没这个问题：当然问题可能就变成排队排死。

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

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

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

润到一个不用工作，到年龄就可以有退休金的国家。

洗碗机？花 20 分钟洗不能机洗和简单处理，然后扔海碗机。

回家了就不要工作了，不要像另外一个帖子中连做爱时都在写代码。

我之前也一直是 16G ，公司给的电脑。我也开着项目编译，跟别人视频也不卡。其实就是只要你不去看内存指标，你就感觉不到卡。但有人就是会说：不对，你卡。

@zidian
确实是，就像“不检查就没新增”，当时觉得是有问题，现在看起来确实是这样。

我用 Angular 这么多年，主要领悟就是能共享对象就不要传什么方法。然后在其他地方替换对象或更新它的值。比计算要高性能，也不要用 get/set 属性，这个会比一般的变量浪费性能因为需要计算才能拿到值，直接给字段，省去重复调用的过程。

你这种还不如这样：{{user.address.length}}。user 来自 userService ，这个对象一直不变，登录修改里面的值。这样肯定可行。你那个主要问题是不确定什么时间会改变，会导致 Angular 不断调用才能判断。

我的电脑过于旧，不支持 Win11 ，就没这个烦恼。[狗头]

至少 OP 的案例让我放心采用所谓的“每个应用一个数据库”的想法。哈哈。

@springhead

是我相像的那种店吗