fix: fix getNativeScrollRef return type for FlatList

[janpe]

Summary:

The Problem

When trying to measure the location of a View within a FlatList (ie. for scrolling to the view), the current recommended method is to use measureLayout on the nested view to determine its location inside the containing FlatList:

const MyComponent = () => {
  const flatListRef = useRef<FlatList>(null);
  const nestedViewRef = useRef<View>(null);

  const scrollToNestedView = () => {
    if (!flatListRef.current || !nestedViewRef.current) {
      return;
    }

    nestedViewRef.current.measureLayout(
      flatListRef.current.getNativeScrollRef(),
      (x, y) => { flatListRef.current.scrollTo({ y, animated: true }); },
    );
  }

  return (
    <FlatList ref={flatListRef}>
      <View ref={nestedViewRef}>
        { /* content */ }
      </View>
    </FlatList>
  );
}

However the types for FlatList getNativeScrollRef don't allow this.

The solution

This solution is basically identical to that in #52203. The return value for getNativeScrollRef should be HostInstance | null

Changelog:[GENERAL] [FIXED] - Change FlatList.getNativeScrollRef return type definition to allow accessing the underlying HostInstance.

Test Plan:

None needed. This is only a type update exposing existing functionality.

[meta-cla]

Hi @janpe!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[janpe]

@rshest I see you’ve previously reviewed changes on this file. Any chance you could have a look? Thanks!

[janpe]

How about @cipolleschi ? Any change you might have time to take a look at these changes?

[janpe]

@huntie could you maybe look at this small PR? I saw that you've contributed to the code for Lists before so I thought reaching out to you to see if this correction for the types could get merged at some point.

[janpe]

@javache @hoxyq any chance either of you could take a look at this?

[huntie]

@janpe This will deviate from our auto-generated types in the Strict API.

Can we check:

• Is React.ComponentRef<typeof ScrollViewComponent> vs React.ComponentRef<ScrollViewComponent> the fix?
• Can we update the source code in Flow for FlatList to align?

react-native/packages/react-native/ReactNativeApi.d.ts

Lines 2335 to 2337 in 4b4ae62

	getNativeScrollRef():
	| (null | React.ComponentRef<ScrollViewNativeComponent> | undefined)
	| (null | React.ComponentRef<typeof View> | undefined)

[huntie]

Extra note: This needs to be PublicScrollViewInstance, so that it has the extra imperative methods we want.

react-native/packages/react-native/Libraries/Components/ScrollView/ScrollView.js

Lines 138 to 149 in 91702e5

	export interface ScrollViewImperativeMethods {
	+getScrollResponder: () => ScrollResponderType;
	+getScrollableNode: () => ?number;
	+getInnerViewNode: () => ?number;
	+getInnerViewRef: () => InnerViewInstance | null;
	+getNativeScrollRef: () => HostInstance | null;
	+scrollTo: (
	options?: ScrollViewScrollToOptions | number,
	deprecatedX?: number,
	deprecatedAnimated?: boolean,
	) => void;
	+scrollToEnd: (options?: ?ScrollViewScrollToOptions) => void;

[huntie]

Hey @janpe, FYI I'm looking at solving a related wider issue in #56673 (fingers crossed, we merge *HostInstance types into all built-in components).

While I'd ideally want us to solve this problem once (for both the current manual TS API and the incoming Strict Flow→TS API), #52203 is indeed precedence.

🚧 Changes needed to land

• Please see my comment above about PublicScrollViewInstance. I think we also want to update the call site in fix: add missing getNativeScrollRef type for ScrollView #52203 to match.

[janpe]

Hey @janpe, FYI I'm looking at solving a related wider issue in #56673 (fingers crossed, we merge *HostInstance types into all built-in components).

While I'd ideally want us to solve this problem once (for both the current manual TS API and the incoming Strict Flow→TS API), #52203 is indeed precedence.

🚧 Changes needed to land

• Please see my comment above about PublicScrollViewInstance. I think we also want to update the call site in fix: add missing getNativeScrollRef type for ScrollView #52203 to match.

Much appreciated! See my changes and let me know if you'd like to request anything further.

[huntie]

Let's make sure the TS changes pass CI validation!

[huntie]

Can I ask that we omit changes outside the .d.ts files in this PR? I'm actioning these in #56718 🙂

[janpe]

Oh, I must have misunderstood. Sorry for that! I've removed the changes to this file from the commit.

[github-actions]

Warning

JavaScript API change detected

This PR commits an update to ReactNativeApi.d.ts, indicating a change to React Native's public JavaScript API.

• Please include a clear changelog message.
• This change will be subject to additional review.

This change was flagged as: POTENTIALLY_BREAKING