feat(aio): add API list page #14899

wardbell · 2017-03-03T10:53:34Z

Add API page based on page and directive in angular.io v.1

Preliminary conversion ready for review. Needs:

unit and e2e tests.
decision about how to handle the ton of SCSS in api-list.component.scss [POSTPONED]
decision/confirmation on how to create/generate api.html (currently in content/marketing ... feels wrong).[for @petebacondarwin]
confirmation that component should be in the embedded folder

Please check if the PR fulfills these requirements

The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x")

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

petebacondarwin · 2017-03-04T08:13:59Z

aio/src/app/documents/document.service.ts

@@ -28,6 +28,7 @@ export class DocumentService {

  private getDocument(url: string) {
    this.logger.log('getting document', url);
+    url = url.match(/[^#?]*/)[0]; // strip off fragment and query


perhaps we ought to move the call to computePath here and then put this stripping logic inside compute path.

SGTM. I'm just trying to get it to work for now.

In my current PR I have done this refactoring move, so if you rebase then you could easily add this line into computePath now.

petebacondarwin · 2017-03-04T08:44:33Z

aio/src/app/shared/api.service.ts

+  private apiBase = 'content/docs/api/';
+  private apiListJsonDefault = 'api-list.json';
+  private onDestroy: Subscription;
+  private sectionsSubject = new ReplaySubject<ApiSection[]>(1);


I think an AsyncSubject is simpler here.

See my response in the next comment

petebacondarwin · 2017-03-04T08:48:51Z

aio/src/app/shared/api.service.ts

+        .subscribe(sections => this.logger.log('ApiService got API sections') );
+      this.fetchSections();
+    }
+    return this.sectionsSubject.asObservable();


If we changed fetchSections() to return a cold observable, then in here we lazily subscribe the sectionsSubject to this cold observable, then I think we would have what we need with fewer lines. Something like:

get sections(): Observable<ApiSection[]> { if (!this.sectionsSubject) { this.sectionsSubject = new AsyncSubject(); this.onDestroy = this.fetchSections().subject(this.sectionsSubject); } return sectionsSubject.asObservable(); }

I think you misunderstand the purpose of fetchSections which deliberately returns void.

It's job is to get the sections, either the first time or (if we need it to) on a refresh. It would handle retry, etc. if that became necessary. Then it pumps the result into the sections observable by way of the sectionsSubject. It is intrinsically "hot". It is not subcribeable.

If you rewrite as you've written (which is how I started), you cannot refresh. There's nothing to call that would pump a refreshed value into the subject.

If we don't want the refresh potential, then we don't need a subject of any kind. We just call this.fetchSections().publishReplay (which I also did in an earlier version).

See Ben Lesh's proposed shareReplay operator for another confirmation of my choice of ReplaySubject: ReactiveX/rxjs#2443

FWIW, the choice of AsyncSubject over ReplaySubject would be irrelevant (or possibly wrong) because the http within fetchSections calls complete.

TBH, this was oh-so-much-simpler in my first promise-based implementation that didn't care about refresh or observables. I almost went that way before deciding that, if we're going Observable somewhere, we might as well stick with it everywhere.

petebacondarwin · 2017-03-04T08:49:34Z

aio/src/app/shared/api.service.ts

+        });
+      })
+      .do(() => this.logger.log(`Got API sections from ${url}`))
+      .subscribe(


By doing the subscription in the sections getter we could avoid this subscription code here.

See earlier comment about the role of fetchSections in a "refresh" scenario. I've confirmed that it works as intended by wiring a "Refresh" button to the component.

Maybe this is all YAGNI. But if it is, I don't really know why we're bothering with an Observable at all. This is a one-and-done operation.

I have the same quandry w/r/t navigation JSON

petebacondarwin · 2017-03-04T08:50:28Z

aio/src/app/shared/api.service.ts

+        }
+      );
+
+    function normalizeItem(item: ApiItem) {


Let's modify dgeni to produce output that is already normalized for our purposes.
It is doing loads of manipulation there so we might as well make it produce what we want

SGTM. I hoped that would be your response. This was a shim to get me from an existing api.json (which I still tweaked to correct the paths) to a working example.

We can fix this in a subsequent dgeni PR, yes?

petebacondarwin · 2017-03-04T08:52:18Z

aio/src/app/shared/api.service.ts

+
+  private apiBase = 'content/docs/api/';
+  private apiListJsonDefault = 'api-list.json';
+  private onDestroy: Subscription;


Is this conventional? I would have expected to give this subscription a name that refers to the thing it is subscribed to. E.g. sectionsSubscription

It is conventional. It's an Alex R. pattern for Components that allows us to have ONE something to destroy and the name conveys its purpose.

In the Component pattern, it's actually a subject. You attach it to every observable with takeUntil(onDestroy). Then call onDestroy.next() in ngOnDestroy and they're all cancelled.

I just took a short-cut here but kept the name to convey intent rather than implementation.

petebacondarwin · 2017-03-04T08:52:55Z

aio/src/app/shared/api.service.ts

+import 'rxjs/add/operator/catch';
+import 'rxjs/add/operator/do';
+import 'rxjs/add/operator/map';
+import 'rxjs/add/operator/publishReplay';


Yes, catch moved into the second callback in subscribe and publishReplay was from an earlier, pre-refresh implementation. The do and map are still needed.

petebacondarwin · 2017-03-04T08:53:47Z

aio/src/app/embedded/api/api-list.component.ts

+    if (this.status.name !== 'all') { addParm('status', this.status.name); }
+    if (this.type.name !== 'all') { addParm('type', this.type.name); }
+
+    window.history.replaceState({}, 'API Search', window.location.pathname + params);


I think that we should move something like this into the LocationService.

I thought about that. You mentioned wanting to do something along these lines for search as well. I decided to keep this PR focused and get it to work. We can refactor later when we know what we want.

petebacondarwin · 2017-03-04T08:57:40Z

aio/src/app/embedded/api/api-list.component.ts

+    const {query, status, type} = search;
+    this.query = query || '';
+    // Hack: can't bind to query because input cursor always forced to end-of-line.
+    this.queryEl.nativeElement.value = this.query;


So if someone types into the search query box, it updates the browser address, which in turn updates the value of the query box.
Could we optimise it so that we don't update the query box if the URL query is the same?

@wardbell This bit here is my biggest concern of the overall architecture of this PR.

if someone types into the search query box, it updates the browser address, which in turn updates the value of the query box.

I don't think that's true. Updating the address has no effect on the query box. Notice that <input> 's value is not bound. I had to remove the binding and substitute ViewChild('filter') to prevent the unwanted cursor behavior (thus the hack).

I didn't love this either. But I couldn't find another, easier way. We don't have an obvious equivalent in Angular to "bind once", AFAIK

DzmitryShylovich · 2017-03-04T08:59:03Z

aio/src/app/embedded/api/api-list.component.ts

+
+    window.history.replaceState({}, 'API Search', window.location.pathname + params);
+
+    function addParm(key: string, value: string) {


petebacondarwin

Looking good @wardbell.
I added some minor comments about observables and where things should live.
Mostly it would be good to see some tests in here :-)

gkalpak · 2017-03-04T08:32:42Z

aio/src/app/shared/location.service.ts

+        const params = path.substr(q + 1).split('&');
+        params.forEach(p => {
+          const pair = p.split('=');
+          search[pair[0]] = pair[1];


Do we need decodeUriComponent here?

See my request to you for help on this (above)

For decoding, it would be:

-search[pair[0]] = pair[1]; +search[pair[0]] = decodeURIComponent(pair[1]);

_{Not sure if/how this is affected in non-browser environments.}

gkalpak · 2017-03-04T08:40:59Z

aio/src/app/shared/api.service.ts

+
+  ngOnDestroy() {
+    if (this.onDestroy) {
+      this.onDestroy.unsubscribe();


I wonder what happens if this gets called while an http request is in flight.

the request will be aborted

OOC, how does Http know?

https://github.com/angular/angular/blob/master/modules/%40angular/http/src/backends/xhr_backend.ts#L148

That is the beauty of Observable over Promise

But who tells XHRConnection that it needs to abort?

When you unsubscribe from an observable, it calls a function to destroy the observable, with is https://github.com/angular/angular/blob/master/modules/%40angular/http/src/backends/xhr_backend.ts#L145-L148 in this case.

Yes, but who unsubscribes from the observable returned by http.get(url)... (subscribed here)?

@gkalpak You are correct that nothing abort the fetch call. The onDestroy only unsubscribes the subscribers to the sections Observable. The only subscriber to the http call is the service itself.

This isn't a practical problem because this service is never torn down and so the whole thing is moot. But I was trying to be good and prepare for a change of heart in the future (YAGNI!).

If I'm going to do it, I should do it right. So, in the interest of science, I will redo it properly, using the Alex R. pattern with onDestroy and takeUntil.

Tests would help, eh? Those are next after the update.

gkalpak · 2017-03-04T08:44:29Z

aio/src/app/shared/api.service.ts

+  private apiBase = 'content/docs/api/';
+  private apiListJsonDefault = 'api-list.json';
+  private onDestroy: Subscription;
+  private sectionsSubject = new ReplaySubject<ApiSection[]>(1);


Why not BehaviorSubject?

BehaviorSubject starts with an initial value, which is not what we want. The first (and only) value in the stream should be the response. (Which is also why I think we should use AsyncSubject)

@petebacondarwin Is correct about why not BehaviorSubject. See my reason for using ReplaySubject instead of AsyncSubject.

gkalpak · 2017-03-04T08:49:19Z

aio/src/app/shared/api.service.ts

+    function normalizeItem(item: ApiItem) {
+      item.name = item.title.toLowerCase();
+      // convert 'secure' property to boolean `securityRisk`
+      item.securityRisk =  item.secure !== 'false';


I don't know the semantics of secure and securityRisk, but mapping secure: 'false' to securityRisk: false seems counter-intuitive.

This is a shim. I took the api.json as given and made the best of it. @petebacondarwin will cure in dgeni in a future PR. IMO, the JSON property should be securityRisk and should be true if it is a security risk.

Curiously, the data for security in the current JSON is either "false" or some lengthy explanatory string that we don't show anywhere. Maybe @petebacondarwin can explain.

I can't remember, but that stuff was always a bit of a WIP anyway. We can tidy it all up now.

gkalpak · 2017-03-04T08:51:17Z

aio/src/app/shared/api.service.ts

+import 'rxjs/add/operator/catch';
+import 'rxjs/add/operator/do';
+import 'rxjs/add/operator/map';
+import 'rxjs/add/operator/publishReplay';


Is this necessary?

gkalpak · 2017-03-04T08:51:30Z

aio/src/app/shared/api.service.ts

+import { Observable } from 'rxjs/Observable';
+import { ReplaySubject } from 'rxjs/ReplaySubject';
+import { Subscription } from 'rxjs/Subscription';
+import 'rxjs/add/operator/catch';


Is this necessary

it appears not. I suspect that originally @wardbell was using it but then switched to the subscribe below with a traditional try-catch block

Observable is only necessary because of explicit return type on get sections(), a habit I got into for our docs. I'll remove.

ReplaySubject and Subscription are used.

do and map are used.

catch and publishReplay will be removed.

gkalpak · 2017-03-04T08:52:19Z

aio/src/app/embedded/api/api-list.component.ts

+/*
+* API List & Filter Component
+*
+* A page displaying all of the angular API methods available


Is this really about just methods?

Updated comment

gkalpak · 2017-03-04T09:03:40Z

aio/src/app/embedded/api/api-list.component.ts

+
+  // Get filter values from search params on the URL
+  private getFilterValues() {
+    const search = this.locationService.search();


Do we need the intermediate search variable.

apparently not but not a blocker :-)

gkalpak · 2017-03-04T09:08:40Z

aio/src/app/embedded/api/api-list.component.ts

+    window.history.replaceState({}, 'API Search', window.location.pathname + params);
+
+    function addParm(key: string, value: string) {
+      params += (params ? '&' : '?') + `${key}=${value}`;


Not likely to bite us, but encodeUriComponent would be safer.

I wanted to do that but wasn't sure exactly how to apply it and how to decode it in getFilterSection. Would you please supply the correct code?

petebacondarwin · 2017-03-04T09:57:05Z

aio/src/app/shared/api.service.ts

+  get sections(): Observable<ApiSection[]> {
+    if (this.firstTime) {
+      this.firstTime = false;
+      // makes sectionsSubject hot; subscribe ensures stays alive (always refCount > 0);


This makes me realise that the NavigationService is returning the http observable for the navigationViews property. I wonder if it is triggering the request twice for the two different menus (SideNav and TopBar)?

Yes it is!! I will fix that.

Fixed in #14924

the DocumentService also had this problem. Fixed in #14924

petebacondarwin

I think this is good enough to get us moving.

It should be followed up with a series of PRs to:

add tests
change dgeni to produce nicer api.json output
use PlatformLocation.search
move the fragment stripping to the computePath function

petebacondarwin · 2017-03-05T22:06:37Z

aio/src/app/shared/api.service.ts

+        }
+      );
+
+    function normalizeItem(item: ApiItem) {


petebacondarwin · 2017-03-05T22:07:43Z

aio/src/app/shared/api.service.ts

+    function normalizeItem(item: ApiItem) {
+      item.name = item.title.toLowerCase();
+      // convert 'secure' property to boolean `securityRisk`
+      item.securityRisk =  item.secure !== 'false';


I can't remember, but that stuff was always a bit of a WIP anyway. We can tidy it all up now.

petebacondarwin · 2017-03-05T22:13:47Z

aio/src/app/shared/location.service.ts

  go(url: string) {
    url = this.location.normalize(url);
    this.location.go(url);
    this.urlSubject.next(url);
  }
+
+  search(): { [index: string]: string; } {


Could we just delegate to PlatformLocation.search() here rather than coding it ourselves?
That would save the hassle of decoding the url components.

https://github.com/angular/angular/blob/2.4.8/modules/%40angular/common/src/location/platform_location.ts#L42

gkalpak · 2017-03-06T09:16:04Z

aio/src/app/embedded/api/api-list.component.ts

+    window.history.replaceState({}, 'API Search', window.location.pathname + params);
+
+    function addParam(key: string, value: string) {
+      params += (params ? '&' : '?') + `${key}=${value}`;


WRT encoding URI component, here is what I had in mind:

-params += (params ? '&' : '?') + `${key}=${value}`; +params += (params ? '&' : '?') + `${key}=${window.encodeURIComponent(value)}`;

AFAICT, this is only relevant if status.name or type.name contain characters that have different meaning when appended to the pathname. E.g. if .name contains & or #.

gkalpak · 2017-03-06T09:18:55Z

aio/src/app/shared/api.service.ts

+import 'rxjs/add/operator/map';
+import 'rxjs/add/operator/takeUntil';
+
+import { Logger } from 'app/shared/logger.service';


I think we need a convention about naming services: Do or don't suffix with Service?
Currently, most of our services have the suffix (e.g. ApiService, LocationService, NavigationService, etc). Logger doesn't. Nor do the build-in services.

What does the style guide suggest?

The CLI tool is defaulting to postfixing when you use ng g service ....
I suspect that @wardbell will say that he doesn't like that default.

The style guide encourages the Service suffix but does NOT mandate it. I states explicitly that if the name of the class is obviously a service, you can omit it. Logger is the example given ;-)

gkalpak · 2017-03-06T09:31:23Z

aio/src/app/shared/location.service.ts

+        const params = path.substr(q + 1).split('&');
+        params.forEach(p => {
+          const pair = p.split('=');
+          search[pair[0]] = pair[1];


For decoding, it would be:

-search[pair[0]] = pair[1]; +search[pair[0]] = decodeURIComponent(pair[1]);

_{Not sure if/how this is affected in non-browser environments.}

petebacondarwin · 2017-03-06T15:46:51Z

aio/src/app/shared/api.service.ts

+import 'rxjs/add/operator/map';
+import 'rxjs/add/operator/takeUntil';
+
+import { Logger } from 'app/shared/logger.service';


The CLI tool is defaulting to postfixing when you use ng g service ....
I suspect that @wardbell will say that he doesn't like that default.

petebacondarwin · 2017-03-06T15:48:33Z

aio/src/app/embedded/api/api-list.component.ts

+      (status === 'security-risk' && item.securityRisk);
+  };
+
+  private setLocationSearch() {


A large part of this function needs to be moved into the Location service. We should not be hitting window.history in a component.

Again I think that judicious use of PlatformLocation might make this a lot cleaner.

PlatformLocation doesn't do much but the window.history part does need to move and has been moved in the latest version of this PR.

petebacondarwin · 2017-03-06T15:53:54Z

aio/src/app/embedded/api/api-list.component.ts

+
+    this.apiService.sections.subscribe(sections => {
+      this.sections = sections;
+      this.applyFilters();


Was it a conscious decision to avoid the Observable world in this component?

I imagine that Mr Lesh would be saying that updates to the filters are actually observable sequences that should be combined together with the observable sequence of the sections, resulting in a stream of filtered sections.

OK ... we had hours of "fun" making this observable. The code became more obscure without being shorter but the gods of reactive purity have been placated.

petebacondarwin · 2017-03-06T16:16:14Z

aio/src/app/embedded/api/api-list.component.ts

+*/
+
+import { Component, ElementRef, OnInit, ViewChild } from '@angular/core';
+import { LocationService } from '../../shared/location.service';


we don't need to use relative imports like this. The webpack setup has aliases such as app. So these can be

import { LocationService } from 'app/shared/location.service';

Didn't know that. Fixed.

petebacondarwin · 2017-03-06T16:17:10Z

aio/src/app/embedded/api/api-list.component.ts

+
+import { Component, ElementRef, OnInit, ViewChild } from '@angular/core';
+import { LocationService } from '../../shared/location.service';
+import { ApiItem, ApiSection, ApiService } from '../../shared/api.service';


Why is the API service stored in the shared folder?
Given that we have folders for navigation, documents and search, then I would expect it either to have a folder of its own, or to appear in the navigation folder.

I don't think it belongs here either. I thought I was following the lead of other services here.

Originally it was in .../api/ which is the only thing that needs it.

I'll move it back there until we have a compelling reason to do otherwise.

mary-poppins · 2017-03-08T08:48:41Z

The angular.io preview for 76cd1ca is available here.

wardbell

I think I've responded favorably to this round of comments.

wardbell · 2017-03-08T03:17:12Z

aio/src/app/embedded/api/api-list.component.ts

+*/
+
+import { Component, ElementRef, OnInit, ViewChild } from '@angular/core';
+import { LocationService } from '../../shared/location.service';


Didn't know that. Fixed.

wardbell · 2017-03-08T03:17:17Z

aio/src/app/embedded/api/api-list.component.ts

+
+import { Component, ElementRef, OnInit, ViewChild } from '@angular/core';
+import { LocationService } from '../../shared/location.service';
+import { ApiItem, ApiSection, ApiService } from '../../shared/api.service';


I don't think it belongs here either. I thought I was following the lead of other services here.

Originally it was in .../api/ which is the only thing that needs it.

I'll move it back there until we have a compelling reason to do otherwise.

wardbell · 2017-03-08T07:10:04Z

aio/src/app/shared/api.service.ts

+import 'rxjs/add/operator/map';
+import 'rxjs/add/operator/takeUntil';
+
+import { Logger } from 'app/shared/logger.service';


The style guide encourages the Service suffix but does NOT mandate it. I states explicitly that if the name of the class is obviously a service, you can omit it. Logger is the example given ;-)

wardbell · 2017-03-08T08:39:07Z

aio/src/app/embedded/api/api-list.component.ts

+      (status === 'security-risk' && item.securityRisk);
+  };
+
+  private setLocationSearch() {


PlatformLocation doesn't do much but the window.history part does need to move and has been moved in the latest version of this PR.

wardbell · 2017-03-08T08:40:19Z

aio/src/app/embedded/api/api-list.component.ts

+
+    this.apiService.sections.subscribe(sections => {
+      this.sections = sections;
+      this.applyFilters();


OK ... we had hours of "fun" making this observable. The code became more obscure without being shorter but the gods of reactive purity have been placated.

wardbell · 2017-03-08T08:42:03Z

aio/src/app/shared/location.service.ts

+
+  // TODO: Could we just delegate to PlatformLocation.search() here rather than coding it ourselves?
+  // That would save the hassle of decoding the url components.
+  search(): { [index: string]: string; } {


PlatformLocation.search returns the query string. It takes an import and an injection to get it here where it saves exactly two lines. I decided against doing that.

mary-poppins · 2017-03-08T09:36:40Z

The angular.io preview for b631b8b is available here.

petebacondarwin · 2017-03-08T16:24:56Z

aio/src/app/shared/location.service.ts

@@ -20,6 +20,7 @@ export class LocationService {
    });
  }

+  // TODO?: ignore if url-without-hash-or-search matches current location?


Since the DocService strips off the query and hash, it will not emit a new doc url unnecessarily.
So I think we can safely leave them on here at this point - in case some other service does care about these things.
(i.e. you can remove this comment :-) )

petebacondarwin · 2017-03-08T16:25:33Z

LGTM - please squash and then add the merge label so the caretaker can pick it up.

petebacondarwin · 2017-03-08T19:43:19Z

aio/src/app/embedded/api/api-list.component.ts

+  // Todo: may need to debounce as the original did
+  // although there shouldn't be any perf consequences if we don't
+  setQuery(query: string) {
+    this.setSearchCriteria({query: (query || '').toLowerCase().trim() });


I thought it was a bug that we were not searching case insensitive but I see here now that we are lowercasing what is typed. So no bug :-)
Of course you would have had a test that checked this and then I would have known that it was covered.

mary-poppins · 2017-03-08T20:12:51Z

The angular.io preview for e6f9208 is available here.

mary-poppins · 2017-03-08T20:15:55Z

The angular.io preview for adf22be is available here.

angular-automatic-lock-bot · 2019-09-11T00:20:45Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

wardbell added the comp: aio label Mar 3, 2017

wardbell self-assigned this Mar 3, 2017

googlebot added the cla: yes label Mar 3, 2017

wardbell force-pushed the aio-add-api-list branch 6 times, most recently from f95eb41 to b1627ff Compare March 4, 2017 01:38

wardbell changed the title ~~[WIP] feat(aio): add API list page~~ feat(aio): add API list page Mar 4, 2017

wardbell requested a review from petebacondarwin March 4, 2017 01:42

wardbell force-pushed the aio-add-api-list branch 3 times, most recently from 23bfe64 to 5ff2d81 Compare March 4, 2017 03:46

petebacondarwin reviewed Mar 4, 2017

View reviewed changes

DzmitryShylovich reviewed Mar 4, 2017

View reviewed changes

petebacondarwin reviewed Mar 4, 2017

View reviewed changes

gkalpak reviewed Mar 4, 2017

View reviewed changes

petebacondarwin reviewed Mar 4, 2017

View reviewed changes

wardbell force-pushed the aio-add-api-list branch 3 times, most recently from c4ed9c2 to 8b2c23f Compare March 5, 2017 21:35

wardbell force-pushed the aio-add-api-list branch 2 times, most recently from aa58453 to a3fad3c Compare March 5, 2017 21:39

petebacondarwin approved these changes Mar 5, 2017

View reviewed changes

gkalpak reviewed Mar 6, 2017

View reviewed changes

petebacondarwin reviewed Mar 6, 2017

View reviewed changes

wardbell force-pushed the aio-add-api-list branch from 2f9d27a to 4e65b0a Compare March 8, 2017 03:09

wardbell force-pushed the aio-add-api-list branch from 76cd1ca to 08cad6a Compare March 8, 2017 09:20

wardbell commented Mar 8, 2017

View reviewed changes

wardbell force-pushed the aio-add-api-list branch 2 times, most recently from b631b8b to e6f9208 Compare March 8, 2017 09:28

wardbell mentioned this pull request Mar 8, 2017

aio: migrate API page from aio v.1 #14886

Closed

petebacondarwin reviewed Mar 8, 2017

View reviewed changes

feat(aio): add API list page

adf22be

wardbell force-pushed the aio-add-api-list branch from e6f9208 to adf22be Compare March 8, 2017 20:07

chuckjaz merged commit 5ad5301 into angular:master Mar 8, 2017

wardbell deleted the aio-add-api-list branch March 8, 2017 22:08

wardbell mentioned this pull request Mar 14, 2017

test(aio): fill in missing API page unit tests #15133

Merged

2 tasks

asnowwolf pushed a commit to asnowwolf/angular that referenced this pull request Aug 11, 2017

feat(aio): add API list page (angular#14899)

32642b8

juleskremer pushed a commit to juleskremer/angular that referenced this pull request Aug 28, 2017

feat(aio): add API list page (angular#14899)

57f2f86

angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 11, 2019


		window.history.replaceState({}, 'API Search', window.location.pathname + params);

		function addParm(key: string, value: string) {

feat(aio): add API list page #14899

feat(aio): add API list page #14899

Uh oh!

Conversation

wardbell commented Mar 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wardbell Mar 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wardbell Mar 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wardbell Mar 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petebacondarwin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wardbell commented Mar 3, 2017 •

edited

Loading

wardbell Mar 5, 2017 •

edited

Loading

wardbell Mar 5, 2017 •

edited

Loading

wardbell Mar 5, 2017 •

edited

Loading

petebacondarwin Mar 4, 2017 •

edited

Loading

wardbell Mar 5, 2017 •

edited

Loading