Change the code for the BindConverter class used on binding so that it's integrated with Dependency injection

[luisabreu]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Hello.

Currently, the default Blazor controls (ex.: InputText, InpuetSelect, etc.) don't play when they're bound to objects (instead of simple properties). The current version ends up delegating to a TypeConverter which is responsible for handling the conversion to and from strings. The problem with this approach is that type converters must have a default parameterless ctor so you cannot use the default dependency injection for injecting eventual dependencies used by the typeconverter.

Describe the solution you'd like

Create a custom type which allows conversion to be performed and that is integrated with Blazor DI.

Additional context

No response

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[halter73]

It might make sense to add support for BindAsync(HttpContext) (and TryParse) to Blazor similar to what we have for minimal APIs and MVC which would allow the binder to use services from HttpContext.RequestServices. The downside is that the type being converted needs to have a public static BindAsync method on itself rather than some other class. Would that work for you scenario @luisabreu?

[luisabreu]

In my case, that would not be a problem...but why not add a new interface which defines the contract for converting to and from string and change the control's internals so it tries to get an instance of that type from the services? I think that having a different type implement the conversion is better that forcing the type to have a bindasync method...

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[BrunoJuchli]

In my case, adding code to the type which needs to be converted is not an option. Example: I want to bind to an Option<T> type defined in an external library (language ext). The Option<T> has two states: either it has a value, or none (so it's similar to T?).

T then can be one of our domain models/value objects, let's say we have record Username(string Value) (it does have logic, which is one rationale for it to exist - the logic, I'm leaving out here, for simplicity).

A conversion from value to string would look like:

option.Match(
    x => x.Value,
    "No username specified");

Now, like I said, I can't add this code to the Option<T> object because it stems from a third party library. I cannot even add a TypeConverterAttribute for that matter. I don't even know if Blazor (Client) supports globally registering these attributes. In WPF this is how I dealt with cases like these.

Injecting dependencies into converters is a feature I would have used in earlier UI too (WPF, where it was missing, too). The workarounds are not nice :/ So I second this feature request. Thank you for your consideration.

---

Side note: from past experience, once we moved our domain objects to the VM instead of converting these to primitives, our code got much easier to understand and work with. Wherever possible we did this. Only downer was, that due to WPF limitations, there was some cases where it was not practical. So it was sometimes a bit of an akward mix, which at the beginning also made us doubt whether we should go this way. We did, though, an after practicing this for about 2-3 years, we were still happy with it, and considered it a significantly better approach. However, without limitations this would have been just awesome, and basically a no-brainer.