This commit refactors how the search index is built. The docsSearch service
is now defined by a provider, which returns a different implementation of
the service depending upon whether the current browser supports WebWorkers
or now.
* **WebWorker supported**: The index is then built and stored in a new worker.
The service posts and receives messages to and from this worker to make
queries on the search index.
* **WebWorker no supported**: The index is built locally but with a 500ms
delay so that the initial page can render before the browser is blocked as
the index is built.
Also the way that the current app is identified has been modified so we can
slim down the js data files (pages-data.js) to again improve startup time.
Closes#9204Closes#9203
The previous solution for opening Plunkers from the docs relied on tight
coupling between the docs site and the plunkr site, in particular the
URL to the example code on the docs server was hard coded in the Plunker
site.
This change goes back to the old POST method of creating a Plunker, but
with a subtle difference: In the very old docs, the content was injected
directly into the example HTML at build time. This was easy enough to
do as the example actually ran in the current page but also increased
the size of the doc page.
The new examples are run in completely separate iframes. This new version
of showing a Plunker loads the file content for the Plunker from the
server by accessing the example's manifest.json file using $http requests.
This also has the additional benefit that you can now generate plunkers
from examples that are running locally or, frankly, in any folder on any
server, such as personal builds on the Jenkins CI server.
Closes#7186Closes#7198
Before we were simply sending the current location, but multiple URLs map
to the same document.
Now, we use the canonical path of the current document if available and
fall back to the $location path otherwise.
Includes tests!!
Closes#6402
