feat(cachedComputedFrom): decorator for computed properties with caching

[doodlesbykumbi]

cachedComputedFrom is just a caching-enabled version of computedFrom.
cachedComputedFrom implements temporary caching for repeated fast access to the computed property while it's dependencies remain unchanged.

I did some profiling and cachedComputedFrom was more performant where it needed to be, i.e. when the the computed property is the same if it's dependencies remain unchanged.

[AshleyGrant]

@jdanyow what are your thoughts on this PR?

[EisenbergEffect]

Perhaps something like this should be the default behavior?

[doodlesbykumbi]

@EisenbergEffect Possibly.

Initially, I thought of augmenting the computeFrom decorator to have a toggle for caching but I don't think that's a good idea just because it's giving one thing too much to do.

I think there should definitely be 2 different behaviours, since it's not clear the sort of functions people use as their getters, they could well be impure and be expected to cause a myriad of side effects every time they are invoked. It's always good to have a choice

[brandonseydel]

What about just making the default to not cache unless specified. (I would like it to be the other way, but as you stated people could currently be doing some additional logic in their getters)

@computedFrom("") -> not cached
@computedFrom("", true) -> cached

[EisenbergEffect]

@jdanyow What if we aliased computedFrom to be computed and then we added the cached mechanism using a decorator called pure?

[brandonseydel]

What if you want to specify a completely different object for the caching mechanism?

@computedFrom("firstName", "lastName")
@cached -> original proposed implementation
@cached("cachingMechanism")
get fullName(){//returns concat};

Analyzes a different object to determine whether or not the value needs to be refreshed.
(maybe first name has changed but you don't want to propogate the changes until last name has also changed)

[doodlesbykumbi]

@EisenbergEffect hey, so whatever you guys decide is best I'd be more than happy to implement it. The intention of this pull request really was both to get feedback on my solution to a problem I faced while creating an aurelia app but also to get my foot in the door with regard to making a habit of contributing to aurelia. It's not clear to me what needs contribution but I hope this is the beginning.

[EisenbergEffect]

Awesome! Thanks for being so willing to join in and help. @jdanyow Do you have any thoughts on this?

[jdanyow]

Definitely a solid idea. I think this would make a nice plugin. Couple thoughts/suggestions:

1. Using string.split to parse the expression is probably ok for 99% of the real-world scenarios. computedFrom supports any expression that works in binding (eg foo[0].bar.baz)- not sure if that's something you wanted to support as well.
2. You could exchange the .every and .map for simple for-loops to avoid extra closures
3. I'm wondering if it would be cleaner/more-performant to put the caching logic in the ExpressionObserver instead. There may be some logic still needed in the decorator to check for the presence of the observer when the property is being accessed and forward the call to the observer's getValue method (assuming it has caching).

[Truffula]

Did this ever ended up being implemented anywhere (as a plugin or otherwise)?

[bigopon]

@Truffula thanks for notifying about this. I didn't know we had a PR for this. The current state of this plugin does not guarantee it works in all scenarios, as dependencies are simply retrieved via index/keyed operator [].

There's a plugin here that gives you the cached computedFrom behavior: https://github.com/bigopon/aurelia-deep-computed (I created this)