[IMP] lazy reactive computed value

[caburj]

Problem: Prior to this commit, existing implementations of computed values
are eager. An example is the withComputedProperties in odoo's web addon, see:
¹. It has an issue such that it can lead to triggering of the compute
function even if the target is still in invalid state -- e.g. removing an item
in an array. This can be solved by batching the recomputation with batched.
But once the compute is batched, the computed value can't be used by other
computed values, because it won't recompute until the next tick -- it's not part
of the same synchronous context.

Proposed solution: This commit introduces a implementation of computed value
that is pull-based -- it only recomputes when it's needed. The main logic is the
following:

• A computed value is declared with a single-parameter function wrapped with
  computed.
• The compute function has a cache that stores the result of the computation.
• The cached value is invalidated when one of the dependencies of the compute
  function changes.
  • During invalidation, the cache is only marked as invalid and the
    recomputation is not made.
• A dependent computation such as an effect may indirectly depend in the
  dependencies of a computed value². This is an important detail because
  without this, the 'laziness' of the computed value won't trigger the dependent
  effect.
  • This indirect dependency tracking is achieved by using the introduced notion
    of multi-reactive target where a target can have multiple callbacks linked
    to it.
  • During recomputation of the computed value, both the target's reactive and
    the invalidation callback are subscribed to the dependencies of the computed
    value. But when the value is cached, only the target's reactive callback is
    subscribed.

With this implementation, we achieve a lazy computed value that plays well with
the existing reactive system.

---

Here's an illustration on how the computed values interact with the rendering.
Source

---

Footnotes

1. https://github.com/odoo/odoo/blob/15d7cf12b98bf0223371b8cca91ef6f79c60ee31/addons/web/static/src/core/utils/reactive.js#L58 ↩

2. It's possible that in the dependency graph, an effect is affected by
   invalidation. This effect will be triggered which will potentially ask for the
   value of the computed value which will trigger the recomputation. ↩

[caburj]

Hi @sdegueldre and @ged-odoo. What do you think about this?

[smetl]

@sdegueldre Up :p This PR looks very interesting to manage big js project with complex data structure like the POS !

[sdegueldre]

I'm not convinced a priori that we need this but if we do it feels like we could implement this on top of effect relatively simply?

function lazyComputed(obj, propName, compute) {
    const key = Symbol(propName);
    Object.defineProperty(obj, propName, {
        get() {
            return this[key]();
        },
        configurable: true,
    });
    effect(
        (obj) => {
            const value = [];
            obj[key] = () => {
                if (!value.length) {
                    value.push(compute(obj));
                }
                return value[0];
            };
        },
        [obj]
    );
}

There are still some shenanigans with a symbol because we don't trap defineProperty on reactive objects but otherwise this seems like a simpler implementation that doesn't require acess to owl internals or a new type of reactive object.

Edit: I've created a version of the todo list app on the playground that auto-sorts the list of tasks: playground link

Edit: slightly refined version:

function lazyComputed(obj, properties, deps = []) {
    for (const [propName, compute] of Object.entries(properties)) {
        const key = Symbol(propName);
        Object.defineProperty(obj, propName, {
            get() {
                return this[key]();
            },
            configurable: true,
        });

        effect(
            (obj, ...deps) => {
                const value = [];
                obj[key] = () => {
                    if (!value.length) {
                        value.push(Reflect.apply(compute, obj, deps));
                    }
                    return value[0];
                };
            },
            [obj, ...deps]
        );
    }
}

[caburj]

@sdegueldre I really tried to find a way without changing the internal but I couldn't. But man, your solution is awesome. I converted the tests to use your solution and it just works! Knowing this simple solution you provided, we can close this PR.

But before I close, you mentioned "There are still some shenanigans with a symbol because we don't trap defineProperty on reactive objects", when you find time, can you tell more about these shenanigans with the symbol?

[sdegueldre]

As you can see in my implementation, I'm still forced to write and read on a symbol property on the reactive object because at the moment, the reactivity system doesn't consider defineProperty to be a write, and so there is no way to update the getter and have it notify. So we have to do this rigmarole where we write a normal function property on the symbol and call it from the getter.

If that wasn't the case the code could be shortened to just an effect that defines the getter.