Deferrable render

[kpdecker]

Allows view rendering to be executed in either a sync or async manner depending on the context. Generally in server side mode async is preferred to prevent blocking the event loop while in client mode sync is preferred to prevent arbitrary reflows, etc.

This attempts to normalize major components of the render pipeline to allow for both without too much chaos. This is done through the psuedo-internal deferred API, which allows for an arbitrary number of tasks to be scheduled in the manner most appropriate to the rendering context's needs.

For current listeners of the append and before:rendered events, it's not necessary to use the new deferred object that is passed as the final API argument. Any code that is executed sync in those event handlers will continue to behave as before, providing they do not have dependencies on code that is running in a deferred task.

Breaking changes:

• setView callers can not assume that the operation has completed after the call returns unless they pass the async: false flag.
• rendered:collection now occurs prior to the rendered event
• append and before:rendered events can not assume that other handlers have executed prior to their own execution unless they utilize the deferred.exec API which does guarantee this case (although the existing concerns of did you register before the other guy hold and this is generally ill advised to make these assumptions in loosely linked event code).

[kpdecker]

One update on the performance impact of this when running ab against the same url on my local machine, concurrency of 10: Merged: Max response time 570ms, concurrent API response times varied between 2ms and 3ms Without: Max response time 1086ms, concurrent API response times varied between 2ms and 300ms

[candid82]

I made a few comment regarding the implementation, but the general feeling is that this is extremely complex. I looked at this code last night, and this morning, and I don't think I fully understand the way it works. Thorax is already quite complex, and this stuff makes it even harder to understand. I am afraid this will limit the number of people who are able to or willing to maintain / contribute to the project.

[kpdecker]

@Candid yes this adds complexity but the added value is worth it. Regarding contributors we don't have much community involvement as it is. I'd love it if we had more, but that should not prevent us from making the changes that we need to to support the end product.

[kpdecker]

Released in 3.0.0-beta.4

[jherr]

What is the QA impact on this? What do we need to re-test in us-mweb?