Validators on RadzenSteps not/only partial working #1771

New Issue

claunia · 2026-01-29T17:58:21Z

claunia commented

2026-01-29 17:58:21 +00:00

Originally created by @Anspitzen on GitHub (May 19, 2025).

Describe the bug
When using the RadzenSteps to guide Users through a more expansive Form Validators will (by design of Blazor) only be working when the Step is loaded into UI

Additional context
When enclosing the Steps in a TemplateForm the "next" will trigger Validation of context. Also happening when you try to jump forward on the Steps from a validation context.
Both variants to go further will fail when a Validator fails.
But if you go from Step 1 directly to Step 3 it will not validate the validators on step 3 (as it is not rendered on Blazor and thus not existent at all on context to validate)

To Reproduce
Steps to reproduce the behavior:

Create Steps with 3 Items
Enclose the Steps component with a valid TemplateForm for InputValidation
Set one Input with Validator on step 2
Go from Step 1 to step 3 directly without entering anything inside the Step 2

Minimum working example for your demo page:

@inherits DbContextPage
<RadzenTemplateForm TItem="Order" Data="_task" Context="task">
<RadzenSteps>
    <Steps>
        <RadzenStepsItem Text="Step 1">
            Nothing in here
        </RadzenStepsItem>
        <RadzenStepsItem Text="Step 2">
            <RadzenTextBox Name="toValidate" @bind-Value=@binding />
            <RadzenRequiredValidator Component="toValidate" />
        </RadzenStepsItem>
        <RadzenStepsItem Text="Step 3">
            Nothing in here either
        </RadzenStepsItem>
    </Steps>
</RadzenSteps>
</RadzenTemplateForm>
@code {
Order _task = new();
string binding;
}

Expected behavior
A more consistent way for Validation to not validation because not rendered. Probably by preventing skipping steps forward.

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Alternatives and more additional:
The CanChange EventCallback has the same problem, when going from 1 to 3 it will not validate against step 2, as index is 1 and on first showing it needs to be able to go to 2 to even enter anything there.
The StepsCanChangeEventArgs also only give Next Index on both Properties (SelectedIndex and NewIndex) according to the xml-docu-tooltip and the link to the source is broken.
Also generally highly inefficient to use and maintain as I would need to duplicate the validation from the RadzenValidators again on that methode. Makes too big a line for being practical when working with slightly larger Forms.

Originally created by @Anspitzen on GitHub (May 19, 2025). **Describe the bug** When using the RadzenSteps to guide Users through a more expansive Form Validators will (by design of Blazor) only be working when the Step is loaded into UI **Additional context** When enclosing the Steps in a TemplateForm the "next" will trigger Validation of context. Also happening when you try to jump forward on the Steps from a validation context. Both variants to go further will fail when a Validator fails. But if you go from Step 1 directly to Step 3 it will not validate the validators on step 3 (as it is not rendered on Blazor and thus not existent at all on context to validate) **To Reproduce** Steps to reproduce the behavior: 1. Create Steps with 3 Items 2. Enclose the Steps component with a valid TemplateForm for InputValidation 3. Set one Input with Validator on step 2 4. Go from Step 1 to step 3 directly without entering anything inside the Step 2 Minimum working example for your demo page: ``` @inherits DbContextPage <RadzenTemplateForm TItem="Order" Data="_task" Context="task"> <RadzenSteps> <Steps> <RadzenStepsItem Text="Step 1"> Nothing in here </RadzenStepsItem> <RadzenStepsItem Text="Step 2"> <RadzenTextBox Name="toValidate" @bind-Value=@binding /> <RadzenRequiredValidator Component="toValidate" /> </RadzenStepsItem> <RadzenStepsItem Text="Step 3"> Nothing in here either </RadzenStepsItem> </Steps> </RadzenSteps> </RadzenTemplateForm> @code { Order _task = new(); string binding; } ``` **Expected behavior** A more consistent way for Validation to not validation because not rendered. Probably by preventing skipping steps forward. **Desktop (please complete the following information):** - OS: [e.g. iOS] - Browser [e.g. chrome, safari] - Version [e.g. 22] Alternatives and more additional: The CanChange EventCallback has the same problem, when going from 1 to 3 it will not validate against step 2, as index is 1 and on first showing it needs to be able to go to 2 to even enter anything there. The StepsCanChangeEventArgs also only give Next Index on both Properties (SelectedIndex and NewIndex) according to the xml-docu-tooltip and the link to the source is broken. Also generally highly inefficient to use and maintain as I would need to duplicate the validation from the RadzenValidators again on that methode. Makes too big a line for being practical when working with slightly larger Forms.

claunia closed this issue

2026-01-29 17:58:21 +00:00

claunia commented

2026-01-29 17:58:22 +00:00

@akorchev commented on GitHub (May 20, 2025):

Hi @Anspitzen,

We are not aware of any way to conditionally disable validation. Did you try using the Disabled property of RadzenStepsItem? A disabled steps item will not navigate.

@akorchev commented on GitHub (May 20, 2025): Hi @Anspitzen, We are not aware of any way to conditionally disable validation. Did you try using the Disabled property of RadzenStepsItem? A disabled steps item will not navigate.

claunia commented

2026-01-29 17:58:22 +00:00

@Anspitzen commented on GitHub (May 20, 2025):

As for disable a validation conditionally: I just set the Visable Property for the Validator. Same principle like with the steps: If it is not rendered by Blazor it is not executed on validation call on context.

But to navigate to the next step it needs to be Enabled. Going back is always possible without triggering validation, only going further will trigger it. Which is also the preferred way. So going to the step and unlocking the next one will make it really hard to prevent skips.
I did try with, if they went there the first time, the whole validation is triggered before they go further. So going back then is no problem, as then there is a vaild value given, if they want to change it they need to go to the corresponding step and change it there (with validators active). But then it is unlcoked before input, go back one step and just skip the 2nd
But I can't think of any way to block going further without opening the way for skip. If I Disable the step further the next is not working, so also not triggering validation. If I unlock the next step when ariving at step2, then I can go back to step 1 (no validation preventing my navigation). But then Step 3 is unlocked as I was on step 2 and I can jump forward. Just Disable Step with the validations is again redundant programming, which is not the way to go.

Possible, but unefficient, would be a something like the steps flickering through all other steps between current index and target index for validation. like an automated load next, try clicking next, repeat until target. That would stop the navigation at a invalid step but allow for jumping forward without having to click the next link all the time.

Probably the best way to do for now is locking Steps based on current index. So Disabled = currentIndex + 1 < StepIndex.
EDIT: to make the problem more appearent: Example is a checkout on a imaginary webshop:
I ask for payment methode. If it is a credit card I will need an additional step to ask for the credit card number. If it is in cash I won't need the step for payment anymore. But I will need to validate the creditcard if it is asked.
Now it is hard to set the Disabled for the Address part after the payment selection as depending on the selected methode (and thus amount of steps) it will be index 1 or 2. So saying SelectedIndex < 2 will block checkout as there is no index 1 before when user selects cash, but saying < 1 will allow skipping credit card infos ... So a bit hard to make in highly variable Forms
That will be middle ground between Locking navigation with steps completely and allowing jumpng wantonly. Only jump back, forward only with next. Even if then any peek back the user has to repeatedly click forward again. Which will mark the forward text by the browser, as is is an -text and not a button.
Maybe worth opening a feature request for making the Next/Previeos "buttons" customizable. Then the problem with marking by double click will be solved also and it will not cause inconvenience to the user. Also may make the buttons more visible, and make it possible to switch Button to a "Send data" Button at the last step instead of a useless "Next" ...

@Anspitzen commented on GitHub (May 20, 2025): As for disable a validation conditionally: I just set the Visable Property for the Validator. Same principle like with the steps: If it is not rendered by Blazor it is not executed on validation call on context. But to navigate to the next step it needs to be Enabled. Going back is always possible without triggering validation, only going further will trigger it. Which is also the preferred way. So going to the step and unlocking the next one will make it really hard to prevent skips. I did try with, if they went there the first time, the whole validation is triggered before they go further. So going back then is no problem, as then there is a vaild value given, if they want to change it they need to go to the corresponding step and change it there (with validators active). But then it is unlcoked before input, go back one step and just skip the 2nd But I can't think of any way to block going further without opening the way for skip. If I Disable the step further the next is not working, so also not triggering validation. If I unlock the next step when ariving at step2, then I can go back to step 1 (no validation preventing my navigation). But then Step 3 is unlocked as I was on step 2 and I can jump forward. Just Disable Step with the validations is again redundant programming, which is not the way to go. Possible, but unefficient, would be a something like the steps flickering through all other steps between current index and target index for validation. like an automated load next, try clicking next, repeat until target. That would stop the navigation at a invalid step but allow for jumping forward without having to click the next link all the time. Probably the best way to do for now is locking Steps based on current index. So Disabled = currentIndex + 1 < StepIndex. EDIT: to make the problem more appearent: Example is a checkout on a imaginary webshop: I ask for payment methode. If it is a credit card I will need an additional step to ask for the credit card number. If it is in cash I won't need the step for payment anymore. But I will need to validate the creditcard if it is asked. Now it is hard to set the Disabled for the Address part after the payment selection as depending on the selected methode (and thus amount of steps) it will be index 1 or 2. So saying SelectedIndex < 2 will block checkout as there is no index 1 before when user selects cash, but saying < 1 will allow skipping credit card infos ... So a bit hard to make in highly variable Forms That will be middle ground between Locking navigation with steps completely and allowing jumpng wantonly. Only jump back, forward only with next. Even if then any peek back the user has to repeatedly click forward again. Which will mark the forward text by the browser, as is is an <a>-text and not a button. Maybe worth opening a feature request for making the Next/Previeos "buttons" customizable. Then the problem with marking by double click will be solved also and it will not cause inconvenience to the user. Also may make the buttons more visible, and make it possible to switch Button to a "Send data" Button at the last step instead of a useless "Next" ...

claunia commented

2026-01-29 17:58:22 +00:00

@Anspitzen commented on GitHub (May 20, 2025):

As for marking it down as a possible (if somwhat convulted) way of forcing only forward with allowing jumps back on a dynamically visible Steps list:

@code{
private RadzenSteps RadzenSteps { get; set; }
private RadzenStepsItem Step1 { get; set; }
private RadzenStepsItem Step2 { get; set; }
private RadzenStepsItem Step3 { get; set; }
private RadzenStepsItem StepMaybe4 { get; set; }
}

Does work, but I have to pull out all the steps and name them. So not working for fully dynamic generation of steps.

@Anspitzen commented on GitHub (May 20, 2025): As for marking it down as a possible (if somwhat convulted) way of forcing only forward with allowing jumps back on a dynamically visible Steps list: <RadzenSteps @bind-SelectedIndex="_currentInex" @ref=@RadzenSteps> <Steps> <RadzenStepsItem @ref=Step1 Text="Step 1"> <RadzenStepsItem @ref=Step2 Text="Step 2" Visible="@(Step2Visible)" Disabled=@(_currentInex < RadzenSteps.StepsCollection.IndexOf(Step2) - 1)> <RadzenStepsItem @ref=Step3 Text="Step 3" Visible="@(Step3Visible)" Disabled=@(_currentInex < RadzenSteps.StepsCollection.IndexOf(Step3) - 1)> <RadzenStepsItem @ref=StepMaybe4 Text="Step Maybe 4" Visible="@(Step4Visible)" Disabled=@(_currentInex < RadzenSteps.StepsCollection.IndexOf(StepMaybe4) - 1)> </RadzenStepsItem> </Steps> </RadzenSteps> @code{ private RadzenSteps RadzenSteps { get; set; } private RadzenStepsItem Step1 { get; set; } private RadzenStepsItem Step2 { get; set; } private RadzenStepsItem Step3 { get; set; } private RadzenStepsItem StepMaybe4 { get; set; } } Does work, but I have to pull out all the steps and name them. So not working for fully dynamic generation of steps.

claunia commented

2026-01-29 17:58:22 +00:00

@akorchev commented on GitHub (May 20, 2025):

I don't think we can offer a better solution than the Disabled property to be honest. I am closing it as there is nothing actionable we can do for now.

@akorchev commented on GitHub (May 20, 2025): I don't think we can offer a better solution than the Disabled property to be honest. I am closing it as there is nothing actionable we can do for now.

claunia referenced this issue

2026-01-29 18:20:56 +00:00

[PR #1771] [MERGED] Add callback for Open and Close to RadzenDropDown #2892

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/radzen-blazor#1771