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
Related
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
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.
We are using Angular JS promises heavily and its one of the recommend practice from Angular team also. I feel that its just a syntax sugar on the top of Callback. But not sure about it. Can anybody give me few examples where Angular.js promises are better than javascript callbaks?
Promises can be chained and avoid the 'pyramid of doom'. They also have a defined way of handling results like success and failures, which with callbacks is not the case.
if you have multiple ajax calls and on each success of those calls sometimes you have to call the same ajax method again. Coding such scenario becomes ugly with callbacks.
Promise handles that very elegantly.
After searching for hours in google and stackoverflow, I did not get the answer for good practices for AngularJS.
My Questions Are ::
1) Is it a good practice to manipulate a DOM using JQuery and CSS in AngularJS?
2) When to add $injector and $inject explicitly?
3) Is it good practice to use JQuery's $.ajax() method to call the asynchronously in the controller of a Module?
1) Is it a good practice to manipulate a DOM using JQuery and CSS in AngularJS?
You may be surprised how much Angular can do without jQuery. However, jqLite is certainly a "lite" version of jQuery. If you can't do it "clean" in Angular (e.g., if you find yourself writing parent().parent() instead of closest('.element-wrapper')) then sure, reach for jQuery.
2) When to add $injector and $inject explicitly?
Normal dependency injection is usually sufficient. You could, however, dynamically inject a service using the $injector, if you really need to: AngularJS dynamically inject scope or controller
3) Is it good practice to use JQuery's $.ajax() method to call the asynchronously in the controller of a Module?
Use $http or $resource. They do things $.ajax() doesn't, e.g., they'll initiate an AngularJS digest cycle when results come back from the server. Often, you'll want to put your server interaction code into an Angular service.