3

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

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

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

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

4

1 回答 1

4

这里有两类东西：

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

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

至于@cached装饰器，它们的语义基本相同。tracked-toolbox 版本是为 Glimmer 发布的（和 Ember 使用的）原语的开发提供的研究，因此ember-cached-decorator-polyfill使用实际的公共 API 实现 -ember-cache-primitive-polyfill如果需要，可以通过 polyfill 来实现。

就性能特征而言，您甚至实际上不需要考虑防止重新渲染：无论如何，这不是系统的工作方式。（请参阅我去年（2020 年）撰写的这篇博文，深入了解如何使用自动跟踪概念在 Ember 和 Glimmer 中安排重新渲染。）同样值得记住的是，缓存不是免费的！所以这不是“这东西要花钱，所以我应该缓存它”那么简单——缓存必须为自己付出代价才值得，而且创建和检查缓存需要消耗内存和 CPU 时间。

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

  • 我要渲染数百次还是数千次？
  • 渲染这会导致长时间运行的计算，这会影响渲染（即大约几毫秒）
  • 这会触发异步行为吗？
  • （尤其是）这会触发 API 调用吗？

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

于 2021-06-29T20:12:38.400 回答