Closes: COREFE-302
This will actually start executing the JS as soon as it comes in
the <head> instead of waiting until after the </html> for it to start.
What this means is that for any page that is streamed, we will start
running our javascript sooner, as soon as the <head> is sent to the
browser. So we can begin executing code while the server is still
working on sending back the rest of the document.
Note: this change makes it necessary for any endpoint that is streamed
to have a check for DOMContentLoaded before doing anything that assumes
elements will be there. I added this `@instructure/ready` helper do to
that in all the places I could see. If the DOM is already loaded,
`@instructure/ready` run the callback immediately (not in a setTimeout)
so theoretically load/execution order should be _exactly_ the same for
any response that is not streamed, even if it is wrapped
in a “ready(…)” callback
QA test plan:
* click around in prod mode, especially on pages that are streamed
make sure there are no thrown javascript errors or pages that
fail to render
* try both on a fast network as well as simulating a slow network with
browser caching turned off (if you don’t know how to change your
network speed simulation settings in Chrome, I can show you)
* specifically look at pages that are streamed
(like courses/x/discussions/y, /courses, courses/x/modules)
Change-Id: I49a74ab480095e50cfa08dca8e074848dce12012
Reviewed-on: https://gerrit.instructure.com/203198
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
48c055ed0e