[react] TouchList.item should be able to return null #75802

Thanks for the discussion about "react", some useful links for everyone:

• npm
• DT
• Related discussions

Pinging the DT module owners: @johnnyreilly, @bbenezech, @pzavolinsky, @ericanderson, @DovydasNavickas, @theruther4d, @guilhermehubner, @ferdaber, @jrakotoharisoa, @pascaloliv, @Hotell, @franklixuefei, @Jessidhia, @saranshkataria, @lukyth, @eps1lon, @zieka, @dancerphil, @dimitropoulos, @disjukr, @vhfmag, @priyanshurav, @Semigradsky, @mattpocock.

Yes for item(): the Touch Events definition explicitly allows null. React's SyntheticTouchEvent implementation forwards the native touch lists, so it doesn't remove that possibility.

The narrow declaration fix is:

- item(index: number): Touch;
+ item(index: number): Touch | null;

I checked this locally with @types/react@19.3.0, TypeScript 7.0.2 and strict: true. This regression test fails with the published declaration and passes after that one-line change:

import type * as React from 'react';
type Assert<T extends true> = T;
type Nullable = Assert<
  null extends ReturnType<React.TouchList['item']> ? true : false
>;
declare const event: React.TouchEvent;
const touch = event.touches.item(0);
// @ts-expect-error An unchecked result may be null.
touch.clientX;
if (touch !== null) {
  const x: number = touch.clientX;
}

For identifiedTouch(), the older Touch Events Extensions specification also specifies null when no identifier matches. It's absent from the current TouchList definition, though, so I'd treat its continued presence in React's types as a separate legacy-API question rather than recommend using it.

This was a focused compiler check, not a full DefinitelyTyped test run. Existing code that dereferences item() without a null check would need updating.

#75825 is opened.

identifiedTouch is not updated, since there are not enough docs / evidences to say it could be null.