在 Ember Octane 中缓存的最佳方法

如何解决在 Ember Octane 中缓存的最佳方法

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

我的问题是，将功能缓存到微光组件的吸气剂的最佳方法是什么？看起来目前有几种方法可以做到这一点：

1. @cached via tracked-toolbox - 我相信这是在 ember 缓存 api 之前发布的。我没有深入了解它，但它有一个 @cached 装饰器，它可能会与未来的 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 应该多昂贵才能保证它被缓存的任何额外的见解/指南？例如，防止重新渲染似乎是一个相当明显的用例，但开发人员可能会认为“昂贵”的计算范围很广。

解决方法

这里有两类东西：

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

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

至于 @cached 装饰器，它们基本上具有相同的语义。跟踪工具箱版本是一项研究，用于开发 Glimmer 提供（和 Ember 使用）的原语，因此 ember-cached-decorator-polyfill 是使用实际的公共 API 实现的——如有必要，通过 ember-cache-primitive-polyfill 对其进行 polyfill .

---

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

牢记这一警告，我倾向于将“费用”分为以下几类：

• 我是要渲染成百上千次吗？
• 渲染这会导致长时间运行的计算，这会影响渲染（即以几毫秒为单位）
• 这是否会触发异步行为？
• （特别是）这会触发 API 调用吗？

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