StepperCommandDialog miscounts conditional steps

[woksin]

Describe the bug

This issue promotes a previously recorded upstream item from a production Cratis consumer. The complete evidence and requested fix follow.

Status: Open upstream defect · filing in progress 2026-08-10
Product: Components — StepperCommandDialog
Type: Correctness / navigation

Symptom and Ada cost

StepperCommandDialog derives its step count through React.Children.count, which counts a falsy conditional
child as a slot. A normal {showStep && <StepperPanel />} therefore produces a step count that differs from the
rendered panels and breaks Next/Previous/Submit navigation. Ada's command-dialog skill has to forbid conditional
steps and require consumers to drop to a manual dialog and PrimeReact Stepper.

Requested fix

Count React.Children.toArray(children) after filtering non-elements, and add navigation coverage with false,
null, fragments and arrays. The visible step list must be the single source for current/last-step calculations.

Honest limits

The behavior is source-read and encoded in Ada's corpus; no Components runtime reproduction was run in this pass.

[woksin]

Fixed in 2.7.1 (PR #127, merge 4e4156a).

React.Children.count counted the false that {condition && <StepperPanel/>} leaves behind, while React.Children.toArray — which fed the field names — already dropped it. Both now derive from one filtered list, and a hidden panel is never handed to the stepper at all, so it cannot surface through an index, a count, a header or an aria-label.

Fixing the count exposed a second defect that had been unreachable while the count was constant. Because the step count can now shrink while a wizard is open, an index that had walked past a step which later disappeared was left above the end — and the comparison for the final step was an equality, so it stopped matching: Submit never appeared, a dead Next took its place, and each further click pushed the index further out. Hiding every step did the same from the other end. The index is now clamped to the steps that exist and compared with inequalities, in both StepperCommandDialog and the shared body, so the two no longer disagree.

Verification worth stating, because the original specs could not have caught either defect. The count fix is pinned by specs that count rendered data-testid="stepper-panel" occurrences and assert on emitted markup — replacing the filtered length with React.Children.count fails twelve facts. The last-step comparison was harder: reverting it to an equality left all 394 tests green, because the dialog hides the shared body's footer, so the buttons only exist when that body is used standalone — which is a published entry point. A spec for exactly that case now exists, and it is the only thing in the suite that fails when the comparison is reverted.

One part of this report is deliberately not fixed. A <React.Fragment> wrapping several panels still counts as one step. That is documented at the counting helper and pinned by a spec, so it is a stated limitation rather than an accident. If you need fragment-wrapped panels to count individually, that is worth its own issue — the fix is not obviously compatible with letting a fragment group steps on purpose.