Follow-up from @ankitgoswami on #863 (comment):
Do we have a requirement for configurable counter start and scale? Or could the initial bulk-create flow simply generate ${prefix}${index + 1} from only prefix and count? That would remove two fields and their state, sanitization, validation and the padding logic.
Current state
The Multiple variant of the bulk-create forms exposes a prefix + counter start + counter scale triple, where scale is a zero-pad width (start 1 at scale 3 reads 001), not a multiplier.
Two call sites share it:
Both generate their labels through client/src/protoFleet/utils/bulkNameSeries.ts (buildBulkNameSeries / formatBulkCounter), which is the single source of truth for the on-screen preview and the CreateRacks / CreateBuildings payload.
What dropping the two fields would remove
- Two
Input fields and their state (bulkCounterStartText, bulkCounterScaleText) per form
bulkCounterStartError / bulkCounterScaleError and the scale range check against counterScaleMinimum/counterScaleMaximum (1–6)- Two of the three
digitsOnly + sanitize call sites added in bd39312
formatBulkCounter and clampScale in bulkNameSeries.ts; buildBulkNameSeries collapses to `${prefix}${i + 1}`- The
counterStartInputMaxLength / counterScale* imports from the bulk-rename constants
Why it was built this way
Two reasons, both worth re-examining rather than treating as settled:
- It matches the comps.
- It matches the existing bulk-rename convention (
RenameOptionsModals, bulkRenamePreview.ts), which already uses the same prefix + start + scale triple. The intent was that an operator who has used bulk rename already knows what the three fields do.
Neither is a hard requirement — there is no ticket asking for configurable start/scale.
The real question
Zero-padding is the part with actual operational value: R-001 … R-012 sorts lexicographically, R-1 … R-12 does not. Racks and buildings get read in sorted lists all over the app. So the choice is probably not "keep all three or keep one", but:
- A — keep as is (three fields, matches comps and bulk rename)
- B — prefix + count only, no padding (
${prefix}${index + 1}) — Ankit's proposal, simplest, but gives up sort-stable labels
- C — prefix + count only, padding derived from the count (a batch of 12 pads to 2, a batch of 500 pads to 3) — removes both fields and their validation while keeping labels sortable. Loses the ability to start at a number other than 1, which matters when adding a second batch to an existing row (
R-013 onward).
Next step
Need @jmarrxyz's take on whether configurable start/scale is intentional in the comps or incidental, and whether C is an acceptable deviation. Deferred out of #863 rather than changed there.
Follow-up from @ankitgoswami on #863 (comment):
Current state
The Multiple variant of the bulk-create forms exposes a prefix + counter start + counter scale triple, where scale is a zero-pad width (start
1at scale3reads001), not a multiplier.Two call sites share it:
client/src/protoFleet/features/fleetManagement/components/RackSettingsModal.tsx—rack-bulk-prefix,rack-bulk-count,rack-bulk-counter-start,rack-bulk-counter-scaleBuildingSettingsModal(bulk building create, currently on the [5/6] feat(buildings): create racks and buildings inline from the building surfaces #864 branch) — same shapeBoth generate their labels through
client/src/protoFleet/utils/bulkNameSeries.ts(buildBulkNameSeries/formatBulkCounter), which is the single source of truth for the on-screen preview and theCreateRacks/CreateBuildingspayload.What dropping the two fields would remove
Inputfields and their state (bulkCounterStartText,bulkCounterScaleText) per formbulkCounterStartError/bulkCounterScaleErrorand the scale range check againstcounterScaleMinimum/counterScaleMaximum(1–6)digitsOnly+sanitizecall sites added in bd39312formatBulkCounterandclampScaleinbulkNameSeries.ts;buildBulkNameSeriescollapses to`${prefix}${i + 1}`counterStartInputMaxLength/counterScale*imports from the bulk-rename constantsWhy it was built this way
Two reasons, both worth re-examining rather than treating as settled:
RenameOptionsModals,bulkRenamePreview.ts), which already uses the same prefix + start + scale triple. The intent was that an operator who has used bulk rename already knows what the three fields do.Neither is a hard requirement — there is no ticket asking for configurable start/scale.
The real question
Zero-padding is the part with actual operational value:
R-001 … R-012sorts lexicographically,R-1 … R-12does not. Racks and buildings get read in sorted lists all over the app. So the choice is probably not "keep all three or keep one", but:${prefix}${index + 1}) — Ankit's proposal, simplest, but gives up sort-stable labelsR-013onward).Next step
Need @jmarrxyz's take on whether configurable start/scale is intentional in the comps or incidental, and whether C is an acceptable deviation. Deferred out of #863 rather than changed there.