That's a cool approach, I hadn't thought of using type providers for config. I guess that works quite well providing there is a type provider for the config source you're using. Are you able to deal with environment variables using that approach too, as I suspect they are about as common as JSON based configuration in most apps?
I have played with type providers for something else briefly and one thing I'm curious about is how they handle changes to the data post-compilation. Does it fail at runtime then, or does it still return you some kind of Result so that you're forced to check for errors at runtime too?
if you try out the linked repo you should see one possible way of safely using type providers. Type providers usually define a Type (Class), not an object (instance), the instance can be bind at run time (with Load function in JsonProvider case).
If you talk about changing configuration once the app has started (unique of IOption), that doesn't happen no, but we happily lived without it before dotnetcore, in most of use-cases, I generarlly don't need that "option" functionality for apps.
For environment variables, they are automatically overridden in the json file by aspnetcore, if they have a matching pattern, so that is also already covered by aspnet and works fine as the file is loaded for each environment.
That's for example how you would inject secrets and sensitive config for example, that also works fine with type providers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That's a cool approach, I hadn't thought of using type providers for config. I guess that works quite well providing there is a type provider for the config source you're using. Are you able to deal with environment variables using that approach too, as I suspect they are about as common as JSON based configuration in most apps?
I have played with type providers for something else briefly and one thing I'm curious about is how they handle changes to the data post-compilation. Does it fail at runtime then, or does it still return you some kind of
Resultso that you're forced to check for errors at runtime too?if you try out the linked repo you should see one possible way of safely using type providers. Type providers usually define a Type (Class), not an object (instance), the instance can be bind at run time (with Load function in JsonProvider case).
If you talk about changing configuration once the app has started (unique of IOption), that doesn't happen no, but we happily lived without it before dotnetcore, in most of use-cases, I generarlly don't need that "option" functionality for apps.
weblog.west-wind.com/posts/2017/de...
For environment variables, they are automatically overridden in the json file by aspnetcore, if they have a matching pattern, so that is also already covered by aspnet and works fine as the file is loaded for each environment.
That's for example how you would inject secrets and sensitive config for example, that also works fine with type providers.