I then realized what the culprit was - live reload. On a whim, I stopped, and switched to just doing cordova emulate ios.
I had been using Ionic's kick ass live reload feature while testing. This is what had originally reminded me to use the sanitization setting in Angular, but I was seeing it in my non-Angular example as well. While testing, I was debugging of course, and I noticed this error in the console: Not allowed to load local resource. I then tried my basic camera demo from my Cordova examples repository - an app I had built a while ago and was as simple as possible - and that failed too! I've used the Camera numerous times before with Cordova so I assumed it must have been an Angular issue. I noticed I had the same issue.Īt this point I hit a brick wall.
Angular cli livereload not working android#
I had been testing with iOS so I quickly switched to Android and tested there. The fix for that is rather simple - just add a regex to imgSrcSanitizationWhitelist: $compileProvider.imgSrcSanitizationWhitelist(/^\s*(https?|ftp|mailto|content|file|assets-library):/) While testing, I noticed that I couldn't see an image I had selected from the gallery.Īt first, I thought it was the Angular issue (ok, they call it a feature, and I get the reasoning, but I call it a bug and I'm happy to be wrong) where the library will block you from injecting potentially dangerous stuff into the DOM. I'm working on a set of demos using Ionic and Cordova that demonstrate a particular use case of the camera. This is a pain, but it’s better than not having live reload at all.This morning I ran into an odd issue with what should have been relatively simple code. In order to start working on a different app, you’ll have to manually edit the port in your NGINX config. Unfortunately, our /sockjs-node/ NGINX proxy above will only route traffic to one of these apps - meaning you can only use the live reload with one app at a time. # proxy my-project traffic location ^~ /my-project/ Īll of these apps will attempt to use /sockjs-node/ to communicate with their respective ng serve live reload server. This step is optional if you only plan on working on a single Angular 2+ app.
Angular cli livereload not working update#
Serve your Angular 2+ app from a unique portįirst, update your Angular project’s angular.json file to ng serve on a unique port - one that isn’t already in use by another Angular app. Another Angular shield mashup icon because there's not enough on the internet already. However, it also blocks some of the traffic the ng serve feature uses to trigger the live reload feature, so your app will lose the ability to refresh itself when its source files are changed.įortunately, it’s possible to proxy this live reload traffic and regain live reload functionality. For example, say you use a local webserver like NGINX to hide your app behind a URL like This common setup allows the app to communicate with a server hosted at a different domain or port without causing cross-origin issues. Unfortunately, it’s pretty easy to break some features of this command. This command builds the app, serves it (using webpack-dev-server), and then watches for changes to source files, incrementally rebuilding and reloading the app when changes are detected. Perhaps the best feature of the CLI is the ng serve command. The CLI cleanly replaces the hodge-podge of custom gulp, grunt, or npm scripts that power the build behind every AngularJS (Angular 1) app. One of my favorite features of Angular 2+ is the Angular CLI. Tight feedback loops are one of my favorite aspects of front-end development. Not my snappiest title, but this topic is too near to my heart to obscure with puns.
0 kommentar(er)
