Deferred updates, part 2: default option

[mbest]

After reading @brianmhunt's comment on #1603, I thought of using the same API for controlling whether to use global deferred updates. But I like ko.options instead of ko.settings, so we have ko.options.deferUpdates.

Following the information I presented in #1728, this also includes a method to run pending tasks immediately. Instead of ko.tasks.runTasks, the name I had used in #1738, I decided on ko.tasks.runEarly, which I think makes its purpose more clear.

[brianmhunt]

I like both ko.tasks.runEarly and ko.options.

[IanYates]

👍 - The new naming makes the intent more clear

[SteveSanderson]

I'm not sure that runEarly should throw if one of the handlers it runs throws. This means everywhere you use runEarly, you have to put all your code in try/catch, because you have no idea whether some completely unrelated task will throw. And people can use it as a way of detecting whether or not at least one scheduled handler does throw (without telling you which handler), which encourages excessive use of runEarly, undermining the benefit.

Could we change this so runEarly doesn't throw? Throwing doesn't seem to communicate anything useful, as you have no idea what threw (and I don't think we should add a way of reporting what threw, as it would lead to really weird use cases). Then all task exceptions are definitely going to land in the same place - the onError callback (or window.onerror if you catch at that level).

[mbest]

@SteveSanderson I'm glad you brought up exception handling since it was something that I felt a bit unsure about.

The main advantage of falling out of the task loop on an exception is that the error gets reported right away in the correct context. We already have somewhat of a precedence for this because if you update an observable, it can trigger any number of manual subscriptions, computed observables, and bindings to run, and errors will both cancel the remaining updates and get thrown back to the caller (the code updating the observable).

I'm also not too concerned about the remaining tasks being rescheduled after an exception, since if using MutationObserver or onreadystatechange, it still happens before the UI is redrawn.

But, I do agree with your concerns about errors when using runEarly. At least when using runEarly, we can handle the errors asynchronously. I've seen this done before with something like this:

try {
    //...
} catch (e) {
    setTimeout(function() { throw e; }, 0);
}

[mbest]

After trying a couple of methods, I decided that the simplest and most clear way is to have all task errors deferred using setTimeout. So this should now work as you've suggested, @SteveSanderson.

[mbest]

I'm merging this now so we can move on to the next part.