Support asynchronous module.run()

[coli]

We want to issue a few $http calls in the module run block, ideally, the run should finish only after the $http and processing finishes before the dom compiling happens.

[petebacondarwin]

This is not so easy but should be looked into.

[dagingaa]

The way Jasmine does this is by setting a flag, that will let the function run and wait for the callback until the flag is set to true, or until a timeout is fired.

Basically something like this:

var flag = false;
$http(...).success(flag = true);
$timeout(function () {
    flag = true;
    // Or add some error handling stuff here
}, 5000);
while (!flag) {};

It's not pretty, but should do the job. The code above isn't tested, so you may need to modify it a bit. It's getting late here. Hopefully something to get you by until something a bit prettier comes along.

[Narretz]

+1

[coli]

On a second though, this does lead to the inability to draw fancy loading screen using angular directives...

[bcherny]

+1

[shahata]

Doesn't $routeProvider with resolve solve this? Maybe I didn't understand the problem...

[coli]

This is more for async module init support. With that said, I no longer need this in my current projects.

[bcherny]

@shahata $routeprovider does this, but not every use case for promise-giving runs uses routes. In my use case, it's for a module that wraps a directive and has nothing to do with routes.

[pocesar]

+1

check if the run function returns a promise, then only procceed when it's resolved. since runBlocks is an array of functions, it shouldn't be hard at all

[horyd]

+1

[davismj]

+1 embarrassing that this got ignored

[pocesar]

any idea when this is going to land? so frustrating to have to move initialization stuff to resolve in the router, mainly because sometimes the initialization code is url agnostic (aka, must be initialized for any type of URL that the user arrives at your SPA)

[davismj]

i don't think angular will be receiving any enhancements henceforth. they're all being added to angular 2.0

[pocesar]

how long the half-assed run method will remain synchronous? it's fine and understandable that config doesn't support asynchronous calls, since you don't have any providers that do $http calls, but run does. look the type of hacks that the lack of this feature (that should've been in since the beginning) causes
https://github.com/philippd/angular-deferred-bootstrap/blob/master/src/deferred-bootstrap.js

it's embarrassing

[cankayacan]

+1

[petebacondarwin]

@btford is looking at how the use cases around this could be supported via the new router rather than inside run blocks.

[edotassi]

+1

[benzen]

+1

[ziaukhan]

+1

[alexbeletsky]

+1

[petebacondarwin]

The main problem we have is the $q is created inside a module that is being loaded when the runBlocks are being run. This means that we would need to somehow extract "some" of the services (or maybe modules) and create those first and then have a second pass that loads the rest of the modules (and services, run blocks, etc) after $q has been created.

[petebacondarwin]

@lgalfaso - perhaps you could look into this a bit more as part of your $injector work later this week (or next)?

[fabiosussetto]

I know it's just a workaround, but I've normally solved the issue of having some async bootstrapping logic by using angular ui router and having a root abstract state in combination with resolve. The root abstract state has to be always resolved first, so it's a good place to load settings, display loading animations, etc.

[kashesandr]

+1

[vladmiller]

It's been two years since issue was opened and there is still no good solution

[petebacondarwin]

@vladmiller There are solutions but perhaps you do not feel that they are good:

• use ngRoute or ui-router with resolves and put your application startup code inside the top level route
• create your own async bootstrap. see Support asynchronous module.run() #4003 (comment)
• use the new component router with $onActivate in the top level component

Putting non-trivial application work inside .run blocks makes it difficult to unit test your code. So it is not something we want to encourage. Moving this to the Ice Box as something we are not likely to implement.

[vladmiller]

@petebacondarwin I would disagree with you; everyone expect angluar to be simple and intuitive, instead you have to either implement your own async bootstrap module or bootstrap module in different place. In my opinion this makes angular more complex.

Can you also explain what do you mean when saying that async code in .run will make testing more difficult?

Apologies for my previous rude comment.
Thanks

[pocesar]

@petebacondarwin I fail to see how it makes it difficult to test. if you place the initialization code in a service, you can just watch/mock/compare the results you'll be expecting from the http backend mock, regardless if it's being executed inside a .run block or not. having code exist outside angular due to work-arounds for the lack of async run is what makes it almost impossible to test

[alexey-sh]

How it's going?

[petebacondarwin]

Another approach: http://plnkr.co/edit/8XGSNOzzRGvgNSSnXx3M?p=preview

[vvmsoft]

@petebacondarwin solution worked for me

[petebacondarwin]

Since there are workarounds and supporting async run blocks would add complexity to the bootstrap I don't think we will be implementing this feature.

[alexey-sh]

Simple feature but too hard to implement. 😕

[yeluolei]

+1 for this feature

[kevingilbert100]

+1

[cristianhoyos66-zz]

+1

[cristianhoyos66-zz]

@petebacondarwin solution works good.

[canyetim]

+1. :(

[celiovasconcelos]

+1

[rochejul]

+1

[liuhao2050]

+1

[nicolae-olariu]

+1

[petebacondarwin]

We are not going to do this.

[Eduardo-Julio]

+100, all the work arounds are terrible.

[petebacondarwin]

@Eduardo-Julio - we are not going to implement this feature as it would make the bootstrap of AngularJS applications much more complex. Adding further +s will not help.