Skip to content

ac.flush() does not accept a callback #206

Closed
renatoi opened this Issue Jun 14, 2012 · 6 comments

4 participants

@renatoi
renatoi commented Jun 14, 2012

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
Yahoo Inc. member
  • I think handlebar will address the async rendering part.
  • FirstByte will flush mojits as content becomes available.
@caridy
caridy commented Jan 29, 2013

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
caridy commented May 17, 2013

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
caridy commented Mar 3, 2014

closing in favor of issue #454

@caridy caridy closed this Mar 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.