dynamically parametrized selectors (dynamic range of computeds)

[ducin]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

TL;DR; Due to computed caching only the most recent computation, it could happen, that unnecessarily the calculations could be repeated over and over again. This proposal is about a way to cache parametrized/multiple (dynamically) computed values

Example Issue

Let's take a look at the following example (from docs):

type BooksState = {
  books: Book[];
  isLoading: boolean;
  filter: { query: string; order: 'asc' | 'desc' };
};

We can create a computed depending on the current state of the filters:

  withComputed(({ books, filter }) => ({
    visibleBooks: computed(() => {
      const phrase = filter.toLowerCase()
      return books.filter(book => {
        return book.title.toLowerCase().includes(phrase)
      })
    }), 
  })),

const books = [
  {title: "abc 1"},
  {title: "xyz 1"},
  {title: "abc 2"},
  {title: "xyz 2"},
  ...
]

An (angular) computed value is cached for the current value of all its dependencies (current value of filter, e.g.query=""andbooks = [...], all works as expected. But when any dependency change, e.g.filter.querychanges, then the entire **visibleBooks` has to be re-computed**. And that could be a heavy operation. And if we keep on switching between two values of filter.query but we have the same books (e.g. fetched once from the API):

• filter.query == abc // result -> [ {title: "abc 1"}, {title: "abc 2"}, ...] // this result FIRST TIME
• filter.query == xyz // result -> [ {title: "xyz 1"}, {title: "xyz 2"}, ...] // this result FIRST TIME
• filter.query == abc // result -> [ {title: "abc 1"}, {title: "abc 2"}, ...] // this result HAS ALREADY BEEN CALCULATED
• filter.query == xyz // result -> [ {title: "xyz 1"}, {title: "xyz 2"}, ...] // this result HAS ALREADY BEEN CALCULATED ...

then each time the computed gets dirty, has to recompute, even though the books is the same and, essentially, books.filterBy('abc') result never changes.

This proposal addresses more advanced usecases which, IMO, will appear sooner or later.

The idea is to:

• introduce a parametrized computed. The difference: ordinary computed is reactive, but not-parametrized
• what we need is a range of computeds. And there's no built-in API for creating a dynamic range of computeds. We could run them in a loop, if we know the values upfront, but in a case where the query comes from the user input, we'd have to add them dynamically, which increases the complexity.
• create a Map of computeds: keys: array of computed parameters, values: native computeds.
• the withMemo, withParametrizedComputed` (or whatever the name becomes) could be either a function encapsulating the access to the Map (and calling underlying computeds) or a Proxy (which would essentially do the same.

Describe any alternatives/workarounds you're currently using

the only alternative I can think of is:

• providing just an ordinary selector (non-parametrized) which is automatically cached (natively on angular level), but then filtering (by parameter) has to take place outside. And is not cached 🙁

I would be willing to submit a PR to fix this issue

• [X] Yes
• [ ] No

Example API Proposal

This is just an example of the API, I'm not bound to the API in any way. Design decisions:

• caching all possible dependencies (all results for ALL books and ALL filter values) would be RAM-expensive and rather not very useful. Not all keys make sense to be cached
  • example: when books change (new response from the API) then all cached results have no meaning anyway
• choose which keys make sense to be cached, e.g. here: filter, ass long as books don't change
• choose, then the cache gets cleared, e.g. when books change.

API: withParametrizedComputed((state, cacheKeyFn, clearCacheMap) => newComputeds

• state is the same as in withComputed,
• result newComputeds is the same as in withComputed,
• cacheKeyFn is a function which returns a cache key, the cache itself is an ES Map (not {} in case the chosen key is an object). Example: ({ books, filter }) => filter (yes, books is unused, left it there for readability)
• clearCacheMap: default (implicit) is { books: true, filter: true } which means clear ALWAYS whenever either books or filter changes. It gets explicitly overriden by - in our example - { filter: false } which results in { books: true, filter: false } (reset only on books change).

Example:

  withParametrizedComputed(({ books, filter }, ({ filter }) => filter, { filter: false }) => ({
    visibleBooks: computed(() => {
      const phrase = filter.toLowerCase()
      return books.filter(book => {
        return book.title.toLowerCase().includes(phrase)
      })
    }), 
  })),

The underlying ES Map could look like the following:

• Map { } - initially empty, visibleBooks computed never used
• Map { "abc" => [bookA, bookB, ...] } - first result of computed, filter=abc
• Map { "abc" => [bookA, bookB, ...], "xyz" => [bookX, bookY, ...] } - second result of computed, filter=xyz
• Map { "abc" => [bookA, bookB, ...], "xyz" => [bookX, bookY, ...] } - filter=abc chosen again
• Map { "abc" => [bookA, bookB, ...], "xyz" => [bookX, bookY, ...] } - filter=xyz chosen again
• ...
• (Map { } - books changed, cache cleared, but immediately new visibleBooks value gets computed)
• Map { "abc" => [bookAnotherA, bookAnotherB, ...] } - first result over new books, filter=abc

Of course the API is far from perfect, it's just a starting point for the discussion.

[rainerhahnekamp]

@ducin would have to read through it multiple times to fully understand it. Are you sure there is no way you can fix it with an equals function in the computed? That one's quite powerful.

Could you add a snippet of how such a parameterized computed would look like? That would help a lot

[ducin]

@rainerhahnekamp @markostanimirovic I have significantly updated the description, and provided an example API to better outline the issue.

[rainerhahnekamp]

Thanks for the clarification Tomasz

[markostanimirovic]

Instead of a custom SignalStore feature (withParametrizedComputed), I'd like to have a custom version of the computed function that has a caching mechanism for the previous results. So it can be used within the SignalStore, but also as a standalone API.

The only problem I see is that it cannot have a computed-like signature with implicit dependency tracking:

const filteredUsers = myComputed(() => {
  return users().filter((u) => u.name.includes(query()));
}, { cacheSize: 10 });

because we won't be able to resolve what are dependent signals and apply proper caching.

Should we reintroduce selectSignal with caching functionality then? 😄 Maybe with a different name: 👀

const filteredUsers = explicitComputed(users, query, (users, query) => {
  return users.filter((u) => u.name.includes(query));
}, { cacheSize: 10, ttl: 60 * 1_000 }); // time to leave is 0 by default

I'm going to convert this issue into a discussion. Feel free to share your thoughts!