-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
MudStepper: ResetAsync now sends correct StepAction arg #10341
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
Conversation
While I'm not familiar with this component, based on the comment on the method you updated, setting comment: What exactly was the bug you experienced? It may be worth providing more details on what the bug is (possibly with an associated image) and what the end result looks like now with the fix you implemented. Additionally, there should be tests added to ensure that a similar bug isn't reintroduced (especially as this appears to be intentional) |
The bug was presenting itself when I used OnPreviewInteraction="OnPreviewInteraction" with ShowResetButton My method:
StepAction.Activate is not useful when reset is pressed. If you press back then it is useful but for reset you expect to be able to trigger a different method to pressing back and actually reset all steps. In my case this was a text field which would retain its value when reset was hit. With StepAction.Reset I am now able to have it clear that text field when reset is clicked, along with all other values in on all pages. This seems much more likely the intended purpose. |
@jgoday I concur. A testcase is strictly necessary though to prevent other PRs from unintentionally breaking this functionality. |
Reset would activate the first step after it is done, right? So after a |
If everyone is happy with my findings and feels it is now following the correct logic let me know in the comments and I'll find time later to write some unit tests for this. No point writing tests if my idea of the logic is wrong if you get my drift. |
This actually confirms everything we discussed. All steps are reset and then the first is activated. You can go ahead and write the test. I am only confused by your screenshot, there shouldn't be any errors after reset IMO. Is this another bug? |
I think there is maybe another bug depending on intention as stage 1 and 2 are in error state from a fresh load too so reset is putting everything back as it should, but maybe stage 1 and 2 should not show the error icon until you have tried to continue. I'll write some tests around my original bug when I get 5 minutes later today and if we get clarification over when then exclamation should be visible I will be happy to write a bug report for that and possibly pick up the work putting that right some day soon. |
Sounds good. I remember something in the back of my head when I worked on the component, thinking that a |
I've added tests for this bug. I probably could have gotten away with updating the single controlled navigation test but I thought it best to go all in, belts and braces and what not |
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #10341 +/- ##
==========================================
- Coverage 91.48% 91.42% -0.07%
==========================================
Files 415 418 +3
Lines 13053 13226 +173
Branches 2473 2538 +65
==========================================
+ Hits 11942 12092 +150
- Misses 548 554 +6
- Partials 563 580 +17 ☔ View full report in Codecov by Sentry. |
|
||
await UpdateStepAsync(_steps[0], new MouseEventArgs(), StepAction.Activate); | ||
await UpdateStepAsync(_steps[0], new MouseEventArgs(), StepAction.Reset); | ||
} |
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.
Sorry for not looking at the code sooner. I think that the line you changed was actually correct. After all, after the reset we want to activate the first step. I assumed we'd do something like this:
foreach (var step in _steps)
{
//await step.SetCompletedAsync(false, refreshParent: false);
//if (resetErrors)
//{
// await step.SetHasErrorAsync(false, refreshParent: false);
//}
await UpdateStepAsync(steps, new MouseEventArgs(), StepAction.Reset);
}
await UpdateStepAsync(_steps[0], new MouseEventArgs(), StepAction.Activate);
and move the commented code into UpdateStepAsync()
to be executed only if the step action is Reset
.
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.
Have a play with the code I have changed. It works beautifully as expected in my business use case. I can't see any other logical way this should work. In my scenario reset will be caught as a unique action. I can choose to set var values back to original value etc and the stepper goes back to the first action as if I had hit f5 to refresh
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.
Maybe you are right. It is certainly a working solution, if a bit implicit.
However, my concern was to make it work not only for your use-case but for every possible one. What if we later need to add a way to reset only single steps as opposed to the whole stepper? Then it might be breaking for you if we send a reset for just one step and you would implicitly assume the whole stepper was reset. I know "what if" arguments don't always make sense and are certainly a way to derail every design discussion, just trying to make sure we don't add any roadblocks.
I also get that it would be hard for you to distinguish between a full reset and a partial reset so I guess what I suggested above (sending a reset for every step on Reset()
) is also not ideal.
I would do this: Let's rename StepAction.Reset
to StepAction.ResetAll
. This way it is clear that this is a full reset even if only the first step is sent with it (and we can always add StepAction.Reset
later if needed for individual step resets). And I also suggest sending the original StepAction.Activate
after sending the reset because it would be just inconsistent not to send it, the step is activated after all.
Does that sound good?
@henon what is the status of this? |
Waiting on a reply to this: #10341 (comment) |
I'll make some changes. Sorry, Christmas got in the way and now I'm back in to coding. Will get some actual work out of the way and find 5 minutes to make a nice solution. |
Updated with solution that I think we can all agree on. |
|
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.
OK, great. Thanks!
Description
Resolves bug where pressing reset in Stepper component pushed StepAction.Activate rather than StepAction.Reset
How Has This Been Tested?
Using the library at work and this bug was causing a lot of grief. Cloned repo, fixed bug and tested in our codebase. Now sending the correct action.
Type of Changes
Checklist
dev
).