Due to the recent changes ragarding the Docs app "Materialization", some
tests where failing for the following reasons:
1. JQuery wasn't being copied to 'build/docs/components/'.
2. E2E examples 89 and 90 were relying on the Bootstrap's glyphicons.
Temporarily replaced with FontAwesome icons; to be replaced with
Material Design iconfont, when ready.
3. `ngMaterial` (and its various dependencies) weren't loaded by Karma
during unit testing (causing modules depending on it to fail). Added a
fake `ngMaterial` module (as a temporary solution).
Since the structure was a little different than the prototype,
classes/styles where not applied correctly to the links in the left
sidenav. This commit fixes the issue.
I also added FontAwesome, in order to be able to display icons until the
Material Design icon-font is released. Since this is a temporary meassure,
I didn't added as a bower dependency; just added a `font-awesome` folder
in assets and added `font-awesome/css/font-awesome.css` to the stylesheets
of each deployment (under `docs/config/services/deployments/`.
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
