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 keywords processor now also extracts the members (i.e. method, properties
and events) into its own search term property. These are then used in the lunr
search index with higher weighting that normal keywords to push services that
contain the query term as a member higher up the search results.
Closes#7661
Form previously posted to target="_blank", but pop-up blockers were causing this to not work.
If a user chose to bypass pop-up blocker one time and click the link, they would arrive at
a new default plnkr, not a plnkr with the desired template.
This fix removes the _blank target, causing the plnkr to open in the current window/tab.
When the search input box was submitted (i.e. by pressing enter) the
app was supposed to take you to the first item but this was not happening.
It turns out the app was just reading the wrong property for the path to
the item.
Closes#3078
With the minimum search length set to 3, it was not possible to search for `$q`.
Changing this to 2 fixes that without really upsetting the search display, since we
only display the first 40 API and 14 non-API items anyway.
Closes#3078
There are some files in the examples that look like JSON and the default
$http transformResponse handler was trying to convert these from strings
to object. An example was the style.css file in the
https://docs.angularjs.org/api/ng/type/ngModel.NgModelController docs.
This commit fixes this by simply removing this transform when loading
these files.
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
The "runnableExample.template.html" template overrides the one in the
dgeni-packages "examples" package with a similar template that also has
a link to a special Plunker URL that can pull in the example from our
code.angularjs.org website.
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
