From Rajbir Kohli:
"ac.flush makes it hard to predict what parts of mojit(s) will be rendered when
on the web page. We experienced that for one of our mojits, ac.flush was
executed after ac.done in which case ac.flush was never rendered on the page.
Would be good to have an ability to allow sync or async ac.flush depending upon
See also #206.
One way to create a easily reproducible test case is to wrap a call to ac.flush
in a setTimeout, though that is somewhat artificial. The key issue here is
that, deep in the template rendering code, asynchronous template render calls
are made. It is entirely up to the ordering of those async calls whether or not
the flush makes it in or not before the callback that is linked to the ac.done
is executed. There is no counter to ensure that ac.flush calls happen before
engine decides, even though the ac.done call ends the request and returns the
buffer containing the template.
@rwaldura says: Is providing a callback (#206) sufficient to address this?
Somewhat. This makes it rather awkward for implementation as all calls to
ac.flush and ac.done must be nested to make sure that they execute in the
proper order, which can get rather unwieldy quickly with more than three or so
What may be more user-friendly would be some kind of queue that ac.done could
check to make sure there are no pending ac.flush calls. I can't think off the
top of my head of a valid reason for an ac.flush in a single request to follow
an ac.done call. Secondary to this would be to ensure that the ac.flush calls
are executed in the right order. We haven't encountered such an issue, but
given the implementation I think it is possible.
@rwaldura says: see also #408.
@imalberto @capecodehq are interested in this also.
In 0.6 we are moving toward synchronous template resolution and rendering, which means that this is not going to be a problem. I will keep this around as a reference.