Current Behavior
In StepSlider.vue:54, the select method bails out entirely when disableNextStep is true:
select (key, disabled) {
if (this.disableNextStep) {
return
}
// ...
}
disableNextStep semantically means "the current step isn't complete, don't let the user advance." But the check blocks all step clicks, including going back to already completed steps. If you're on step 3 and the step isn't valid yet, you can't click step 1 or 2 either.
The guard should only block navigation when the target step is ahead of the current one (key > currentEntry).
Fixing that introduces a second problem. There's nothing preventing users from skipping intermediary steps entirely. MultiStepForm.selectStep just sets currentStepKey directly with no bounds checking:
selectStep (key) {
this.currentStepKey = key
}
So clicking from step 1 straight to step 3 would work as long as disableNextStep is false on step 1, bypassing step 2's validation completely.
Suggested approach
Phase 1: Track a "high water mark" of the furthest step the user has validly reached. Only allow navigation to steps up to that point. Any change on step N resets the high water mark back to N, forcing the user to re-walk through N+1, N+2, etc. This is intentionally blunt but safe.
Concretely this means:
- New state in
MultiStepForm (something like maxReachedStep) that increments as the user progresses forward via the Next button
- Pass it down to
StepSlider as a prop to gate which steps are clickable
- When a step emits an update (via step-updated), reset the high water mark to the current step
- Fix the
disableNextStep guard to only block forward navigation, not backward
*Phase 2 (follow-up)**: The blunt reset is too aggressive for forms where steps aren't all interdependent. For example, changing something in step 1 shouldn't force re-walking step 2 if step 2 has no dependency on step 1. This would introduce per-step dependency declarations so concrete form implementations can define which steps depend on which. A change on step N would then only invalidate steps that declare a dependency on it. The step definition format already supports disabled and hidden, so something like a dependsOn array or a validation callback per step could slot in there.
Expected Behavior
No response
Steps To Reproduce
No response
Environment
- FlowFuse version: 2.32.0
- Node.js version:
- npm version:
- Platform/OS:
- Browser:
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate
Current Behavior
In StepSlider.vue:54, the select method bails out entirely when disableNextStep is true:
disableNextStepsemantically means "the current step isn't complete, don't let the user advance." But the check blocks all step clicks, including going back to already completed steps. If you're on step 3 and the step isn't valid yet, you can't click step 1 or 2 either.The guard should only block navigation when the target step is ahead of the current one (
key>currentEntry).Fixing that introduces a second problem. There's nothing preventing users from skipping intermediary steps entirely.
MultiStepForm.selectStepjust setscurrentStepKeydirectly with no bounds checking:So clicking from step 1 straight to step 3 would work as long as
disableNextStepis false on step 1, bypassing step 2's validation completely.Suggested approach
Phase 1: Track a "high water mark" of the furthest step the user has validly reached. Only allow navigation to steps up to that point. Any change on step N resets the high water mark back to N, forcing the user to re-walk through N+1, N+2, etc. This is intentionally blunt but safe.
Concretely this means:
MultiStepForm(something likemaxReachedStep) that increments as the user progresses forward via the Next buttonStepSlideras a prop to gate which steps are clickabledisableNextStepguard to only block forward navigation, not backward*Phase 2 (follow-up)**: The blunt reset is too aggressive for forms where steps aren't all interdependent. For example, changing something in step 1 shouldn't force re-walking step 2 if step 2 has no dependency on step 1. This would introduce per-step dependency declarations so concrete form implementations can define which steps depend on which. A change on step N would then only invalidate steps that declare a dependency on it. The step definition format already supports disabled and hidden, so something like a
dependsOnarray or a validation callback per step could slot in there.Expected Behavior
No response
Steps To Reproduce
No response
Environment
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate