Background, have an app built originally with angularjs, it's now a angularjs/ angular hybrid using the UpgradeModule. There's been kind of an ongoing problem with falling out of the angular zone and ending up in the <root> zone. Have hit on a fairly repeatable example.
Have hit a rather frequently re-occuring problem of getting stuck in the <root> zone and it's been distilled down to this.
So, 3 methods of creating promises, all starting in the angular zone.
new Promise(blahblah)
returns ZoneAwarePromise
new $q(blahblah)
returns Promise
let def = $q.defer(); return def.promise
returns Promise
So, this looks to me like $q promises are not getting patched with zone and so the angular zone is not being maintained and callbacks end up in <root>. Which results in things on the angular half being quite slow (once this has occurred) and occasional digest errors when something runs an apply/ digest in the callback of a promise from some sort of remote request. Common culprits are $http and callbacks from the angularfire library, etc.
So...put simply, is the UpgradeModule intended to patch angularjs promises ($q) as ZoneAwarePromise's? It's what I would have expected.
EDIT: Here is a more barebones example on StackBlitz. This example is showing the same as in my app: The UpgradeModule does not patch $q promises: https://stackblitz.com/edit/github-fwbk4x?file=src%2Fapp%2Fhome%2Fapp.component.ts
Related
TypeScript constantly suggests that I change my AngularJS service code to async/await functions.
My understanding is that using the await keyword is totally fine with third-party promises, since it is just syntax sugar for calling then. However, I normally return Angular promises because they are necessary to play nicely with the digest cycle.
This code gives me an error because async functions wrap their contents in an ES6 promise. Will this matter for Angular scheduling, given that the returned promise is still hooked up to an Angular-spawned promise? Or should I submit an issue to TypeScript for suggesting async/await when functions do not explicitly return an ES6 promise?
For anyone viewing this in the future. It does not play nicely. async functions wrap their contents in a global ES6 promise, so if you await AngularJS promises within the changes will eventually hit, but scheduling is weird when you chain together $q promises and ES6 promises, so there will usually be an artificial delay before changes are reflected in the DOM.
On the other hand, Angular 2+ monkey-patches DOM event sources and promises, so async-await should work as expected with newer versions.
I had a use-case where I wanted to make the session timeout of the application configurable by making a call to REST api and get the value using $http. But as I found in this link how to inject dependency into module.config(configFn) in angular that services cannot be injected in config method, I have found this solution to make this work in the config:
var $http = angular.injector(['ng']).get('$http');
This is working fine, what is the difference between the two approaches and why this is working ? Also is there any limitation of using this approach.
angular.injector creates a new injector (application instance). It is misused most times and rarely ever needed in production.
It will have its own $http, $rootScope, $q, etc instances:
angular.injector(['ng']).get('$http') !== angular.injector(['ng']).get('$http');
The use of angular.injector in config block is an antipattern. It will result in untestable and potentially buggy code. $http request is asynchronous, application initialization will be completed first and likely result in race condition.
Most times when a need for $http in config appears, it should be performed in route resolver. If the response contains information that should be used to configure service providers and should be available in config block, it should be fetched prior to application bootstrap - in fact, there should be two applications, as shown here.
I cannot get the Breeze Angular service (http://www.getbreezenow.com/documentation/breeze-angular) to configure Breeze to use Angular promises, i.e., I can never get the useNgPromises() function within breeze.bridge.angular.js to log a message to the console and thus I assume Breeze is never configured to use Angular promises.
My JS files are loaded as follows:
angular.js (v 1.3.14)
angular-route.js (v.1.3.14)
q.js (v 1.1.2) - This is here because I kept getting errors that Q was undefined if I left this out. I don't know if it is necessary to load Q.js if I use Angular promises instead.
breeze.js (v 1.5.3)
breeze.bridge.angular.js (v 1.1.0)
app.js and other app-specific JS files
So far, that satisfies steps #1 and #2 from the "Install It" section of that Breeze page.
Per steps #3 and #4 on that Breeze page and comments in breeze.bridge.angular.js, this is what my app.js looks like:
window.myApp = angular.module("myApp", [
"breeze.angular"
])
.value("breeze", window.breeze)
.config(["$routeProvider", function ($routeProvider) {
// Routing code
}])
.run(['breeze', function (breeze) {}]);
As far as I can tell, that code matches the Example #1 code on that Breeze page and satisfies steps #3 and #4 on that Breeze page.
Then I have some basic views that use controllers and datacontext JS files, the latter of which inject the breeze object as a dependency. To test whether Breeze is actually executing the configuration to work with Angular promises, I edited the breeze.bridge.angular.js file such that the following statement is included as the first line in the useNgPromises() function:
console.log("Using Angular promises!");
When I run my app, I never see that in the console, so I assume the configuration is not happening.
Am I doing something wrong in the setup? If so, what?
You absolutely do NOT need Q.js; the fact that you see errors relating to that library is an indication of a configuration mistake.
I think you found the problem when you added .value("breeze", window.breeze).
That one line wipes out the definition of the breeze service established by the 'breeze.angular' module (defined in breeze.bridge.angular.js), thus preventing the configuration of breeze for $http and $q. Without that configuration, breeze looks for a promises implementation elsewhere ... hence the complaint about missing Q.js. So ... yes ... that line was a disaster.
I wondered where you got the idea for that line. Thanks for referencing the Microsoft ASP Breeze/Angular template documentation. Wow that is old (2013). I'd kill it ... and the other defunct Visual Studio Breeze templates ... if I could (maybe I can). I thought we had made them hard to find. Looks like you found them. How?
That certainly isn't how we teach Breeze + Angular these days.
The "Todo Angular" sample is a far better guide (even if it is a year old).
I resolved the issue by commenting out the line:
.value("breeze", window.breeze)
I had included that line per the "Dependency Injection" section here: http://www.getbreezenow.com/ng-spa-template#module as well as the "Value Recipe" section here: https://docs.angularjs.org/guide/providers, but apparently it does not play well with the Breeze Angular service.
I am not sure exactly why this is the case but my best guess is that the issue was caused by Angular values not being configurable, per this explanation: https://gist.github.com/demisx/9605099, and I assume the Breeze Angular service requires the Breeze object to be configurable and therefore it should not be injected as a dependency for the app via the value recipe.
I should also note that after removing that troublesome line of code, I no longer receive an error indicating that Q.js is required since the Breeze Angular service successfully configures Breeze to use Angular's $q instead.
I am getting this error in the console $q is not defined. When I did some research I found some thing like .q library has been deprecated from
http://www.breezejs.com/documentation/breeze-labs/breezeangularqjs
If this is so, then the whole concept of promises is also deprecated,
Promises are not deprecated. In fact they're gaining quite a lot of momentum lately and are included in the next version of JavaScript.
Let's look at what they say:
This breeze.angular.q library has been deprecated. It is superseded by the Breeze Angular Service which more cleanly configures breeze for Angular development.
The Breeze Angular Service tells Breeze to use Angular's $q for promises and to use Angular's $http for ajax calls.
What they say is that breeze uses Angular's own promises for promises rather than its own breeze.angular.q which uses Q promises which are more able but also much heavier than $q promises which Angular uses. This is simply an API change.
Inside Angular code, you can obtain $q using dependency injection - for example with the simple syntax:
myApp.controller("MyCtrl",function($q){
//$q is available here
});
Alternatively, if you want to use it independently you can use service location and obtain $q directly from an injector, but that's rarely the case. (If you want an example - let me know, I'd just rather not include code that's usually indicative of bad practice).
# in your console, try following code
$injector = angular.injector(['ng']);
q = $injector.get('$q');
deferred = q.defer();
# then do whatever you want
In an Angular JS app I'm working on, I am using a service to periodically (in a $timeout) make a GET request to a URL in my API (both the Angular app and the API are being served from port 5000 on localhost).
For some reason, it appears that $http is not actually sending the GET. For each $http.get(), the .error() is called with empty data and a status of 0. When I check in my server log (I'm running a Ruby on Rails backend with the Unicorn gem for my server), it appears that the server never receives the request from Angular.
Here's the function in my service:
updateUserStatus = () ->
$http.get('/api/v1/status').success (statusData) ->
# update the variable and notify the observers
this.userStatus = statusData
notifyObservers()
startStatusTimeout()
.error (error, status) ->
# if there's an error, log it
console.log 'error:'
console.log error
console.log status
startStatusTimeout()
What's really odd is that it only happens sometimes. When it stops working, I can change the URL in the $http.get() to '/api/v1/status.json', and it works. For a while. Then I switch it back and it works again, for a while... obviously there is some greater issue at play.
I've been racking my brain for a few days now, and I've seen a bunch of similar issues on SO, but they all seem to be solved with implementing CORS in Angular, which I don't think is applicable to my situation because it's all coming from localhost:5000. Am I wrong? What's going on?
For reference, I'm using Angular version 1.0.7.
I had the same problem.
Check your code to see whether this happens after events that are fired from the DOM and are unknown to Angular.
If so, you need to add $scope.$apply(); after the get request in order to make it happen.
I'm fairly new to Angular so I'm not sure this is the best practice for using Angular, but it did work in my case.
See this similar question for a better explanation.