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.
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'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 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?
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
I'm confused about what code I should instantiate directly in Backbone.js. Should I create a generic object App that instantiates my views? Should I instantiate an App View that instantiates all the other views on the page and coordinates everything? Should I create views, models and collections and attach them to the window ?
Also, are controllers even necessary? So far I'm not finding any use for them and they are missing from many of the examples out there. Should I instantiate a controller and have it create the other objects as I do in other languages' MVC frameworks?
My guess is I am free to do what I want but I would prefer some advice from somebody who has used it quite a lot.
Controllers are useful for managing the hashbang URL.
If you don't have multiple pages, states you want to save or want to use the back and forwards buttons then controllers have no use.
Most examples of backbone I've seen have a AppView class that manages views and collections.
See the Annotated Example
Generally speaking, a router or controller would be the centerpiece of your application, although it may be your own hand-rolled init or global object. Backbone provides utilities to you; it doesn't provide an entire soup to nuts setup.