-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the usage experience with IsInRangeConverter in XAML #1983
Improve the usage experience with IsInRangeConverter in XAML #1983
Conversation
Updated unit tests to be cleaner
Validate that the MinValue and MaxValue types can be converted to the valueType.
Note that I would need to update the DOCs, so this should be blocked until the docs are ready. |
This also "Needs Discussion" label added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GeorgeLeithead thank you for this! Apologies for the delay in reviewing this. I have added a number of comments, some improving existing bits (xml docs) and others just to confirm my understanding. I like the concept.
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
src/CommunityToolkit.Maui/Converters/IsInRangeConverter.shared.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Shaun Lawrence <shaunrlawrence@gmail.com>
Co-authored-by: Shaun Lawrence <shaunrlawrence@gmail.com>
Co-authored-by: Shaun Lawrence <shaunrlawrence@gmail.com>
Co-authored-by: Shaun Lawrence <shaunrlawrence@gmail.com>
Removed unnecessary checks Removed no longer used method.
Updated tests to use correct exception thrown then using incompatible TValue objects.
src/CommunityToolkit.Maui.UnitTests/Converters/IsInRangeConverterTests.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this @GeorgeLeithead
Are we sure that removing the all of the This means that users can no longer bind to any of the following properties from the VIewModel:
Personally, I'd prefer that we keep the bindable properties unless someone with more XAML knowledge can help me understand. |
That was my initial thinking but I struggled to get input on this. |
Let me put them back so we can merge this in |
I have some comments to make on this. Well do so tomorrow. |
Um.. Ok, too late to add my 2-pennies... but...
So, I think the big question in reality is: Should we either adhere to the same standard and NOT have bindable properties, or should we add bindable properties to all [appropriate] converters? If the former, then I don't think we should have bindable properties on this converter. If the latter, then IMO a bigger PR should be undertaken, and at the (very IMO) VERY LEAST additional Unit Tests should have been added BEFORE we approved the PR. Thoughts? @bijington @brminnick, et all? (Should this be an open discussion on Discord, instead of against the PR?) |
I agree that we should consider the bigger picture on whether all or no converters should have BindableProperty's or none. I don't agree that additional tests should have been added before this PR merged, the point that I believe is important is that the PR was removing functionality by removing the BindableProperty definitions, the last change was just to prevent this loss of functionality - this wasn't adding new functionality that needed to also be tested. Although in truth those tests should have existed which would have caught this loss of functionality but hindsight is a wonderful thing. I completely agree with the below statement and thank you for improving it
The above is still true with the retention of the BindableProperty's. But to come back to the original point, I agree that we should discuss whether all or no converters should have bindable properties and we consider the risk of breaking people based on the outcome. |
Description of Change
When initially written, the
IsInRangeConverter
usedCompareConverter
as a guide/basis. Since then, theCompareConverter
has been changed to improve the usage experience in XAML. See #1841 for details.This PR brings the
IsInRangeConverter
back into alignment with theCompareConverter
, in terms of implementation.The current use of the converter is as follows:
If a developer tries to write
MaxValue="7"
, and thevalue
for the converter is aDouble
, the user will not get any valid results from the converter. In XAML, theMaxValue="7"
has a type ofString
, by default.This PR makes it possible to define what type
MaxValue
andMinValue
should be when inheriting from the converter, based on thevalue
.Converter definition
XAML Usage
I have also removed the un-used
CompareValue
property.I think that this will make is easier for users to use, and eliminate any confusion about XAML defaulting to
String
for this control.Linked Issues
PR Checklist
approved
(bug) orChampioned
(feature/proposal)main
at time of PRAdditional information