To keep consistency with provideHttpInterceptors, probably we should choose provideAppInitializers(...initializers: InitializerFn[]). How do you think about it?

To keep consistency with provideHttpInterceptors, probably we should choose provideAppInitializers(...initializers: InitializerFn[]). How do you think about it?

Hey @lacolaco! I wonder if we really want to keep them consistent.
In most cases, you want to provide all your interceptors in one place with an array that makes the interceptors order explicit and easy to understand.

On the other hand, app initializers are often totally independent and even provided in different places like custom provide functions. (e.g. provideStore() { return [..., provideAppInitializer(store => store.init())] }
My guess is that in most cases there will be only one app initializer so writing provideAppInitializers([() => {}]) can be syntactically heavy with too many types of brackets in one line 😊

We could end up in a styleUrls / styles situation where the array was of a cardinality of one in most cases.

What do you think?

@yjaaidi As you says, each APP_INITIALIZER function is basically independent. I agree with your design 👍

@yjaaidi can you please update the commit to be a feat rather than refactor?

@yjaaidi can you please update the commit to be a feat rather than refactor?

Done!

We tried to make it ship before 17.1.0 😅 but you got us!
Cf. https://youtu.be/zno7FMKXbVQ?t=2010

👍 either way works for me.

@alxhub done here as there is a low risk this breaks anything and rolling back to the previous implementation is straightforward.

Now, all app initializers will run with injection context.

@atscott do you want me to squash the commits or keep them separated?

@atscott do you want me to squash the commits or keep them separated?

What you have is fine

Thanks @atscott, @alxhub and @JeanMeche for your time!

Now that the initializer is running within an injection context even without using the helper, I update the reference docs with simplified examples. What do you think?

I'd prefer replacing the following APP_INITIALIZER docs example:

 function initializeApp() {
   const http = inject(HttpClient);
   return firstValueFrom(
     http
       .get("https://someUrl.com/api/user")
       .pipe(tap(user => { ... }))
   );
 }

with something simpler even though more abstract like this:

function initializeApp(): Promise<unknown> {
  return inject(MyService).init();
}

This could be fixed in a distinct PR.

cc. @alxhub @atscott @JeanMeche @JoostK

Presubmit.

This PR was merged into the repository by commit 19edf2c.

The changes were merged into the following branches: main

Nice catch Pawel!

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}