[Documentation] How to memoize autotracked properties

[YoranBrondsema]

I'm a long-time Ember user and it wasn't clear to me until recently that getters that use autotracking in Glimmer components are not memoized by default. In my interpretation of all the things that I read about autotracking in annoucements, blog posts and so on, autotracking was a drop-in replacement for computed: all the same benefits (including memoization) but without having to explicitly list the dependencies. Maybe I didn't read carefully enough, or maybe it wasn't communicated clearly enough.

I realized that it wasn't when I started noticing degrading performance when I moved certain components in my application to Ember Octane. To my surprise, many getters were being recomputed even though the values of the getters they call didn't change.

For this reason, I can't wait for the @cached RFC to merge or to be available in a polyfill.

However, in the mean time, I still want to be able to enforce memoization for some properties in my Ember Octane components:

1. What is the idiomatic way of doing this in the current version of Ember.js? Is the @computed decorator compatible with autotracking? I don't mind if I need to explicitly list dependencies until the @cached RFC is merged. My priority now is to resolve the performance issues by avoiding unnecessary expensive recomputations.
2. Would it make sense to document this somewhere, in e.g. the Autotracking In-Depth guide? I'd be happy create a PR that adds this once I know the answer to my first question.

[pzuraq]

Hey @YoranBrondsema, thanks for opening up this issue! @cached will definitely provide a solution to this issue that is more conventional, but there are some options that are available to users currently. We recently shipped caching primitives, and there is a polyfill for them which can be used currently. In addition, I added an implementation of the @cached decorator to my addon, tracked-toolbox, which is meant to cover odds and ends of autotracking utilities.

I agree that we should document caching via the cache primitive in the guides, this would be the current idiomatic way to do accomplish this with autotracking, and we actually discuss adding it to the guide this in the RFC. I haven't had a chance to write a guide yet, help would definitely be appreciated there!

[YoranBrondsema]

@pzuraq Thank you for your very helpful reply.

In addition, I added an implementation of the @cached decorator to my addon, tracked-toolbox, which is meant to cover odds and ends of autotracking utilities.

Great, I never knew about the addon. So I imagine that the @cached decorator in tracked-toolbox is an implementation of the @cached RFC?

I agree that we should document caching via the cache primitive in the guides, this would be the current idiomatic way to do accomplish this with autotracking, and we actually discuss adding it to the guide this in the RFC. I haven't had a chance to write a guide yet, help would definitely be appreciated there!

Cool. I'll work on it over the next few days and create a PR.

Last thing: if I understand correctly, the @computed function has become completely obsolete in Ember Octane? If so, maybe we could add a short message in the API doc that indicates this and would link to the guide with the Octane way of doing reactive properties. I'm thinking it can be quite confusing for the new Ember user at the moment, who may be left unsure about what the idiomatic API is that he should use. And strong conventions is one of Ember's great strengths compared to the other "frameworks" out there!

[urbany]

Hi @pzuraq i also need this and tried using that polyfill you mentioned but it didn't work because of this bug: ember-polyfills/ember-cache-primitive-polyfill#3

Can I use the @cached decorator from your plugin instead? Thanks in advance!

[pzuraq]

@urbany you can absolutely use the @cached decorator, that's what it's meant for 😄

[YoranBrondsema]

FYI there's now also a dedicated polyfill for @cached: ember-cached-decorator-polyfill.

So the options for caching autotracked properties as of today are:

1. use the low-level Ember.js caching API as described in the official guide.
2. use the @cached decorator from tracked-toolbox
3. use the @cached decorator from ember-cached-decorator-polyfill

I guess the choice is yours, until the @cached decorator ends up in Ember core :-)

Closing this for now as the main issue (documenting the memoization) has been resolved.