jcfranco
commented
2 years ago We only emit change events on user interaction, so any code calling the stepper methods needs to sync up accordingly. Reason being that the code calling the stepper methods knows that there is potentially a change in step, hence why we don't emit. It also helps avoid cases where we can't distinguish where a change event came from.
I think what's missing is a property to easily know the selected stepper item. FYI, I'll have a PR for cleaning up event payloads this week that will introduce this prop.
macandcheese
github-actions[bot]
Description
When a user clicks a button that invokes a stepper method and navigates a stepper, the stepper should emit a
calciteStepperItemChangeevents.Acceptance Criteria
A stepper emits a
calciteStepperItemChangewhenever the step changes either by clicking a stepper-item heading or via a stepper method.Relevant Info
No response
Which Component
calcite-stepper
Example Use Case
In some cases, it's necessary to force a user to visit steps in order. This can currently be accomplished by disabling subsequent steps and offering a button that, when clicked, enables the next step and navigates to it via the stepper's
nextStep()method.In order to cleanly track the current step and which steps have been visited (regardless if the user clicked the button or navigated to a previously enabled step by clicking its heading), it'd be helpful to unify that code in a single
calciteStepperItemChangehandler.Another use case is the event provides an indicator that the step is rendered and ready for any setup work (e.g. setting initial focus).