WheelPicker

A time is two columns and a date is three, so a wheel with a single value would be a wheel that can only ever be one of them. The WheelDatePicker, WheelTimePicker and WheelDateTimePicker of P5.25 are all this component with a different set of columns and the arithmetic to fill them — which is why it is here first, and why the roadmap calls it "the spinning column the three below share".

<WheelPicker>
  <WheelPicker.Column
    value={hour}
    onValueChange={setHour}
    accessibilityLabel="Heures"
  >
    {HOURS.map(h => (
      <WheelPicker.Item key={h} value={h}>
        {h}
      </WheelPicker.Item>
    ))}
  </WheelPicker.Column>
  <WheelPicker.Column
    value={minute}
    onValueChange={setMinute}
    accessibilityLabel="Minutes"
  >
    {MINUTES.map(m => (
      <WheelPicker.Item key={m} value={m}>
        {m}
      </WheelPicker.Item>
    ))}
  </WheelPicker.Column>
</WheelPicker>

There is no press to select. The row at the middle is the choice, so a column snaps to a row and reports whichever one it stopped at — which is what makes this a wheel rather than a short list, and why the rows are Text nodes rather than pressables. A row you could tap would be a second way to choose that the band does not describe.

It reports at rest, never while turning. One flick passes nine rows, and every one of them is a value some caller would have written to a form. onScrollEndDrag covers a slow drag that stops without momentum and onMomentumScrollEnd covers the flick; both are needed, and neither fires for the other.

Coming back to rest on the row you started from fires nothing at all.

One shape laid across every column, rather than one per column: two columns at different widths would show the seam between their two bands. It is pointerEvents: 'none', so it marks the middle without taking the touch that turns the wheel under it.

It is written by the root rather than by the caller, unlike the Tabs's indicator — that one is a choice about a decoration, and this is where the middle is.

Not decoration: it is the whole of what says this is a drum with more of it out of sight rather than a list that happens to have stopped. The row at the middle is upright, full strength and in the band's colour; two rows out it is at a quarter opacity, 82% of its size and turned 55°.

The turn is read from the column's scroll offset on the UI thread, through a shared value. A position crossing the bridge every frame would animate at the rate React re-renders rather than at the rate the finger moves — which on a fast flick is the difference between a drum and a slideshow.

<WheelPicker visibleCount={7}>…</WheelPicker>

The whole control is built on there being a middle row. An even count has two rows equally near the centre, and the band would sit over the seam between them. A count is rounded up to the next odd number, because a caller who asked for four wanted more than three, not less.

It is a raw number rather than a token, like the ProgressCircle's radius, so it lives outside the style cache: the wheel's height is visibleCount rows and is applied after the recipe rather than inside it.

An endless drum is not a scroll view with a flag on it — it is a list with no end, faked by rewriting the data around the finger and jumping the offset back whenever it drifts too far. That trick belongs to the caller's data, where the caller knows how many months there are; here it would be a component quietly renumbering its own children.

useWheelPicker() carries the resolved styles and the geometry — the row height above all, since the snap interval, the padding and the rest position are all computed from it. useWheelPickerColumn() carries the live offset, the resting index and each row's position. Both are exported (R10), and both throw by name outside their parent.