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

Discussed in https://github.com/CommunityToolkit/Maui/discussions/164

<div type='discussions-op-text'>

^{Originally posted by Countryen October 22, 2021} 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?</div>

Most important details from the discussion:

• The TargetNullValue of XAML’s Converter for bindings is applied to the result of the converter and not to the value before it goes in to the converter.
• Let the BaseConverterOneWay<TFrom, TTo> check for null and fallback to the default value for TFrom instead of throwing an Exception. (Suggested by @pictos )

• If we went with a blanket always replace nulls with default then that is a behavioral change but is still probably unlikely to have a big impact. If we added a way to opt-in as @Countryen suggested then it would have even less of an impact.

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

[bijington]

@Countryen that’s great you have been able to start on this. To answer your questions:

Some unit tests are already red for me in the DateTimeOffsetConverter_Tests. This is probably because I use a German system. If wanted I can report this in a separate issue.

If you could raise an issue that would be fantastic. Sadly we do have some inconsistent tests that we need to tidy up and I might see if I can get those sorted to reduce any friction for new contributors.

Also, I’ve noticed some small spelling errors (in the tests). Should I only fix the topic of this issue and ignore them? For example: BoolToObjectInValidValuesThrowArgumentException (I think it should be BoolToObjectInvalidValuesThrowsArgumentException, but only the missing t in Argument is what I see important).

Ideally if we can keep a PR limited to the scope of the issue/feature that is ideal as it makes it easier to review. If the tests are in the same area you are working though I see no reason why you couldn’t/shouldn’t fix typos like this.

Sadly, there is no test that uses the BaseConverterOneWay<TFrom, TTo>. The only classes that derive from this are the color conversion classes but they are not tested at all it seems.

So I will have to add a new unit test class like (ColorToRgbStringConverter_Tests) and add a test for the invalid arguments (like done in other test classes) where null should be possible.

If not wanted I can also just add a custom private implementation in the test class itself to test it.

I think adding a test like you suggest ColorToRgbStringConverter_Tests sounds like a good approach as it not only tests your new code but provides the ability to test pre-existing code that should have already been tested.

Thanks again for looking at this

[bijington]

@Countryen that is great thank you. To answer your questions:

Is it enough to create a PR and wait for automatic test runs or do I have to run tests locally on my device first?

Ideally we would like as much tested as possible. It is possible to run the unit tests locally if that helps and if changing behavior as we would be with this change additional unit tests would be great. Obviously not everyone has access to all device types (Android, iOS, etc.) so if you are not able to test some devices then just letting us know in the PR would be really helpful. That said this change is extremely unlikely to have platform specific issues.

Do I have to test MAUI and Xamarin Forms or only Xamarin Forms?

So this is where it may get a little bit more confusing but this issue is raised against the MAUI Community Toolkit and is completely separate to the Xamarin Community Toolkit. We will need to fix this in both toolkits to retain consistency but there is no expectation to provide both, just as much as you feel you can. If you are in a better position to test/fix for the Xamarin Community Toolkit then it would probably best to fix this issue. I just raised a copy of this issue against the Xamarin Community Toolkit to cover the change there.

Do you expect a working sample or unit test to be added?

Yes please. Given that you would be fixing something and not adding new functionality it should hopefully be possible to just tweak an existing page/unit test class to expose this new behavior rather than having to create something new. We are hear to answer any questions though if anything isn’t clear in what you would need to change 😄

In summary I think it would probably be best to look at the XCT issue first. What are your thoughts?

And of course please feel free to ask for guidance on any of these steps.