Don't recalculate derived properties until next access

[STRML]

I plan to submit a PR for this - opening this issue to track it.

The issue is that derived properties are often expensive, and any change to any dep causes a recalculate, even if the property has not been accessed.

Considering that derived props are already getters, dep changes should instead set a dirty flag (since delete self._cache[name] would cause deopt) which marks the property for recomputation.

[STRML]

The only issue I can think of is change listeners - any ideas on this? Should we be checking for the presence of a change or change:${derivedKey} listener, then revert to the current behavior if present?

[latentflip]

The only issue I can think of is change listeners - any ideas on this? Should we be checking for the presence of a change or change:${derivedKey} listener, then revert to the current behavior if present?

Are there many situations where you would have a derived property on a model, but would have no change/change:${derivedKey} listeners on that model at all?

[latentflip]

I'm not going to suggest that this has as nice an API as a derived property does - I've not tried to abstract it in any way - but an alternative way of doing this if you don't need the change events, and just want a cached getter, is to just create a cached getter, using Object.defineProperty on the prototype, and something like lodash.memoize for the caching.

If you do need the change events, then I'm not sure that you can avoid the current behaviour.

Here's an example:

http://esnextb.in/?gist=acf4e2cae3bab5eae5f4

[STRML]

Yes - I don't use change listeners at all, I'm using ampersand-state with a Flux pattern so I know exactly when changes have been made.

I often use derived properties to mask and cache expensive operations that are not used often - until now I had assumed that recalculation was only done at access, not if any dep had changed.

It should be relatively simple to record when change handlers have been attached. Can you think of any issues with this approach?