Poc for Generic typed Date Picker

[ArieGato]

Description

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[henon]

I think version 7.0.0 is the perfect time for this PR. With full test coverage of the different implementations of IDateOperations etc I see no problems. @ScarletKuro do you want to do a quick glance if the concept is sound?

[henon]

Just curious. Why did you design it like this DateOperations.WithDate(_picker_month.Value).IsMinDate() instead of extension methods IsMinDate() for different this types?

[ScarletKuro]

If we going to accept this solution, the IDateOperations and it's implementations should be internal, same to the injection of this service, I do not think that user needs to know about their existence and interact with them.
I also would expect the components to use ParameterState but this is optional, because MudPicker is using MudFormComponent which is not ParameterState friendly because of it's converters, and biggest design problem of it is that the value is implemented as

protected T? _value;

instead of

[Parameter]
public abstract T Value { get; set; }

and components are forced to do this:

[Parameter]
[Category(CategoryTypes.FileUpload.Behavior)]
public T? Files
{
	get => _value;
	set
	{
		if (_value != null && _value.Equals(value))
			return;
		_value = value;
	}
}

[henon]

@ArieGato We decided against generics and for just having two different bindable properties: #2954 (reply in thread)

Are you ok with that?

[ArieGato]

I think there are pro's and cons for both solutions.

My intentions were to bind the datepicker to a model without any conversions. The NumericField works simular to this.

I'm curious how the OneOf solution works out in usage.

And shouldn't we add DateTimeOffset support as well?

[henon]

And shouldn't we add DateTimeOffset support as well?

Ok, that seems to kill the Two-Properties-Solution

[danielchalmers]

And shouldn't we add DateTimeOffset support as well?

Ok, that seems to kill the Two-Properties-Solution

If the original binding was changed to DateTimeOffset it could implicitly support DateTime right? There's implementation details to work out but maybe that could work.

[ScarletKuro]

If the original binding was changed to DateTimeOffset it could implicitly support DateTime right? There's implementation details to work out but maybe that could work.

Technically, yes.

[ArieGato]

Reworked in branch https://github.com/ArieGato/MudBlazor/tree/feature/generic-datepicker

[henon]

Oh, you haven't created a PR yet. OK, we'll link once you do.

[ArieGato]

Continues in PR #9016