When you develop a bigger application, chances are quite high that you need some kind of configuration. That can range from simply visualizing the ...
For further actions, you may consider blocking this person and/or reporting abuse
this seems like it would work fine (quick&dirty) , but it seems like a way around using the app initializer, which works great btw :)
a good article about it:
davembush.github.io/where-to-store...
Hi, actually my post describes just that. Using the static compile time approach and the dynamic runtime approach which uses the app_initializer 😉
oh my, totally missed the Read more lol :)
🙈 😅 haha sorry for that.
I just have to ask what your color-scheme plugin you're using in your vscode first image?
Oh 😅 it's an old screenshot so I'm not 100% sure, but as far as I remember it should be the material theme I guess.
Nowadays I mostly switch between Night Owl & Night Owl Light + FiraCode as the font 🙂
When would you have (or what type of) work in the constructor vs app_initializer?
Well the APP_INITIALIZER starts before the app boots. If you place work in the constructor of say your app component, it'd be very similar. But I find it more clean in the app_initi... as it's meant for this type of work 🙂
Yeah I agree. Any work should be done via app_init. I find it weird to have any code in a module's ctor. I struggled to find an argument not to do work in the ctor
How would you do if every feature had a switch for dev and prod?
That's more of a use case for feature toggles (there are a couple of libs out there). But in the end, the feature toggle config could be downloaded via this runtime config I describe in the post & then processed.
The various configs for dev, prod etc...is something the server needs to give you at disposal.
Either via a static json deployed by the CI, or via an API etc..