[Closed] Allow handling of null for Convert of BaseConverterOneWay<TFrom, TTo>

[Countryen]

The base class for IValueConverter BaseConverterOneWay<TFrom, TTo> provides many features/benefits but doesn't allow overriding or defining what happens when a null is passed into the Convert method.

It would be very nice if it was able to either override or define the type/value checking or to set a "allows null" for the value.

This helps using converters with strings that can also be null.
Is there a better solution?

[TheCodeTraveler]

Thanks @Countryen!

It's certainty feasible, but I'm struggling to think of scenarios where null would be a useful for converters.

Does XAML handle null differently for certain scenarios?

What's an example where XAML would prefer null instead of string.Empty or byte[] or Color.Default?

[Countryen]

Thanks for the reply @brminnick.

XAML doesn't care about null, I think.
Using a binding to property like "Name" with a value of null will just result in string.Empty - but this is not the case when using a converter.

See the following snippet:
<Label Text="{Binding Name}" TextColor="{Binding Name, Converter={StaticResource NameToColorConverter}}" />
When this bound property (string) Name is set to null at any time, this crashes because of the (base) converter's check for null.
XAML doesn't send string.Empty to the converter but null.

It's the same when you bind to something like "Person.Name" and the person is null -> Name will also be null

Of course, you could try to ensure the Name is never null, but that's not always possible/easy.
It'd be easier to implement the converter like this if there was a way to allow null.

public override Color ConvertFrom(string name)
{
	return name switch
	{
		"John" => Color.Red,
		"Lisa" => Color.Blue,
		null => Color.Purple,       // <- This is the self handled null case.
		_ => Color.Black
	};
}

Above is possible with a custom implementation of IValueConverter but not with an extension of the nice BaseConverterOneWay.

I've found no way to ensure that the "Name" property isn't null by only using the page/view (XAML) since there is no Simple Name ?? string.Empty in XAML. Neither the FallbackValue nor the TargetNullValue nor the StringFormat seem to make a difference.

So by (optionally, with opt-in) allowing to handle null cases by the converter would much improve the usage in XAML when binding to strings or other properties that might be null.

Note that this experience comes from using Xamarin.Forms 5 not MAUI but I can't open anything in Xamarin.Forms repo so I thought it'd be better to try make this possible in MAUI instead.

[bijington]

Thank you for the clarification I have just learned that the TargetNullValue is applied to the result of the converter and not to the value before it goes in to the converter. For some reason I assumed it would be applied before going in to the converter.

Any further tests I have quickly tried appear to fail miserably because of this line in the base converter class:

if (value is not TFrom valueFrom)
    throw new ArgumentException($"value needs to be of type {typeof(TFrom)}");

It basically cannot convert from null to the TFrom type and therefore throws runtime exceptions.

One suggestion from the team (@pictos) was to check for null and fallback to the default value for TFrom.

@Countryen do you think this approach would help solve this problem? If so would you be willing to write up a proposal for the change?

[TheCodeTraveler]

Quick question - is this a bug fix or a new feature?

A bug fix could be implemented pretty quickly, whereas new features have to follow the New Feature Proposal workflow

[pictos]

Just open a bug issue here, adding the information that you posted here (:

[bijington]

@Countryen great thanks! If you look on the right bar there should be an option to Create issue from discussion. This will link to this discussion.

This would then mean that the actual custom converter's ConvertFrom(TFrom value) is called with default(TFrom) when value is null, am I right? We could then add a null check to return something the view can use.

Yes that is correct 😄

[Countryen]

I've added issue #184 for this, do I have to close this discussion now?

[bijington]

Thank you. You shouldn't need to close this, I think we somehow mark them as answered but I can't work out how to do that yet. I'll try and work it out and do that

[TheCodeTraveler]

We can only mark Q&A Discussions as answered.

I'll prepend [Closed] to the title so that folks know that this discussion is closed 👍

[CliffAgius]

Closed as part of clean-up.