An `IValue Converter` is a way to modify a value that is provided via a binding. I rarely use them, but others use them frequently and find the experience to be less than ideal.
I stopped using them a long time ago (while still using Silverlight) because they had a significant and noticeable performance impact. The performance impact today isn't as noticeable, but I haven't gone back.
By not using them, I also realised that they make the code easier to test. The logic I was performing in the converter (the way the docs and conventions of the time encouraged) actually made more sense in the ViewModel. When the logic is all in the ViewModel I only have to test that. I don't need to have tests that run the app and manipulate the UI to verify the internal logic. (Yes, I test my MVVM code, and still have separate tests for UI verification--but not the internal application logic.)
That's me, but there are people who do create ValueConverters and don't feel happy about it.
There are two complaints that I hear frequently:
- The syntax is verbose.
- The need to create and initialize extra types seems unnecessary when all that is really needed is a static function.
This isn't such an issue for anyone using WinUI as that includes the `x:Bind` MarkupExtension which already supports the ability to call static functions as part of a binding.
So, if you had this class:
public static class Converter
{
public static string MakeUpperCase(string input)
{
return input.ToUpper();
}
// .. other functions
}
You could apply the function as part of the binding like this:
<TextBlock
Text="{x:Bind utils:Converter.MakeUpperCase(VM.Message)}" />
Yes, I'm using a trivial example throughout so as not to get caught up in the complexities of what the conversion function does and can instead focus on how it is used.
That's all well and good for WinUI code, but what if you're using .NET MAUI or WPF, where there is no x:Bind support?
Well, if what you want is the ability to provide a static function as part of a binding, why not create a MarkupExtension that does that? The X in XAML serves as a reminder of using something intended to be eXtended. Plus, this is software. If using a framework that doesn't provide the desired functionality, unless there's something preventing it, you can add it yourself.
So, why not create a MarkupExtension that behaves like a binding but also accepts a static function and automatically applies that to the value that is used?
It seems so obvious that I can't imagine why everyone isn't already doing this.
In this example, I've called by MarkupExtension "BossBinding" and it can be used like this:
<Label Text="{rx:BossBinding Message,
Converter={x:Static utils:Converter.MakeUpperCase}}"
/>
This is from a .NET MAUI app.
In all other ways, the BossBinding works and can be used like a regular Binding, but the Converter property takes a static function.
To make it as flexible as a ValueConverter, it requires a slightly more complex signature, but the contents of the function is what would go in the `Convert` function of a class that implements `IValueConverter` so it doesn't feel that complicated.
public static class Converter
{
public static Func<object, object> MakeUpperCase => (input) =>
{
if (input is string str)
{
return str.ToUpper();
}
return input;
};
// other functions
}
If wanting to be stricter about the types used in the conversion, a version of the static function and the property of the MarkupExtension could use types other than `object`.
To make this work for both .NET MAUI and WPF, it was necessary to have different implementations of the `ProvideValue` function. This was due to the differences between the two frameworks and the way they support bindings internally.
The XAML still ends up being the same.
For example, here's a snippet from a WPF app that does a similar thing to the above, but also uses a static method that accepts a parameter to set the text color based on the bound value.
<TextBlock
Text="{rx:BossBinding Path=Message,
Converter={x:Static utils:Converter.MakeUpperCase}}"
Foreground="{rx:BossBinding Path=Message,
ConverterWithParameter={x:Static utils:Converter.ChangeColor},
ConverterParameter=True}"
/>
The conversion function here is again very generic, matching what is done with an IValueConverter.
The code is also somewhat arbitrary and was created primarily as a quick way to demonstrate that this can work with parameters and return types other than strings.
public static Func<object, object, object> ChangeColor =>
(input, parameter) =>
{
if (input is string str
&& parameter is string parameterAsString)
{
if (bool.TryParse(parameterAsString,
out bool parameterAsBool)
&& parameterAsBool)
{
switch (str.Length % 3)
{
case 0: return Colors.Blue;
case 1: return Colors.Red;
case 2: return Colors.Green;
}
}
}
return Colors.Black;
};
That solves the second problem mentioned at the start, but what about the first (syntax verbosity)?
Maybe that's something ENAMEL can help with..
Am I going to use something like I've shown above regularly in future?
Maybe. I rarely use ValueConverters, so probably not.
It solves the problem of needing to create and instantiate custom types when all that's needed is a static function, but I still think it requires too much text in the XAML file.
Still, it's an option for anyone who prefers it. We don't all have to write code the same way, and there may be good reasons to sometimes need this.
If and when I do need to use a value converter, I prefer the automatic generation of MarkupExtensions based on the class implementing IValueConverter. I find it makes the required XAML much shorter and clearer.
It means that instead of having to write this in the XAML file:
<Label Text="{Binding Message,
Converter={StaticResource MakeUpperCaseConverter}}" />
I can write this:
<Label Text="{conv:MakeUpperCase Message}" />
But that's probably another post for another day.
I appreciate being reminded that there are simple ways to create something that solves a problem when you don't like what comes out of the box.
What I really reject is the idea that someone should complain about a limitation of a framework (which can never do everything that everyone might want or need) when there are simple solutions that any developer should be able to write themselves. I'm almost surprised that this is a situation where developers don't want to write code to solve a problem they're facing. Writing more code as the first solution is frequently something that developers need to be stopped from doing.
