Support configuration file for compile-time value management #184
Description
Proposal
I am looking at converting over some of our policies to the toolkit. In rate limiting cases we're currently using named values for things like rate limiting configuration.
First thing I found was that of course we can't use a named value (as far as I can see) in an int param without using an expression that guarantees an int type - but this results in old world having an attribute like renewal-period="{{my-named-value}}" to renewal-period="@(int.Parse("{{my-named-value}}")". Initially I thought some syntactic sugar on this so we can still get type safety would be neat, but then started thinking bigger.
It would be great if there were one place that I could define a set of values, e.g. in a traditional appsettings.json file, for values that don't change without a redeployment. This would allow centralized management of things like rate limiting durations that might be used in multiple policies without having to either hard code them into the c# definition (fragmented / harder to maintain) or rely on named values in the deployed instance (as they don't need to change between releases).
For example, let's say we had an appsettings.json file with content like:
{
"ratelimits": {
"renewalPeriod": 60
}
}Then have the ability to have some helper in the C# of a form like:
context.RateLimitByKey(new RateLimitByKeyConfig()
{
Calls = ...,
RenewalPeriod = ToolkitConfig.Get<int>("ratelimits:renewalPeriod"),
CounterKey = ...
});The output in the policy would be the expected:
<rate-limit-by-key calls="..." renewal-period="60" counter-key="..." />And in testing the above would be executable so the value can be obtained and tested against.
I would probably want such syntax to fail building if the property does not exist, or otherwise not convertible to defined type (i.e. in this case type is non-nullable, so null would throw).
What would be super awesome if the two concepts could then be combined, that I could put the {{my-named-value}} string in my JSON config file, the compiler would understand the string has appropriate {{ ... }} syntax so outputs it as expected, but ten in the testing framework / emulator I'd have a way in the mock context to define named values
Component
Authoring library
Contact Details
No response