ORIGINAL EXCEPTION: Error: not implemented
ORIGINAL STACKTRACE:
Error: not implemented
at NativeScriptDomAdapter.Parse5DomAdapter.getCookie (/data/data/org.nativescript.nativescriptweather/files/app/tns_modules/@angular/platform-server/src/parse5_adapter.js:612:68)
Fixed by https://github.com/NativeScript/nativescript-angular/pull/286
PR merged
Btw, the quick and dirty workaround until the fix is live is to add the not implemented method(somehere in the main.ts):
// HACK - patch dom adapter
import {Parse5DomAdapter} from '@angular/platform-server/src/parse5_adapter';
(<any>Parse5DomAdapter).prototype.getCookie = function (name) { return null; };
Is it fixed yet?
Yes - version 0.2.0 has the fix
This is odd, are you sure this is fixed? This is what I did to confirm.
nativescript$ npm install -g nativescript
$ tns --version
2.1.0
$ tns create foobar --ng
$ cd foobar
app.component.ts with this pieceimport {Component} from "@angular/core";
import {HTTP_PROVIDERS, Http, Headers} from "@angular/http";
import {Observable} from "rxjs/Rx";
@Component({
selector: "my-app",
templateUrl: "app.component.html",
providers: [HTTP_PROVIDERS]
})
export class AppComponent {
constructor(private _http: Http) {
}
public onTap() {
this.createUser()
.subscribe(
() => alert('Your account was successfully created.'),
() => alert('Unfortunately we were unable to create your account.')
);
}
private createUser() {
const headers = new Headers();
headers.append("Content-Type", "application/json");
const body = JSON.stringify({
Username: '[email protected]',
Email: '[email protected]',
Password: 'foobar'
});
return this._http.post('https://api.everlive.com/v1/GWfRtXi1Lwt4jcqK/Users', body, {headers}).catch(this.handleErrors);
}
handleErrors(error: Response) {
console.log(JSON.stringify(error.json()));
return Observable.throw(error);
}
}
$ tns platform add ios
$ tns run ios --emulator
TAP buttonBy adding the "hack", it works. The nativescript-angular version is 0.2.0.
Confirmed - I'm still getting the crash. Reopening for investigation.
OK, some updates:
The fix form @NathanWalker if you pass HTTP_PROVIDERS in the nativeScriptBootstrap function. It provides a custom NSXSRFStrategy that does not use cookies - so no crash.
However, if you add HTTP_PROVIDERS at component level (as in the @SamVerschueren's example) the built-in angular XSRFStrategy is used. It depends on cookies and causes the crash. The "load local files" goodies form #249 will also not work in this case.
For now: You can just add HTTP_PROVIDERS in the bootstrap and everything should work fine.
General Fix Proposal: Export NS_HTTP_PROVIDERS that can be provided at component level and provide the right XHR related dependencies.
@vakrilov working up PR to handle this now. Curious your opinion:
Should we still auto push in NS_HTTP_PROVIDERS in appProviders or should we just document that the user should instead import those and use them instead of HTTP_PROVIDERS? I could go either way.
@samarthagarwal @SamVerschueren Final fix is here: https://github.com/NativeScript/nativescript-angular/pull/321
Once that lands, you can use this guide: https://github.com/NativeScript/nativescript-angular/wiki/Http
:+1:
I'm not familiar with the {N} core or the technical implementation whatsoever, but is it technically not possible to patch the @angular/http HTTP_PROVIDERS to just work without introducing NS_HTTP_PROVIDERS?
I'm not familiar with the {N} core or the technical implementation whatsoever, but is it technically not possible to patch the @angular/http HTTP_PROVIDERS to just work without introducing NS_HTTP_PROVIDERS?
Agreed here, and I think this is going to confuse a fair number of people, especially considering the error message doesn鈥檛 point you in the right direction at all.
If this is indeed a necessity, is there anything we can do to point people in the right direction when they use HTTP_PROVIDERS at the component level?
cc @NathanWalker @vakrilov
Agree - making HTTP_PROVIDERS just work would be the easiest option to use.
However, I don't see how this can be done, because of the way HTTP_PROVIDERS are defined. The XSRFStrategy is the thing that we want to override but because it is defined inside the HTTP_PROVIDERS if you want to tell the DI to use another strategy - you should do it after including HTTP_PROVIDERS. That's how its done in the NS_HTTP_PROVIDERS.
One more argument for the NS_HTTP_PROVIDERS is that we actually provide extended Http implementation - more on that #286.
I hit this after upgrading from 0.2.0 to 0.3.0. I've always been bootstrapping with HTTP_PROVIDERS. Switching to NS_HTTP_PROVIDERS fixed the issue.
Most helpful comment
Btw, the quick and dirty workaround until the fix is live is to add the not implemented method(somehere in the
main.ts):