I tried to google the following question, but nothing came up (which is super weird I need to).
What is an Agular app lifetime in a browser?
Or to rephrase when a user opens an Angular website, the app instances in the browser and stays live until the user leaves the website or closes the browser or?
On the separate note is it better to use a service for holding global variables (e.g. logged user name) or $rootScope?
Thanks!
What is an Agular app lifetime in a browser?
The angular app persists while that particular tab/site is open. If you navigate away from it and then back to it, for all intents and purposes, that's a fresh instance of the application. You could mimic a persistent session but that would entail a custom implementation on your part.
Here is a post on preserving data on a refresh of the application that you might be interested in - AngualrJS: sustaining data on html refresh
On the separate note is it better to use a service for holding global variables (e.g. logged user name) or $rootScope?
This is well documented and you can find myriad sources both here on SO as well as the internet, but it's better to use an angular service to share data among various controllers. It's not recommended that you pollute the $rootScope if you can avoid it.
Here is the same question asked on SO with solutions:
angular set a variable accessible to any scope
How to use variables from a controller in another controller in AngularJS
If you use angular's routing or another way to load views that doesn't reload a page, then an angular application will stay active until you leave the page (closing or refreshing).
Every time you load a page through angular its controller's data is in its initial state so any modification to a controller's data will get lost when you change page (unless you persist it somewhere, that is)
Regarding your second question, the best way should be to get a user's data after every page change (to check if the user is still logged in. Saving a user's data client side without checking if it's still valid might be a security issue). But in any case, a service is a better way to store data than using rootScope
Related
I was wondering what is the lifetime of variables stored in factory/services in Angular JS? If we refresh the page, will the values still persist? What will happen if we refresh the entire application? Actually i am trying to store values in factory and fetch them on any page by passing them in respective controllers. So should we refresh (F5) the pplication, will values go undefined in factory?
Any help will be appreciated
The lifetime of a service is the lifetime of the application - services are basically Singletons, created when the application is constructed.
So you basically ask: what actions restart the application?
The user manually 'refreshing' the page: yes. The browser takes the user's request literally: discard the current page and reload it (although of course there are caching issues to think about; but they are separte from the lifetime of any javascript objects).
The application navigating to a URL in the same namespace (i.e., the part of the URL before '/#/'): no. Whatever routes you set up (e.g., '/#/foo/page1') and then navigate to under code control do not trigger the browser to reload the page. The original application object (and thus the Singletons that represent services) remain active.
When developing a web application with angular js, a part of time that developers spend is the time for implementing routing.
When using ui-router in a application, there are two "phases" to consider with regards to routing:
user navigates inside application: when click is made on some button, user is transfered to another state by using $state.go("somestate"). Parameters can be send etc. And url is changed accordingly.
user navigates directly via url.
Lets say application has such route:
/mythings/{thingid}/mysubthings/{mysubthingid}
If user navigates to that url directly by pasting it into browser window, application needs to handle it. My question is what's the best practice to do it?
What I'm thinging is: if looking at url example above what needs to be done when user enters that url in browser:
get {thingid} from url (from $stateParams), then get {mysubthingid} also from $stateParams (probably by using resolve (ui-router feature) when defining state), then inject what was resolved to controller and then make a query to api and get data about "subthing" and present view in ui with that data. So that should work with both "types of navigations": when user clicks and is transfered to state, or when user enter url directly into browser. Is this the right path to go?
And I suppose that any url you go to when you click something in application, you should be able to take that url and just paste it into browser and see the same results without being redirected to anywhere else. If application cannot handle every url in such way, maybe application' architecture needs to be reconsidered?
Thanks
In UI-Router, the main component of the routing is the state. The URL is essentially just an address that points to a specific state of the app. I don't think it's necessarily productive to think of the two ways of navigating as separate; they're just two sides of the same coin. There should be no URL that isn't handled by a state. Any URL that doesn't match a state should be caught by the otherwise definition on the $stateProvider and probably redirect to your home page or a 404 page.
In your example, the thing/:thingId/subthing/:subthingId url should map to a predefined state just like any other state. Let's say that state is main.subthing. The process for loading the data, initiating the controller and rendering the UI should be exactly the same whether you get there by calling $state.go('main.subthing', {thing: 123, subthing: 456}) or ui-sref='main.subthing({thing: 123, subthing: 456})' or you paste myapp.com/thing/123/subthing/456 into the browser. They'll all end up at exactly the same place with exactly the same data by calling the exact same logic (most likely loading thing 123 and subthing 456 in resolves and injecting those into a controller).
You're right that if a url can't be handled by the application, that's a sign that something is wrong. Like I said, bad urls should be handled by defining otherwise when setting up states. But pasting a URL into a browser shouldn't require any extra work if your states are defined correctly. URL handling is baked into UI-Router by default.
I partially agree with you. The point where I disagree is when the URL is obtained by a user who is not supposed to access it. Quite often some websites implement authorization code to check if the user who is currently accessing the page is authorized to do so.
Also I think the route could be a bit different. Something like:
{thingid}/{mysubthingid}
This, I think is a cleaner URL and the parameters could be handled in the same way as the one in your example.
I suggest this in order to make it a bit difficult to unauthorized users.
Anyway, it definitely depends on the kind of application you are implementing. If the app's requirement is to be able to access the page by pasting the URL in the browser then I guess your approach is much better.
I am currently working on a large enterprise web platform which loads different web applications (html/js/silverlight) as views so it is almost like a container or a framework for accessing different types of web applications.
We are currently reviewing the migration to Angular however there's one problem (at least) which we can't address.
in the current non-Angular version when a user loads Application-A from within the framework and let's say types "ABC" in a text box then he decides to navigate away and load Application-B and after using that application when navigates back to Application-A he can still see "ABC" in the textbox in other words he has "Persistent Workspace" so every app that he loads whether it be Silverlight or Html/JS has the ability to be kept loaded into the memory.
Regardless of the right or wrong of this approach can anyone think of the way this can be implemented in Angular? a simple overview is enough.
[UPDATE]
Please note that we are dealing with iFrames for each of the web apps we currently load, so there's no model that we can persist to the browser storage or elsewhere. if all our apps where html/js based then we would have no problems as we could serialize the state of each view but since some are in Silverllight we can't do that. hope this clarifies.
Thank you all.
You can always synchronize Angular's state with the local storage of the browser. So there will have to be a unique key for every field in every form and use something like this.
Alternatively, you can listen for the $routeChangeStart event (docs) from within each controller that cares to save status. Then the controller can decide to serialize its state (or not) to the local storage. On controller initialization, the saved state must be retrieved.
Solutions involving the browser's local storage will not affect the server but will not be available to the user when he/she uses another computer. Otherwise, you should listen to the route events as before, but synchronize the "persistent workspace" with the server (slower, more development time).
I have an application which has some specific (non-trivial) initialization requirements, and it's not really clear what the best practice solution to this is. Sorry for the wall of text. The question itself is not that complex, but I need to make sure my reasoning is clear.
First, the application itself:
It has user authentication, though it is only forced at two points in time:
The first time the application is loaded (the very first time). I'll just call this requirement (1) through the rest of the question.
On a need-to basis when interacting with server-side. This part I have already solved with something similar to http://ngmodules.org/modules/http-auth-interceptor, though a custom solution (which is required because the application needs to use some services that I don't want to be Angular dependent). I'll call this requirement (2) through the rest of the question.
There are two controllers relevant to this question:
A navigation bar controller (fixed, not bound to the view).
The controller applied to the view used (ng-view).
It is started manually using angular.bootstrap.
This question is about the user authentication handling. Requirement (2), where a user has to authenticate on a need-to basis, is already solved. It is currently handled like the following:
Some server-side request is performed by one of my Angular service modules. The request can potentially result in a 401 response if the applied authentication token has expired (or doesn't exist all-together).
The application service module which made the request discovers the 401 response and applies a $rootScope.$broadcast('app:auth').
The authentication broadcast is picked up by some code using $scope.$on('app:auth'), shows a modal authentication dialog, and then makes sure the original service request promise is resolved / rejected (rejected if the user presses cancel in dialog).
The only differences between requirement (1) and (2) is that (1) should be a forced authentication dialog (the user cannot simply reject it with 'cancel' or 'esc'-button) and that (1) should happen as early in application initialization as possible.
Now, my issue is with requirement (1), really, and Angular best practices. There are a couple of ways to do this that I can see:
Perform this one-time authentication outside of Angular completely. The downside here is obviously that I have to write essentially duplicate logic for both the modal dialog box and the initialization. Some of this can be shared, but not all.
Perform this one-time authentication in some special (fixed) controller of the application (like the navigation bar controller).
Perform this one-time authentication in angular.module.run.
The aim here is obviously to "force" an authentication on the user before he (or the application) can trigger something else in the application.
I would love to use number (3), since I would then be able to re-use all code already in use by requirement (1). However, you then instead run into the question of where to place the event-listening code. No controllers / parts of the application are yet started at this point (only the injections are complete).
If I place the logic for authentication events in an application controller, that controller won't even have started at that point, and thus won't have been able to register with the event. If I place the $rootScope.$broadcast inside a $timeout with 0 delay, my navigation bar controller have started, but not my view-bound controller. If I place the $rootScope.$broadcast inside a $timeout with 100 ms delay, both my controllers have started (on MY computer).
The issue obviously being that the amount of delay I need to use is dependent on the computer and exactly what scope the event handler code is placed in. It's also probably dependent on exactly in which order Angular initialize the controllers found through-out the DOM.
An alternative version of (3) might also be to do the $rootScope.$broadcast in angular.module.run, and have the event-listener attached to the $rootScope itself. I'm leaning towards this being the most straith-forward way to do it.
See the following plunker (which tries to higlight the timing issue only): http://plnkr.co/edit/S9q6IwnT4AhwTG7UauZk
All of this boils down to the following best-practice question, really:
Where should application-wide code and non-trivial application initialization code really be placed? Should I consider the $rootScope as the actual "application"?
Thanks!
The short answer :
Application wide code should be in a service.
Application initialization code should be in the run block.
Longer answer :
Application wide code like your Authentication should be defined in a service. This service should expose API's which the rest of your application can interact with in order to achieve that task. Ofcourse the job of the service is to hide the implementation details. The service itself should take care of where it fetches the authentication information from ( initially ) - perhaps from cookies, perhaps from your local storage or session storage.. Or perhaps it even does a http call. But all this gets encapsulated into that Authentication Service.
Because now you have written a separate service and you can inject stuff into your run block you are good to go. You dont really need the $rootScope. The $rootScope is another injected service. But because it participates in the dirty checking mechanism and seemingly this service need not.. you dont need to over burden $rootScope with this additional task. Its not its job and perhaps it can be delegated to some other service whose only task is authentication. Because your service is also a singleton it is amazing at maintaining states as well. You could perhaps set a flag , something like isAuthenticated which can be checked later if need be.
Oh, between your modal should also be a service.. See the $dialog service in Angular UI if you havent already. Which means that authentication can directly work with the $dialog service.
You should put application-wide non-trivial initialization code in providers. Providers offer the most flexibility with regards to initialization, because they can be used to configure the service before the instance of the service is actually created by the $injector.
app.provider('service', function() {
// add method to configure your service
this.configureService = function() { ... };
this.$get = function (/*injectibles*/) {
// return the service instance
return {...};
};
});
The config block is your opportunity to initialize your providers. Inject your provider into your config function (notice the required 'Provider' suffix) and perform any initialization code that you need to setup your provider. Remember, that the provider is not the service - it is the thing that the $injector will use to create your service.
app.config(function(serviceProvider) {
serviceProvider.configureService();
serviceProvider.setTimeout(1000);
serviceProvider.setVersion('1.0);
serviceProvider.setExternalWebService('api/test');
... more configuration ...
};
There are several reasons why providers and config blocks are suitable for initialization:
config blocks are called only once and very early in the application life cycle
providers are configurable - meaning you can initialize the provider before actually creating the service.
The main purpose of the config block is initialization. It supports injection of providers as an opportunity to perform the initialization.
Providers are singletons (like factories and services) - meaning that one service instance is created by the $injector and then shared between all controllers, directives, etc - basically any where that the service is injected.
Now for requirements (1) and (2) - I think you're on the right track. I suggest creating an authLogin directive that shows or hides a modal login dialog based on an "IsAuthenticated" property that is being watched on the scope. This would take care of the requirement to show the login modal dialog when the application starts up. Once the user authenticates successfully, set the IsAuthenticated property to true (which would then hide the dialog).
The second requirement is handled through an HTTP interceptor. When a request is made and the user is not authenticated, the service would broadcast the event starting from the $rootScope downwards towards the child scopes. You can have the same authLogin directive listen for the event and handle it by setting the IsAuthenticated property to false. Since IsAuthenticated is a watched property, it would trigger the modal login dialog so the user can log in again.
There are many ways you could implement requirements (1) and (2). I offered a slight variation on your approach, but in general it is the same approach.
I am working on a small piece of an angular project and need to define some constants that are derived from values in a database. I have a REST endpoint that delivers the data I need, but I can't figure out how to load the values before the app gets automatically bootstrapped.
I cannot modify the application to a manual-bootstrapping process. Typically a resolve would be used upon navigation, but I have other components (like modals) that use the constants that aren't necessarily part of any route.
What would be ideal would be some sort of "resolve", but at the application layer. I do have the ability to load npm and bower packages, but anything that changes to a 'manual' bootstrapping method isn't allowed.
In that case I can recommend you to use a $rootScope. I don't understand very well your needs, but everything that is stored in $rootScope will be available in all views. Just fill it with your REST service inside the first or main view of your app. Although, it is important to understand that if you refresh you page, the $rootScope will be as well refreshed, this is, all of your REST calls will be launched again. (Navigating inside angular views is NOT refreshing the page unless you ask for it using window.reload() or similar; it is just the same page with a new controller)
To avoid this last behavior (page refresh) you could also use local Storage, which is basically a small amount of memory inside your browser where you can save any data that you want to keep regardless of your page refreshes. I used in one of my projects this library: https://github.com/grevory/angular-local-storage
It was useful for saving permanent stuff until user logs out.
Hope it helps! And sorry if I am answering something not useful for you
Cheers
It seems that the only way to effectively load some values from a service prior to the app starting is to make the service-call to and then manually bootstrap the app. The idea of an app-wide "resolve" doesn't seem to exist.