Add ParameterInfo of Source to ConverterContext to help IInputConverter implementations #3193
Description
Description
Feature request
When using IInputConverter you only get the following information:
- FunctionContext
- Properties (often, if not always empty or unused)
- Source
- TargetType
Having additional information about the Source like ParameterInfo will give more capabilities and help out special scenario's like when an input has attributes assigned. (Could even lead to not needing a azure custom FromBody?)
Details
When dealing with most basic conversions you are fine with the information at hand, but take httptriggers as an example there can be a lot of quirks if you are coming ASP.NET Core.
And you might want to add attributes or need to know a bit about the target parameter to handle them better.
Motivation
For basic conversions, the current context is sufficient. However, when working with HTTP triggers and aiming for ASP.NET Core–like flexibility when coming from that field, limitations quickly surface.
Example, I’ve implemented a CustomAspCoreExtendedInputConverter that mimics Minimal API behavior for conversions and it supports types like ISpanParsable and IParsable. But when using custom attributes or even existing ones like FromQuery, FromHeader, or FromRoute, the lack of ParameterInfo becomes problematic — you cannot get the information from them.
With the existing three it is even easier to notice, if someone tries to use the Name property than they will quickly notice that does not work at all, the parameter name must match what you get from the Uri, and without access to parameter metadata you cannot fix this in a singular inputconverter, you need to make custom a FromQuery version.
This can actually be seen with FromBody, a custom dedicated attribute and converter is provided in the Azure sdk because otherwise would not be possible. If ParameterInfo were available, similar functionality could be implemented in a singular converter for all of them and mayhap even make the FromBody from the azure sdk obsolete.
##Additional notes##
Regarding FromQuery, FromHeader, and FromRoute: ideally, these should be handled and form a different layer in the code, but didn't get time to go deep enough to where that is all handled in current situation and not even sure if possible due to quirks on how the FunctionContext is filled for HttpRequests. (like BindingData property can be corrupted)
But until that’s addressed, exposing ParameterInfo in IInputConverter would serve as a practical workaround and unlock much-needed flexibility to get it working from there without a custom variant.