caching - 在 Ember Octane 中缓存的最佳方法

Question

我有一个运行 Ember@3.20 的项目。我们目前正处于从经典组件迁移到基于微光的组件的过程中，并且遇到了一些可以从缓存中受益的昂贵计算模式。

我的问题是，将功能缓存到 glimmer 组件的 getter 的最佳方法是什么？看起来目前有几种方法可以做到这一点:

1. @cached via tracked-toolbox - 我相信这是在 ember 缓存 api 之前发布的。我没有深入了解，但它有一个 @cached 装饰器，它可能会与 future 的 ember @cached 发生冲突。
2. ember-cache-primitive-polyfill - 在 Ember docs 中提到作为 ember 缓存 API (3.22) 的 polyfill，但语法不如 @cached 装饰器简洁
3. ember-cached-decorator-polyfill - 与 RFC566 有关似乎是基于具有更符合人体工程学语法的选项 2
4. 升级到 3.22 - 除非有明显的好处，否则尽量避免碰撞 ember。乍一看，我没有看到这里包含 @cached。

关于 getter 应该多昂贵才能保证它被缓存的任何其他见解/指南？例如，防止重新渲染似乎是一个相当明显的用例，但开发人员可能认为“昂贵”的计算范围很广。

Answer 1

这里有两类东西:

1. 两个 @cached 装饰器。
2. 通过 RFC 0566 引入的缓存原语.

在绝大多数 Ember 或 Glimmer 应用程序或普通库代码中，您只会使用装饰器。只有当您自己构建一些低级库代码时，您才会真正接触到缓存原语(不是从不，但也不完全是常见)。 p>

至于 @cached 装饰器，它们基本上具有相同的语义。 tracked-toolbox 版本是为 Glimmer 发布(和 Ember 使用)的原语开发提供支持的研究，因此 ember-cached-decorator-polyfill 是使用实际的公共(public) API — polyfilling 实现的如有必要，通过 ember-cache-primitive-polyfill 实现。

---

就性能特征而言，您实际上甚至不需要考虑防止重新渲染:反正系统不是这样工作的。 (请参阅 this blog post I wrote last year (2020) 深入了解如何使用自动跟踪概念在 Ember 和 Glimmer 中安排重新渲染。)同样值得记住的是缓存不是免费的!因此，这并不像“这东西要花点钱，所以我应该缓存它”那么简单——缓存必须为自己付出代价，这样才值得，而且创建和检查缓存需要内存使用和 CPU 时间。

牢记这个警告，我倾向于将这里的“费用”分为以下几类:

• 我是否将其渲染了数百次或数千次？
• 渲染是否会导致长时间运行的计算影响渲染(即几毫秒的数量级)
• 这会触发异步行为吗？
• (尤其是)这会触发 API 调用吗？

在许多普通的应用程序代码中，您真正需要用 @cached 修饰的唯一 getter 是根据组件的参数生成 API 调用的 getter。由于每次引用 getter 时都会调用它，因此您最终会调用多个 API，这可能会导致 UI 中的明显状态随着对不同 promise 的引用而来回翻转的情况。