I am currently developing a new system at work, using AngularJS. And the application currently has many Controllers, Services and Directives, and many dependencies.
The system has about 9 services, and most of them are reused in multiple controllers, so I injected them into the parent controller so they can be accessible by children controllers. Each service stores data used throughout the whole system.
However, as the development progresses, I find that it is getting harder and harder to manage, and in some cases, I have to do a bit of hack to be able to use the instance of a service at different places.
My question here is, instead of injecting all services into the main controller, should I instead instantiate them in the app.js file as global variables... but I don't really like the idea of having global variables, so besides doing this, would there be any alternative solution to this?
Services are singletons in Angular, so you should just inject them where ever you need them. It's not necessary to inject them in to an ancestor and propegate it down. Just inject it directly into the child as well. There is only one instance of the service regardless, so why not just make it easier that way?
Related
In an Ember engine app, can an Application Controller be used to share data between
Say parent app & child engine
Between 2 child engines
So one of them would set the data/attribute on the Application Controller & other would access/get it from the Application Controller
Can that be done easily or is it better to use Services.
Generally a service is probably preferable. Controllers are singletons and have the ability to do what you are suggesting, but services are a simpler concept that was abstracted in Ember as the community began realizing what they were using controllers for. At some point, some of that controller functionality may go away too ...
I am new to angularJS. I am trying to debug a full-fledged angularjs app. I am totally confused as it contains lot of directives, providers, filters and controllers. Moreover, It also uses lazyloading using oclazyload. Individually, I know about directives, providers, filters and controllers and routing. But when all put together, I am totally confused. I have tried searching angularjs docs, but couldn't find any good reference.
Can you please explain me what's the flow of execution/sequence of things happens in the angularjs app ? In other words, in which order angularjs components such as controllers, directives, filters, providers, services will be processed, and how many times ?
I beg your pardon, for may be such simple question.
Thanks in advance.
The controllers are initialized when you reference them in your html files.
Services/directives will be initialized when calling them, when services will be initialized once per app and directives each time you use one.
I'm hoping someone can clear this up for our team. Why exactly are controllers singletons which don't get reset on navigation? In what situations is it better for them to not reset every time. I've heard "Controllers as singletons make perfect sense in any long-lived application" but non ember devs I've talked to were equally confused by this. Is this a design flaw that is being improved in the future or are we just looking at things the wrong way?
Hoping for a really clear answer I can take back to the team. Thanks everyone!
Not all controllers are singletons, most applications when they iterate over a collection will be creating instance controllers for each model. Ember dynamically creates a controller for you.
I use controllers to wrap all my model instances, eg editing a contact with multiple address models
Route based controllers are singletons because routes are singetons and normally persist for the life of the application once instantiated.
Ember doesn't need to tear down controllers and routes when transitioning between routes as the only thing that needs to change on rentering the route is the controllers content/model property.
It is trivial to clear the content of a controller on a route transition if you want to. I just recently answered a question on that which does that and additionally unloads models from the store as well:
https://stackoverflow.com/a/26695922/2238268
Singleton controllers can also be useful for managing other state in your application, perhaps gloabal session/authentication state.
So really Ember provides both singleton and instance controllers and they are both used heavily depending on the complexity of your business logic. I tend to keep my models fairly plain and put anything not route related in controllers. I do dirty tracking and undo/reversion in controllers as well as orchestration of persisting model changes in controllers. Aside from the route level controller I have a lot of instance controllers supporting views and implementing the update logic that can span many models.
I'm a familiar person with Angular Js, recently I've seen that in some projects multiple angular modules are created and assembled in main module.
The code looks like.
angular.module("main",['main.sub1','main.sub2','main.sub2'])
angular.module("main.sub1",[])
angular.module("main.sub2",[])
angular.module("main.sub3",[])
My questions are
When to approach such fashion of splitting modules ?
How it is useful ?
Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)
If i inject a dependency in sub modules are they by default injected in main modules ?
I read few blogs but I'm not able to get a clear perception.
Can you please guide me through.
1.When to approach such fashion of splitting modules ?
Preferably, Always. But you don't really need to do it unless you have multiple apps that are using the exact same code, maybe the way you handle authentication in a few apps is identical, it would make sense to put the common code into a service and have that service as its own module. This offers code reuse, and we all know that code reuse is good.
2.How it is useful ?
Again, reusability is the key word here. You don't want to go around writing duplicate code. Code duplication is just plain wrong, and results in more expensive maintenance and more error prone code.
Another advantage is that modularising your applications explicitly outlines the dependencies of your application and separates the responsibilities of different parts of your app. Code reuse and separation of concerns are fundamental practices in writing maintainable code.
Another reason to separate your app into modules is performance. Right now I'm working on an app (web shop) which consists of 2 main sections: one section(app) for normal users/buyers/sellers, and another app for the admin. Now the users app needs some scripts/libraries the admin app doesn't, and vice versa. For example the admin app uses a kendo grid which requires a kendo.all.min.js script which when minified is 1.7MB! Now would it make sense to force all visitors to the site to download the heavy 1.7 MB script?
3.Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider
for each separately)
Yes. Ideally your applications will have different route/state configurations, so each app would have their own app.config(), this means you could define separate routes for each app using the shared modules. To my experience the main things you want to move into their own modules are services and directives, not applications routings.
4.If i inject a dependency in sub modules are they by default injected in main modules ?
Yes. If you inject a dependency X into a module A, and module A will be used by another module B then B will also inherit the dependency X.
A module is the kernel of functionality for Angular apps. Modules contain all of the code that we
write for our specific app and, thus, tend to grow huge in a monolithic way. Although this tendency
isn’t bad (modules are a great way to reduce global scope noise), we can divide our modules.
There are several differing opinions about when to create a module and when to nest functionality
in a global module. Both of the following methods are valid ways to break up our functionality by
modules:
1. When to approach such fashion of splitting modules ?
When you want to sepereate your app logic by functionality or by routes, is needed because as your code separated on modules, it easy to understand, to tests and etc. angular module system implementation of Module Pattern.
Modules are an integral piece of any robust application's architecture and typically help in keeping the units of code for a project both cleanly separated and organized.
2.How it is useful ?
For starters, it's a lot cleaner for developers coming from an object-oriented background than the idea of true encapsulation, at least from a JavaScript perspective.
Your significant other is the new developer on the team who's been asked to fix a bug on one of the many screens in your app.
The developer sifts through the directory structure and sees all the controllers, models and services neatly organized. Unfortunately it tells him/her nothing about which objects are related or have dependencies on one another.
If at some point the developer wants to reuse some of the code, they need to collect files from a bunch of different folders and will invariably forget code from another folder somewhere else.
3.Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)
Another method we can use to break up our app is to divide our modules by route. This breakdown
allows us to write isolated tests that focus on the functionality per route. Modularizing by route can
make more sense, depending upon the project; it allows us to divide our functionality efficiently
when we’re dealing with a lot of independent routes.
For instance:
angular.module('myApp.home', []);
angular.module('myApp.login', []);
angular.module('myApp.account', []);
angular.module('myApp', [
'myApp.home',
'myApp.login',
'myApp.account'
]);
This modularization makes sense specifically when we’re dealing with large numbers of routes
and/or when we don’t have too much cross-over between routes
4.If i inject a dependency in sub modules are they by default injected in main modules ?
shortly: yes. :)
I am new to AngularJS, the notion of scopes really confuses me. I have a situation where I want to modify a an object or a variable from different scopes. Here is why:
in my application I want to centralize the user notification Controller and notification view.
In the middle top of the page. I separate my code as follow: each view has its controller I think its fair reasonable. I want to inject a service or some common object that when invoking its function with some string parameter on a common place but, I figured out that I can not inject $scope service. So, when
What you want is to communicate between controllers. That is fairly easy to realize whit a service that can broadcast messages (or objects) between controllers.
There is a nice youtube about this:
http://www.youtube.com/watch?v=1OALSkJGsRw
OK here what I have done in my application. I am a java programmer and I used to work with GWT
In GWT ther is a very nice design pattern, to notify widgets across the application, called EventBus. In angular I tried to do something similar. Here is the code link in gist