-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Core] Could APP_INITIALIZER depend on ApplicationRef ? #9101
Comments
We could change this. |
Reviewed #9110 and added some comments. But it is the right change for now, as adding eager providers would be a bigger change... |
it seems like we just need more lifecycle hooks for platform/application (sometime like: beforebootstrap, afterbootstrap, beforetick, aftertick) |
Just to point out an issue created by this one. When we try to navigate in the OnInit function of the RootComponent, the navigate event is cancelled. This happen because the method initialNavigation() on Router is called after the initialization of the RootComponent and cancelling the current ongoing navigation event. This is caused by the setTimeout() here https://github.com/angular/angular/blob/master/modules/@angular/router/src/common_router_providers.ts#L54-L61. It should be fix with this issue with the increase of lifecycle hooks (or whatever strategy you guys intent to do) |
After introducing |
Modules are eager, i.e. their constructor can be used as an app initializer
|
This makes `bootstrapModuleFactory` wait for promises returned by `APP_INITIALIZER`s, also making `bootstrapModuleFactory` async. I.e. now `bootstrapModule` and `bootstrapModuleFactory` behave in the same way. This ensures that all code form module instantiation, to creating `ApplicationRef`s as well as calling `APP_INITIALIZERS` is run in the Angular zone. This also moves the invocation of the initializers form the `ApplicationRef` constructor into the `bootstrapModuleFactory` call, allowing initializers to get a hold of `ApplicationRef` (see angular#9101). Closes angular#9101 Closes angular#10363 BREAKING CHANGE: - Deprecates: * `ApplicationRef.waitForAsyncInitializers`: No more needed as `bootstrapModule` and `bootstrapModuleFactory` automatically wait for promises returned by initializers.
This makes `bootstrapModuleFactory` wait for promises returned by `APP_INITIALIZER`s, also making `bootstrapModuleFactory` async. I.e. now `bootstrapModule` and `bootstrapModuleFactory` behave in the same way. This ensures that all code form module instantiation, to creating `ApplicationRef`s as well as calling `APP_INITIALIZERS` is run in the Angular zone. This also moves the invocation of the initializers form the `ApplicationRef` constructor into the `bootstrapModuleFactory` call, allowing initializers to get a hold of `ApplicationRef` (see angular#9101). Closes angular#9101 Closes angular#10363 BREAKING CHANGE: - Deprecates: * `ApplicationRef.waitForAsyncInitializers`: No more needed as `bootstrapModule` and `bootstrapModuleFactory` automatically wait for promises returned by initializers.
This makes `bootstrapModuleFactory` wait for promises returned by `APP_INITIALIZER`s, also making `bootstrapModuleFactory` async. I.e. now `bootstrapModule` and `bootstrapModuleFactory` behave in the same way. This ensures that all code form module instantiation, to creating `ApplicationRef`s as well as calling `APP_INITIALIZERS` is run in the Angular zone. This also moves the invocation of the initializers form the `ApplicationRef` constructor into the `bootstrapModuleFactory` call, allowing initializers to get a hold of `ApplicationRef` (see angular#9101). Closes angular#9101 Closes angular#10363
This makes `bootstrapModuleFactory` wait for promises returned by `APP_INITIALIZER`s, also making `bootstrapModuleFactory` async. I.e. now `bootstrapModule` and `bootstrapModuleFactory` behave in the same way. This ensures that all code form module instantiation, to creating `ApplicationRef`s as well as calling `APP_INITIALIZERS` is run in the Angular zone. This also moves the invocation of the initializers form the `ApplicationRef` constructor into the `bootstrapModuleFactory` call, allowing initializers to get a hold of `ApplicationRef` (see angular#9101). Closes angular#9101 Closes angular#10363
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Right now
APP_INITIALIZER
s can not have a dependency onApplicationRef
because the initializers are executed inApplicationRef_
ctor.Would there be a way to allow such a dep ? (ie execute the initializers after the
ApplicationRef_
is constructed ?)/cc @tbosch @vsavkin
(the use case is APP_INITIALIZER -> Router -> AppRef)
The text was updated successfully, but these errors were encountered: