Fix Reorder.Group to accept union array types

[mattgperry]

Summary

Fixes #2905

Reorder.Group's values prop was typed as V[] with a single generic element type V, which prevented passing union array types like number[] | string[]. TypeScript would infer V = number from the first union member and then reject string[].

Cause: The external type signature used V as the element type, so values: V[] couldn't represent number[] | string[] (a union of arrays is not the same as an array of unions).

Fix: Changed the external type assertion to be generic over the full array type (Values extends any[]) instead of just the element type. The values prop now accepts Values directly, and onReorder returns Values, so union array types flow through correctly. The internal implementation is unchanged — it derives the element type as Values[number] where needed.

This is a backwards-compatible change: existing code using string[], number[], or MyObject[] continues to work exactly as before.

Test plan

• Added unit test that uses useState<number[] | string[]> with Reorder.Group — verifies the TypeScript compilation and rendering
• Existing Reorder tests pass (ref hydration, virtualized list reorder)
• Full build passes (yarn build)

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR fixes a TypeScript-only issue with Reorder.Group where the values prop could not accept union array types like number[] | string[]. The root cause was that the external generic was parameterised over the element type V, so values: V[] couldn't represent a union of arrays. The fix re-parameterises the exported type cast over the full array type (Values extends any[]) and derives the element type as Values[number] where the internal implementation needs it.

• Type fix (Group.tsx): The forwardRef cast now uses Values extends any[] as its generic, accepts values: Values directly, and exposes onReorder: (newOrder: Values) => void. The internal ReorderGroupComponent is completely unchanged — the element type for context/register logic continues to come from the internal Props<V> interface.
• New test (index.test.tsx): Adds a test that instantiates useState<number[] | string[]> and passes it to Reorder.Group, verifying both TypeScript acceptance (the file must compile) and correct runtime rendering of list items.
• Backwards compatibility: Fully preserved — existing usages typed as string[], number[], or custom object arrays still infer Values as that concrete array type and behave identically.

Confidence Score: 5/5

• This PR is safe to merge — it is a backwards-compatible TypeScript type-only change with no runtime behaviour modifications.
• The internal ReorderGroupComponent implementation is untouched; the change is limited to the exported type cast. The Values[number] indexed-access pattern is a well-established TypeScript idiom for extracting element types, and the fix correctly threads union array types through both values and onReorder. A dedicated regression test confirms the scenario compiles and renders correctly. No runtime risk is introduced.
• No files require special attention.

Important Files Changed

Filename	Overview
packages/framer-motion/src/components/Reorder/Group.tsx	Adds a type-level cast to expose Values extends any[] as the generic parameter instead of the element type V, allowing union array types to flow through values and onReorder. Internal implementation is unchanged; Values[number] correctly derives the element type for internal use.
packages/framer-motion/src/components/Reorder/tests/index.test.tsx	Adds a regression test that uses `useState<number[]

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["User Code\n<Reorder.Group values={items} onReorder={setItems}>"]
    B["External Type Cast\nReorderGroup\nValues extends any[]"]
    C{"TypeScript\ninfers Values"}
    D["string[]"]
    E["number[]"]
    F["string[] | number[]\n(new - previously broken)"]
    G["Values[number]\nextracts element type"]
    H["Internal ReorderGroupComponent\nProps<V, TagName>\n(unchanged)"]
    I["ReorderContext\nregisterItem / updateOrder"]

    A --> B
    B --> C
    C --> D & E & F
    D & E & F --> G
    G -->|"V = Values[number]"| H
    H --> I

Loading

_{Last reviewed commit: a25d58a}

[greptile-apps]

Consider unknown[] over any[] for the constraint

Values extends any[] technically allows any to satisfy the constraint unchecked. Using Values extends unknown[] is marginally stricter and prevents any from silently widening through — a common best-practice for generic utilities where you don't need the escape hatch any provides.

Suggested change

	Values extends any[],
	Values extends unknown[],

This is backwards-compatible: all existing concrete types (string[], number[], MyObject[], string[] | number[]) satisfy unknown[] just as they satisfy any[].

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[HardikDewra]

Smart type-level fix. The original generic V on Reorder.Group meant passing a union array type like number[] | string[] would infer V as number | string, losing the array-level union distinction. By switching to Values extends any[] and using Values[number] for the item type while keeping Values as the array type for onReorder, TypeScript preserves the full union and setItems works correctly without type errors. The test demonstrates the exact use case - a state typed as number[] | string[] now works without needing to widen the type.