I am using angular translate version 1.x for quite a while.
The use of the $translate service is really easy.
In a controller, you can simply write:
$scope.whatever = $translate('WHATEVER');
But in angular translate 2.x that has changed.
Now the service works async.
The simple and fast to write above statement has now become:
$translate('WHATEVER').then(function (whatever) {
$scope.whatever= whatever;
});
This makes things more complicated.
I don't really understand the need for this.
In most scenario's (?) the translation files will be downloaded once and then getting a translation value should be really fast. Why the need of handling this async?
Can anyone explain why this change was made?
Thanks
You should think the way around:
Who guarantees you, that all language files are loaded in time or at all. And as you're in a browser environment, everything retrieved from somewhere is asynchronous in terms of network speed etc.
So in case one "loading" process hangs, the whole application will be unusable because it is waiting for a correct reply/answer. So, if you do it synchronous, you'll have to wait until everything is loaded - just think of big images or translation files in our case here and maybe these are even unneeded translation files, because you're just using some languages out of the language stack as your personal preference.
Async loading speeds up the whole process of rendering the DOM and giving your "application" already a final state that you can work with, no matter, how many promises haven't been resolved yet.
This is one of the "big" natures of the Web Applications and yes, might cause headaches sometimes. Sometimes you'll ask yourself "why not wait this 500ms until everything is there?", but it could be the case, that one of the webservers is down or just overloaded and then you'll have to wait and wait and wait as a user. Do you always want this?
Related
I am taking over a big (50+ modules) AngularJS project, from another programmer, which did not do it right, so I have several migration questions:
There are lots of usages of JS functions like setTimeout and setInterval. It will be very easy to change to $timeout and $interval (because they use the same syntax, so it is just find and replace), but should I bother?
The entire project is without services, and all data requests run in the controllerss. Should I make time to create services for all controllers, the most important ones, or none? (I know that "if it works dont fix it", but from your experience does this make your life easier?)
The ENTIRE project uses $.ajax, with over a thousand requests. I do not have the time to migrate all requests to use $http, but I will try over time. In the meanwhile, should I create a service like $http_o and replace all "$.ajax(" strings in all files to $http_o, so the service will pretty much get a normal ajax request syntax, and send it using the $http service.
Every controller's services are written in a variable name, and not with a string at the start (function($scope) instead of ['$scope', function($scope)). Is there a fast way to change all of them to use the normal syntax, so I can use a minifier, or do I have to do it by hand? Should I do it?
I will obviously try my best to rework modules to use correct MVC and angular rules in my spare time at work, but this will happen way ahead in the future.
It's not as trivial as you might think i.e. $interval applies a $rootScope.$apply() at end so it will trigger $digest cycle, with lots of intervals it might slow down app
It's all about readability and maintainability. I'd say yes, do separate services and DRY the application otherwise when you will have to debug it in 3 months time it's going to be hell
A smart regex could work for you although the advantage of using $http over $.ajax is that you don't have to use tricks to trigger change in view - i.e. manually run $digest or $apply
You can do it easily with https://github.com/olov/ng-annotate
I'm struggling dealing with Protractor's asynchronous nature.
On different connections or browsers, it seems that elements are sometimes found, sometimes not, depending on my connection speed.
Short of using .then() callbacks, what options are available to me within Protractor to deal with it's Async issues to make sure elements are fully loaded before moving onto the next action?
Thanks!
I had many problems like that.. to resolve it, if a element depends of a asynchronous call to be showed, I always put a browser wait before.
browser.wait(protractor.ExpectedConditions.elementToBeClickable(element(by.id('elementId'))), 3000);
element(by.id('elementId').click()
Based on your other question, it would seem you're testing a non-angular application. Hence, you will want to use ignoreSynchronization.
And thus, you'll need to handle async and all it's quirks yourself. Eg. using then() callbacks, and ExpectedConditions and the like.
I'm attempting to write some UI tests for a RequireJS-based Backbone application, utilizing FluentAutomation.SeleniumWebDriver and NUnit. The HTML page in question contains a typical data-main attribute for loading the RequireJS module for the application. My struggle is in properly detecting when the application is fully loaded with these tools; the only thing I've gotten to work consistently so far is using an explicit wait in seconds, like so:
I.Open("http://myapp")
.Wait(5)
.Enter("foo").In("input[name=username]")
.Enter("bar").In("input[name=password]")
.Click("button")
.Wait(5)
.Expect.Text("Welcome").In("#welcome");
This is less than ideal -- my test as written above will always take at least 10 seconds to run, when in reality the app might be "ready" much faster than that. What I'd like to be able to do is something like this:
I.Open("http://myapp")
.WaitUntil(() => I.Assert.Exists("input[name=username]"))
.Enter("foo").In("input[name=username]")
.Enter("bar").In("input[name=password]")
.Click("button")
.WaitUntil(() => I.Assert.Exists("#welcome"))
.Expect.Text("Welcome").In("#welcome");
However, this doesn't work -- using WaitUntil here actually seems to prevent the app from loading, for reasons unclear to me, as I simply receive timeout exceptions after the default wait period (30 seconds), stating that it was unable to locate the element in question within that timeframe.
I see that Selenium 2 provides a WebDriverWait for this kind of scenario, and possibly that would work here, but am unsure how I would use this within FluentAutomation (and a quick search of the FluentAutomation code on GitHub doesn't seem to indicate it's in use within the library).
What can I use in FluentAutomation to properly wait for a RequireJS module (or DOM loaded by it) to be ready?
Additional details:
This might not be a RequireJS compatibility problem at all. I've looked further into the app and found that what's happening after the Click("button") is actually a window.location.replace -- not a RequireJS async module load. It's the one place in the app that this is occurring, apparently. So, is a window.location redirect a known scenario that would cause problems with WaitUntil, and is there an alternate approach (aside from a simple Wait(5)) that would properly handle this?
I'm building a web application using GAE.
I've been doing some research by my own on GAE python project structures,
and found out that there isn't a set trend on how to place my handlers within the project.
As of now, I'm putting all the handlers(controllers) in main.py,
and make all urls (/.*) be directed to main.application.
Is this going to make my application slower?
Thank You!
In general, this will not make your application slower, however it can potentially slow you down your instance start-up time, but it generally isn't a problem unless you have very large complicated apps.
The instance start up time comes into play whenever GAE spins up a new instance for you. For example, if your app is unused for a long period and you start it up once in a long while, or for example, if your app is very busy and need a new instance to handle the load.
python loads your modules as needed. So if you launch an instance, and the request goes to main.py, then main.py and all the modules associated with it will get loaded. If your app is large, this may take a few seconds. Let's just say for example it takes 6 seconds to load every module in your app. That's a 6 second wait for whoever is issuing that request. Subsequent requests to that loaded instance will be quick.
It's possible to break down your handlers to separate modules. If handler for \a requires very little code, then having \a in a separate file will reduce the response time for \a. But when you load \b that has all the rest of the code, that would take a while to load. So it's possible to take that 6 second load and potentially break it up into a few requests that may take 2 seconds.
This type of optimization really depends on the libraries you need to load with each request. You generally want to do this later on, when you run into the problems, rather than design your layout for this purpose up front, since it's pretty difficult to predict.
App Engine warmup requests also help alleviate this problem.
No, that doesn't affect the speed. Your code needs to be loaded anyway, so it makes no difference if it's all in one file or not. It will of course make the file more complex, but that's your problem, not GAE's.
I have an ASP script that generates page content in response to some GET parameters.
Sometimes the page generation takes a bit of time (running database queries etc) and I'd like to display something to the user while the page is loading. What is the standard way of doing this?
I'm not using AJAX on the page at the moment.
Is there a reason you're not using AJAX? I had a similar problem at an internship I did last summer. At first I decided to ignore AJAX, partially due to being lazy and not wanting to have to learn javascript/ajax usage. However, it became increasingly obvious that without ajax, the user experience was being significantly hampered (due to the same sort of thing you're talking about here... a longish server side operation).
If you're in the position to "AJAXify" your application, then I suppose you could add a loading image when the request is initially made, and then replace it with the given content when the asynchronous call returns. Jquery makes this kind of thing pretty easy with its various AJAX facilities and callback functions.
Of course, you're probably already aware of all of this... so please forgive me if I'm just restating the obvious!
You can use the Response.Flush to force something to the browser:
Response.Write("<div id=""preloader"">Loading, please wait...</div>")
Response.Flush()
'long running code...
'long running code...
'long running code...
Response.Write("<script type=""text/javascript"">document.getElementById(""preloader"").style.display = ""none"";</script>")