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.
Related
I am making a back end call to Restful service from my controller in my angular application, but my requirement states or compels me to make the back end call in the service. Why is it not recommended to make the back end calls from the controller?
from the angularjs docs:
Using Controllers Correctly
In general, a Controller shouldn't try to do too much. It should contain only the business logic needed for a single view.
The most common way to keep Controllers slim is by encapsulating work that doesn't belong to controllers into services and then using these services in Controllers via dependency injection. This is discussed in the Dependency Injection and Services sections of this guide.
Controllers should contain only the business logic.
It's a good practice to isolate the backend-call in a service, so you can use everywhere in your app, just adding the service-name into the controller.
I suggest you to read this Angular styleguide (written by John Papa and Todd Motto, two Angular guru)
It's very simple and clear
https://github.com/johnpapa/angular-styleguide
Our project uses various jquery plugins. We are trying to convert it into angularjs. What is the right approach in terms of implementing such a functionality in angular perspective. is it correct to a write directive for each plugin and call the jquery plugin internally it or do we have any standard approach.
TIA
Try to use Angularjs plugins rather than jquery plugin
If you are using jquery plugin then you have to take care of $digest cycle because your jQuery plugin may have setTimeout() inside which make angular out of $digest loop, so it may be possible that you may got trouble in getting $scope values.
tl;dr
I'm really struggling to find the appropriate pattern here. How should I best configure a generalized provider to a specific use-case? I can't use $http as a dependency in .configure(); can I?
longer, boring explanation:
I am trying to create a generalized provider which I may reuse in Angular. I have it working, however it requires configuration.
The intention is to provide a fallback REST service to use in saving data to the server, but with provision to save offline in local-storage. Therefore, I need to provide appropriate $http calls for each instance of this provider.
Is it possible to provide appropriate $http calls with .configure() or else should I try and figure out how to inject $http into the provider from the start and then configure it afterward??
It's frustrating... and may change in AngularJS 2.0... But for now, yes, it is not possible to do this. There is a very high wall between the .configure() and .run() states, so you can't access $http from a .configure() function. The reason is that it hasn't actually been created. At this stage, all that exists is the provider. Once all of the dependencies are configured, then the http provider will be used to make the real $http service.
I'm not sure exactly what you're trying to do, but there are two excellent AngularJS developers that are good to follow who have some advanced patterns in projects they've shared: Pascal Precht and Brian Ford. Here are two projects that make heavy use of provider/service concepts as well as $http-driven services:
https://github.com/angular-translate/angular-translate
https://github.com/btford/angular-modal
Angular Modal, especially, does $http work to load its templates. There might be use cases in there that are similar to what you're trying to do.
I'm implementing an Angular/RequireJS routing solution based on Dan Wahlin's article.
In the article, Dan makes the following register shortcuts on his app object:
app.register =
{
controller: $controllerProvider.register,
directive: $compileProvider.directive,
filter: $filterProvider.register,
factory: $provide.factory,
service: $provide.service
};
When I use these, I can correctly register and reference my controllers through RequireJS calls, but if I use the traditionall app.controller() or angular.module('myApp').controller() syntax, then Angular can't find them and I get errors from the router.
How is defining controllers, directives, etc. with the above method different, and why does it work with RequireJS where the more traditional method does not?
Any ideas?
Thanks,
-Nate
Since the controllers are being added dynamically things have to change a bit from the "norm" (unfortunately). The main difference is that controllers are being wrapped in RequireJS modules, being downloaded dynamically, and then being registered. The $controllerProvider.register allows for the dynamic registration. It's definitely not the normal technique but what's required in this scenario. That's why "app" (which is the RequireJS module that gets us to the application's AngularJS module) is passed in to all of the controller modules. It exposes the controller property shown above which handles the registration "on the fly".
If you download a controller script dynamically and then use the normal technique (angular.module('..').controller(..)) it won't register it properly - at least that was the case the last time I tried it. It's been several months since I've tried it but I'm assuming the same behavior is still there.
The bottom line is that when controllers (and other items such as services/factories) have scripts that are loaded "on the fly" things change somewhat and the way you access and register these items changes from the normal way that we're all used to seeing.
So I know if the call is outside angularjs or it is async then we need $apply to update the
angularjs scope.
What is the best practices to using $apply if I have many api/3rd party in my app?
I always forgot or didn't know that api/plugin is async.
I would write a wrapper service for each lib that needs it, and encapsulate callbacks in angular promises, but remember it's only neccessary for asynchronous functions, if you call a synchronous external lib, this should work as expected without issues.