FastBoot and waiting for additional asynchronous content

Summary

There are times that you’d want ember to load data asynchronously in the browser. This changes when in FastBoot, you have a single pass before the response is sent back to the browser, and there is no updating the source once the response is sent when it comes to crawlers. Some content you may want index may be loading asynchronously in the Ember app, but needs to be there for crawlers

FastBootInfo.deferRendering(promise)

By adding a method to chain promises to the FastBoot service, we can allow the user to notify FastBoot which promises this page depends on before rendering. The server would then wait for this promise to resolve after hitting the visit method of the app, so that all the routes/components/etc could notify the server. This would be an explicit call to fastboot.deferRendering.

Additional consideration

Should this be done for all ember-data calls automatically in FastBoot-land. There is an argument in both directions. This would ensure that all ember-data calls are completed before rendering the page, which would cover the majority of use cases for the typical user. Instead of having to check to see if we are in FastBoot and then explicitly call deferRendering, we could hook into ember-data to do this automatically.

Instead of hooking into ember data, we could provide an additional hook to the route, akin to a fastBootModel which will be expected to return a promise that should block the rendering of the page until.

Drawbacks from ember-data and hooks approaches

Both the ember-data approach and fastBootModel hook approach would prevent the user from doing their own checks of whether or not they are in FastBoot and handle that case appropriately, but bring in addition work. And there may be cases in the ember-data approach that you would not want to wait for every ember-data operation to resolve before allowing FastBoot to return the response.

/cc @tomdale @ef4

[markmhx]

@courthead Good question, and I think the short answer is Shoebox: https://github.com/ember-fastboot/ember-cli-fastboot#the-shoebox

After implementing deferredRendering with my components, I started experiencing the redrawing problem you describe with my site. I need to try implementing Shoebox to know for sure, but I think with a standard implementation, it should prevent the reloading of data and subsequent redrawing.

[markmhx]

In case anyone finds this thread through search and is looking for a similar solution, @kratiahuja pointed me toward the deferRendering method on the FastBoot service.

The following is an example of how to use it to accomplish the above (thanks @danmcclain!):

https://github.com/ember-fastboot/ember-cli-fastboot/blob/2e913eb907d3a8aa2b64d87b2877704a365fa6bf/test/fixtures/async-content/app/components/async-content.js