mardi 29 juin 2021

Best approach to caching in Ember Octane

I have a project running Ember@3.20. We are currently in the process of migrating from classic to glimmer based components and have come across some expensive computational patterns which would benefit from caching.

My question is, what is the best approach to caching functionality to getters for glimmer components? It looks like there are currently a few ways to do this:

  1. @cached via tracked-toolbox - I believe this was released prior to the ember cached api. I didn't peek under the hood but it has the has a @cached decorator which might collide with future ember @cached.
  2. ember-cache-primitive-polyfill - Mentioned in the Ember docs as a polyfill for the ember cached API (3.22) but the syntax isn't as concise as the @cached decorator
  3. ember-cached-decorator-polyfill - related to RFC566 appears to be based on option 2 with a more ergonomic syntax
  4. Upgrade to 3.22 - Trying to avoid bumping ember unless there is a significant benefit. At a glance, I didn't see @cached included here though.

Any additional insight/guidelines into how expensive a getter should be to warrant it being cached? For example, preventing re-renders seems a fairly obvious use case but there can be a wide range of what developers might consider an "expensive" computation.




Aucun commentaire:

Enregistrer un commentaire