Rework application bootstrap
The embed code has for some time been the place where our application is bootstrapped. When we did the epub.js integration, we added query parameters to the embed.js view to control which plugins were loaded by each instance of the application (a widget host for the reader frame and a slimmer guest annotator for the chapter frames). Change the injection bundle to instead include a separate bootstrap script. This has the nice benefit of ensuring that while we still use yepnope or a similar technique for script injection that our bootstrap code runs in the same global context as the application dependencies whether or not the embed script is run in a normal context or a Chrome extension content script context. The need for an inline script created by the embed code is no longer, since it is a separate script fetched from the server (it's bundled in production, inside the monolithic hypothesis-assets.js). Instead of passing the URI of the sidebar iframe by templating the bootstrap script, the embed script adds a link tag to the page with ``rel=sidebar`` and ``type=application/annotator+html``, which the bootstrap script looks for. This pattern fits nicely with the existing role of ``rel=sidebar`` in Firefox and Opera and nicely decouples the embeding and the bootstrapping. Further customization that used to take place in the query parameters is now done through ``window.hypothesisRole``, which can specify an alternate constructor, and ``window.hypothesisConfig``, which can be a function to configure the options passed to the constructor. This function will be useful for Single Sign On options, too, as laid out in #1437. The destroy script from the Chrome extension is put alongside the new bootstrap script, as they complement one another and are not extension specific.
Showing
h/static/bootstrap.js
0 → 100644
h/static/destroy.js
0 → 100644
Please register or sign in to comment