It always again happens (especially in real world scenarios) that you need to configure your Angular app at runtime. That configuration might be fetched from some backend API, or it might be some simple JSON configuration sitting on your deployment server. The key here is that you want to be able to dynamically modify and adjust that configuration without the need to re-compile and re-deploy your application. Also, you most probably want that configuration to be loaded and ready once your application bootstrapping is done.
In this lesson we learn how to make use of the
APP_INITIALIZER to hook into Angular's initialization process. That will allow us to inject some configuration into our app just when it is about to start up.
A Community Resource means that it’s free to access for all. The instructor of this lesson requested it to be open to the public.
I missed the part why it cannot be an Observable. and also what is the difference comparing to "root" Resolver?
Hey. Hmm...maybe I should clarify the Observable thing better in the vid. The thing is basically that the initializer function that you return to Angular doesn't support Observables, but just Promises or plain returns. Described it here: https://juristr.com/blog/2018/01/ng-app-runtime-config/
What exactly do you mean with "comparing to the root Resolver"?
I'm not asking "Does it support observables or not?" :) I'm asking "Why the initializer function does not support them?"
for Router you can have a common parent route with Resolver Guard
Is missing an important part, maybe more server related, but the config asset should not be available from outside for security reason.
@Georg: Agree, here it really depends. You could have "public" configuration info, which is not sensitive to the current user's permission, and you may have "private" configuration information, which might be.
So in general, if you expose the configuration from some API, I usually filter the response based on the user's permissions. So if you call the configuration API before login, it might just return the publicly visible config which the app might need to adjust the UI etc...and once the user is logged in, another call to the config could then return further keys, which only matter to this specific user. Really depends on your use case.
In general, everything that's deployed with the frontend client, should not depend on the user's permissions of course, as it is visible from anyone that's able to access the app :)