ac.flush() does not accept a callback

[renatoi]

Consider the following example:

ac.flush({ somethingInTheTemplate: 'Hello world!' });
ac.done('foo');

ac.flush() might take a while to render, while ac.done() is pretty fast since there's no template processing.

Template processing has an asynchronous execution and might finish after the order of the execution.

ac.done() finish its execution before ac.flush(). This problem could be solved if ac.flush() had a callback so we could add sequencial commands (AKA callback pyramid of doom).

I believe the flow is the following:

-> ac.flush()
-> lib/app/addons/ac/output-adapter.common.js::flush() // wrapper
-> lib/app/addons/ac/output-adapter.common.js::done()
-> lib/app/autoload/view-renderer.common.js::render()
-> lib/app/addons/view-engines/mu.server.js::render() // asynchronous call, callback is adapter flush()
-> lib/output-handler.server.js:: flush() // this is the final adapter for flush(). There's no callback
here. There's also no callback for the done()

Maybe ac should emit an event when the output is finished (mu.server.js::done()), so that we know that we have already flushed all the data.

This example is a real case scenario where you want to flush first byte content to improve performance (load css / js before the page rendering is complete).

http://developer.yahoo.com/performance/rules.html#flush

[rwaldura]

@imalberto how is this problem solved by FirstByte?

[rwaldura]

@zhouyaoji we should document ac.flush() is asynchronous

[imalberto]

• I think handlebar will address the async rendering part.
• FirstByte will flush mojits as content becomes available.

[caridy]

Few notes:

• Yes, with handle bars this is not an issue since internally it is a sync process, but it might be problematic for other view engines like MU.
• Yes, MU will be an alias of HB starting on 0.5.4 (PR already merged), which means we are off the hook for now.
• First byte do not helps at all with this, they are different beasts.
• Partials might help in many use cases (already introduced in 0.5.3).

The solution proposed in issue #454 sounds good.

[caridy]

We are moving toward synchronous template resolution and rendering, in which case this is not going to be an issue in 0.6.x, I will like to keep this around until we get there.

[caridy]

closing in favor of issue #454