Difference between computed() and computedFn()

[lekevin-microsoft]

Heya,

I want to solidify my understanding of computed vs computedFn. Could someone help me understand the difference between:

const isEmpty = computedFn(
    (props: complexProps): boolean => {
        return lotsaWorkFunction(props);
    }
);

vs.

function isEmpty(props: complexProps): boolean {
    return computed(() => lotsaWorkFunction(props)).get();
};

Here's what I know:

1. They both properly return a computed, in which it protects the caller from needing to rerender based on lotsaWorkFunction's inner workings. Now, it only cares about the return value: true or false.
2. computedFn will try and cache the result based on the properties, however that means that if the complexProps are too complex (e.g. lots of structural comparisons, nested objects, etc), it's just wasted work at best, and maybe worser memory consumption at worst.

Is there any other drawbacks for the computed() way? I'm struggling to understand when I'd use computedFn, besides for the times that the parameters are really simple (numbers, strings, booleans) and it'd be worth doing the next level of memoization.

Thanks!
Kevin Lee
Microsoft

[urugator]

function isEmpty(props: complexProps): boolean {
    return computed(() => lotsaWorkFunction(props)).get();
};

Every time you call isEmpty you create a new computed, meaning lotsaWorkFunction always has to run. The cached value is never re-used.
It only avoids notifying the caller, when lotsaWorkFunction's observable dependency changes and the result stays the same. This can help a little when a caller is expensive, but it never prevents calling lotsaWorkFunction, which given the function name, was probably the intention.

[mweststrate]

Additionally, another way to think about it: a computed has only value if you store it somewhere, as it is conceptually just a cache. Without storage, there is no added value beyond doing directly lotsaWorkFunction(props). For normal computed properties of an object, the object instance itself is the cache. (So that assumes you keep observable objects around).

For computed functions, the cache becomes conceptually [object instance, ....parameters]. Since parameters can wildly vary, you can get many caches this is basically a tradeoff of memory for cpu that computedFN takes.

I think what would be nice to have here is an abstraction that only caches the computed for the latest arguments set, for cases where arguments typically doesn't change / isn't called from many different contexts. Something that'd generalise a pattern like:

function isEmpty(props: complexProps): boolean {
    if (this._isEmpty_computed && isEqual(this._isEmpty_arguments, props)) {
       return this._isEmpty_computed.get()
    }
    this.isEmpty_arguments = props
    this.isEmpty_computed = computed(() => lotsaWorkFunction(props));
    return return this._isEmpty_computed.get()
};

[lekevin-microsoft]

Thanks so much @urugator and @mweststrate . Reading your replies made me realize a possible misunderstanding I have, which leads me to one further question:

If computedFn does not get a parameter cache-hit (i.e. param values are different), but it returns the same value, would that still notify the caller?

Example, using the isEmpty from earlier:

const isEmpty = computedFn(
    (props: complexProps): boolean => {
        return lotsaWorkFunction(props);
    }
);

If props were different, but isEmpty still returned true, would the caller be notified of the difference and still re-render, or would it see that it's still the same value and not?

My understanding was that the caller would only be not notified if the computedFn's parameters also matched, but now I'm not so sure after digesting your replies.

Thanks again,
Kevin

[urugator]

The caller is the one who calls the function and provides new params. The caller must have been already invoked by something - eg notified by some observable (eg. an observable accessed in the computedFn) or eg component recieving new props. It's already re-rendering. Params only decide whether lotsaWorkFunction is going to run or not.

[urugator]

Maybe the part that isn't so obvious: If the computedFn is invalidated by an observable, it is recomputed with the previously passed params (the last one), if the result changes, caller is notified, re-runs, calls isEmpty again, but very likely with the same set of params, so it won't re-computed twice.

[lekevin-microsoft]

Oh, wow. I see. That's very intricately done, but I see... It's this sort of top-down and bottom-up call stack thinking that is new to me.

So if we have (a summary of my understanding now):

• Component A calls isEmpty(props) which cares about observable observableA.
• If observableA changes, isEmpty(props) will just call itself with the same props because those props never changed, as what's prompting the computedFn to recompute isn't Component A, but rather the observableA being updated.
  • I thought this would be buggy, because "wait, how can you be sure that isEmpty(props) the props aren't stale?" but that's because that's how MobX works, where it only notifies those who listen to observableA, and Component A doesn't know about the observable because it calls the computed function isEmpty, a caching point.
• Lastly, if Component A rerenders, then isEmpty has a chance to be given new props. At this point, computedFn has a chance to optimize the program: If Component A calls it again with the same props, isEmpty doesn't re-run and just returns the cached value. If not, it'll re-run naturally.

That's very interesting. Thanks for helping me so much, I really appreciate it.

Best,
Kevin