Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Provide access to dependency count within computed function #627

merged 3 commits into from Feb 9, 2014


None yet
2 participants

mbest commented Jan 1, 2014

This would allow you to do something different inside the function based on whether it will be updated in the future or not. This is related somewhat to #483.


mbest commented Sep 11, 2012

I first thought that this could be accomplished by passing the computed object as a parameter to the computed's read function. But although there may other uses for that, it won't be so good for this purpose currently. That's because a computed's dependencies aren't necessarily finalized until after the computed's read function finishes. We could change the algorithm to make this work, though.

Another option would be to make something like a ko.getComputedDependencies function available to get the current dependency count. It would use the length of the distinctDependencies array within the current frame of ko.dependencyDetection. This method would be useful in cases where there's no direct access to the computed anyway, such as in a binding handler update function.

mbest added some commits Jan 1, 2014

@mbest mbest Allow computed evaluator code to get info about computed state (initi…
…al evaluation and current dependency count). Update checked and if/ifnot/with bindings to take advantage of these.
@mbest mbest Export ko.computedContext and add tests. 5fdff3c

mbest commented Jan 1, 2014

The attached code adds an alias for ko.dependencyDetection, ko.computedContext, which now includes getDependenciesCount, isInitial, and computed. I updated the checked and if/ifnot/with bindings to use these new methods.

@mbest mbest referenced this pull request Feb 1, 2014


February 2014 Iteration #1298

5 of 5 tasks complete

SteveSanderson commented Feb 2, 2014

Thanks for this. It's great that the if/ifnot/with bindings are now able to skip the whole template-extraction-and-storage phase if it's never going to be needed! That makes with a whole lot more lightweight if you're just using it to select a non-observable subproperty of your model.

One question before merge though: why does computedContext expose the current computed? That doesn't seem to be necessary for the changes to checked or if/ifnot/with, and it's potentially risky because it means you can now do some new and unexpected things, such as attempt to read a non-deferred computed's value during its own first ever evaluation (wouldn't have been possible before). Could we drop that aspect of computedContext, or could you clarify why it's needed? Thanks!


mbest commented Feb 2, 2014

You're right. Exporting the computed object isn't needed. I've removed it.

@SteveSanderson SteveSanderson added a commit that referenced this pull request Feb 9, 2014

@SteveSanderson SteveSanderson Merge pull request #627 from knockout/627-computed-context
Provide access to dependency count within computed function

@SteveSanderson SteveSanderson merged commit 31b9df3 into master Feb 9, 2014

@SteveSanderson SteveSanderson deleted the 627-computed-context branch Feb 9, 2014

@rniemeyer rniemeyer referenced this pull request Feb 11, 2014


v3.1 Release Planning #1310

7 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment