We now have the possibility for custom action buttons. This is the last major missing piece. I think we can merge it as experimental like this.

Will add some more tests.

Big thanks to @fondraco for making the stepper. I did just polish and wrote all the tests.

Love the idea as an experimental component. Things I noticed:

Can't use Next button after reaching end

No padding between hover effect and text below (effect should be shrunk)

Each section is a div with role=tab but I believe it should semantically be a button

-<div class="mud-stepper-nav-step active mud-ripple" role="tab" [...]>
+<button class="mud-stepper-nav-step active mud-ripple" role="tab" [...]>

NonLinear should be Linear=false as per previous efforts for inverted names?

AlternateLabel not descriptive. Could be CenterLabels, LabelPosition, etc?

Not fluid when there's too many items

Could hide labels when it gets too wide (and then start turning center steps into dots)

Consider icons (FirstPage, NavigateBefore, NavigateBefore, NavigateNext)

Warnings are positioned different than ToggleGroup

Awesome review @danielchalmers, thanks a lot. Can you help me with the visual stuff? If not we'll put it on a todo list with the rest of the things to do them in a follow-up PR.

In this PR I think I will solve these:

• Next-button problem (fixed by also not showing previous button if completed)
• Warning positioning in the docs
• NonLinear -> Linear
• Better name for AlternateLabel ... CenterLabels
• Display "Complete" instead of "Next" on the last step
• Merge examples Vertical Stepper and Non-Linear Vertical Stepper

Things for a follow-up PR:

• No padding between hover effect and text below (effect should be shrunk)
• Each section is a div with role=tab but I believe it should semantically be a button
• Not fluid with many steps
• Hide labels or even steps if too many steps
• Icons for the action buttons
• Make sure the action button Icons work with RTL
• Customization example: Improve the action buttons (i.e. disable previous or next in certain situations, etc)
• Docs: make some of the more boring examples more interesting
• The numbers in the circles are misaligned, not centered.

Not sure about renaming NonLinear. Actually I think it is the perfect term to describe something that doesn't have to follow order. It is a well known term. We are not fundamentalistic about positivity in naming anyways because we didn't change Disabled to Enabled for similar reasons.

I tried icons but they look horribly out of alignment. This is standard for our buttons it seems :(

Will leave that for you too @danielchalmers to be done in a follow-up PR

Great new component! Our team has our own home-grown version of this, but will look at moving to the Stepper and dog fooding it soon.

FYI, one issue we had to overcome with our custom implementation was if the user input on a step made it so that another step was not needed, we needed to ensure it gracefully disappeared from the step list. IE, wrapping a MudStep in a conditional if.

Thanks for the feedback @gabephudson. We already have the possiblity to disable steps, it would look like this:

<MudPaper Style="width: 800px">
    <MudStepper ShowResetButton NonLinear>
        <MudStep Title="Step 1">
            <MudSwitch T="bool" @bind-Value="_step2" Color="Color.Primary">Ignore Step2</MudSwitch>
        </MudStep>
        <MudStep Title="Step 2" SecondaryText="Optional" @bind-Disabled="_step2">This can be switched off in Step 1</MudStep>
        <MudStep Title="Step 3">Final step</MudStep>
    </MudStepper>
</MudPaper>

@code {
    bool _step2 = false;    
}

However I discovered, that there is a bug because the next button doesn't work then. Will fix that.

https://try.mudblazor.com/snippet/QucoPulPdczUwCIy

Removing steps with an @if is also possible btw, I tried. Adding them back doesn't work for some reason though, so I will also consider adding a bindable Visible property.

Edit: actually there is a bug that can also be seen in the Add / Remove example. Adding a step does render it only after the next render so there is always one less shown than have been added. Will fix that, then the @if block around a step will also work.

Glad I brought that up. The way Blazor renders makes it tricky if the "steps collections" changes dynamically. Our implementation has each "step' register itself with the parent in the OnParametersSet() event. Even so, we still have issues with things like a consistent index and "active step" state when steps are not added/rendered due to a state change because of conditional @ifs. We have had to use OnAfterRender() in the "stepper" to fix edge cases and re-render. It's still not perfect for some combinations of prev/next steps and state changes (on our implementation).

That said, I really like the idea of using a visibility parameter (wish we implemented that on ours). This would allow the steps to remain in the stepper's collection and just simply be invisible/skipped. This allows a consistent steps collection and being able to keep track of an active index (that doesn't change because the collection size change). Wrapping a step in an @if would then be not recommended and perhaps only used if the steps are not needed on initialization. Visible would be used otherwise and when state changes dynamically when moving through steps.