SwipeArea: Real Time Swipe Support #11307
Conversation
Codecov ReportAttention: Patch coverage is
❌ Your patch status has failed because the patch coverage (69.23%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## dev #11307 +/- ##
==========================================
- Coverage 91.13% 91.12% -0.02%
==========================================
Files 439 440 +1
Lines 14238 14258 +20
Branches 2759 2763 +4
==========================================
+ Hits 12976 12992 +16
- Misses 635 639 +4
Partials 627 627 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Looks good, just need clarification regarding the |
|
In the swipe box, I noticed that if you move the mouse too quickly, it escapes the drag effect of the icon. I'm not sure if that's intended. |
Yes, i think its intended. Because swipe area is an "area", it's not designed for swiping itself. For complete drag ability, we need to combined (nested) swipe areas one as container and one as item. This way the connection never lost and we can tolerate the little rendering delay (that shouldn't be issue for this PR). It would be great if box drag immediately, but it look like rendering delay, because swipe doesn't miss the pixels, so it shouldn't be our fault.
Haha yes, that's why we added public cancel method and pointer leave event. Users can call cancel method in pointerleave to prevent further effects. |
|
I like this addition, thanks! I have a pending PR updating the SwipeArea docs #11223 and looks like we will have minor conflicts. My PR is ready to be reviewed/accepted if that's what we want - happy to change anything if needed. @mckaragoz @ScarletKuro |
| <DocsPage> | ||
| <DocsPageHeader Title="Swipe Area" Component="@nameof(MudSwipeArea)"> | ||
| <Description>Note: these examples only work on devices where touch events are supported.</Description> | ||
| <Description>Controls the swipe movement of a determined area.</Description> |
There was a problem hiding this comment.
I like your wording here.
In my PR I added an info alert: https://github.com/MudBlazor/MudBlazor/pull/11223/files#diff-67029bc53e1d988261a8d0377af01b42ca92f427536af8fec8132772de9d4006
But the wording is repetitive, maybe we should use my alert with your wording on the top instead of: "An area which..."
There was a problem hiding this comment.
Sorry a bit confusing, disregard above. On my PR I reverted the Note: line back to what it was before so that your PR can update the wording because mouse is now supported.
In my PR I just adjusted this: https://github.com/MudBlazor/MudBlazor/pull/11223/files#diff-38160f09a01b7906aba6a2c5cda0a6d620df8d515366ed79b375b87cd007959a
to remove the touch events wording
So if my and your PR get accepted it would read:
Swipe Area
An area which receives swipe events. (From my PR)
Controls the swipe movement of a determined area. (From this PR)
Thanks to @ScarletKuro for pointing that out
There was a problem hiding this comment.
I think you can just update your PR
This message is old and will be fixed in: MudBlazor#11307
|
|
Ideally, |
If i understand true, we can't bypass the OnPointerMoveAsync, all requests should stack with or without debounce. As an another approach, we can set Sensitivity parameter also for the pointer move, so it only triggers custom event when pointer move reach to sensitivity point (example run the method for each 5px move instead of each move). |
Description
Current
MudSwipeAreahasonpointerdownandonpointerupevents that calculate the swipe direction and delta. But this doesn't help when user wants to do something during swipe. We addedonpointermovesupport for real time scenarios. Here is the docs example that calculates swiped pixels on real time:20250508_110207.mp4
Current design only supports one-dimension swipe with
SwipeEventArgs. For real time movement, it's not sufficient, because when you make a diagonal swipe, you lost the x-axis or y-axis movement. So we enhanced this and addedMultiDimensionSwipeEventArgsforOnSwipeMove. The old SwipeEventArgs remains for the pointer down and up, its sufficient for them. So the PR does not bring a breaking change.Tests & Examples
Precision Test
Swipe should be consistent. This example shows a swipe that goes from one corner to another and turns back. So the swiped values should be the same. And here is the results: No missing pixels.
20250508_110252.mp4
Performance Test
Swipe also should have same performance on swipe faster. Here is an example that swiped very slowly on first time and faster next times. The results are same: There is no missing pixels on fast swipe.
20250508_110348.mp4
What We Will Gain
This enhancement is a main infrastructure for lots of components. We can use for our drag drop logic, can make our own scrolling mechanism and more. We added an tiny example in docs that what real time swipe should achieve:
20250508_110417.mp4
Type of Changes
Checklist
dev).