[0.87] Strict TypeScript API Feedback Thread (removal of deep imports)

[huntie]

Introduction

RFC | Docs

The 0.87 rollout of the Strict TypeScript API is an ecosystem-wide change, and one we need to make in order to have stable API guarantees for React Native in future.

Design choices about which APIs are exported at root, and intentional updates to type names/shapes have been worked on with the community and partners since the original 0.80 preview.

We believe we've ironed out all rough edges, but there may still be edge cases. If you're choosing to opt out of the Strict API in 0.87 or later, we'd love to know why.

💡 Strict API in brief

The Strict TypeScript API is React Native's modern TypeScript API, replacing the previous hand-maintained TypeScript definitions from earlier versions.

Key changes (breaking)

1. No deep imports. The API is restricted to react-native 's index file. This is a tighter and more intentional public API contract. It also ensures that internal file path changes in React Native's source code won't be breaking.
2. Generated directly from source. Previously, React Native used separately maintained manual types. Generating from source now means we improve coverage, correctness, and compatibility guarantees.

https://reactnative.dev/docs/strict-typescript-api

Backlinks

• [0.80] Deprecating deep imports from `react-native` — Feedback thread #893
• Community feedback actioned on: facebook/react-native/issues (sort:created-desc label:"JS API refinements (2025)")

[SimpleCreations]

Hi! I'm surprised I'm the first one here 😁

I gave the strict TypeScript API a shot. Upgrading most of my project went smooth. But I'd like to highlight a couple of regressions I've run into.

• Animated.event now returns any (previously: (...args: any[]) => void). This now requires a workaround if the project uses @typescript-eslint/no-unsafe-assignment.
• The parameter of Animated.Value.addListener is now typed as any (previously: ValueListenerCallback, resolved to (state: {value: number}) => void). Same issue.
• SectionListData got a new union type option SectionT that wasn't there in the legacy types. This means that new types allow a section to consist only of user-provided fields, without data. Hacks/workarounds are required to assert that sections always have a data property.

[huntie]

Thanks for finding and documenting these!

Opened fixes, should land in 0.87.1:

• Type Animated.event() as an event handler instead of any react/react-native#57991
• Type Animated.Value.addListener callback react/react-native#57992

[sidorchukandrew]

Hi! Could we by chance have VirtualizedListContextResetter and ScrollView.Context.Provider exported from the public API? I am trying to use react-native-screens Modal component (because the RN one doesn't have native header support). I need to reset the contexts because the scrollviews genuinely are not in the same native hierarchy:

<ScrollView>
  <RNScreensModal>
    {/*  I need to manually add these here to break the illusion that these are nested scroll views */}
    <VirtualizedListContextResetter>
      <ScrollView.Context.Provider value={null}>
        <ScrollView />
      </ScrollView.Context.Provider>
    </VirtualizedListContextResetter>
  </RNScreensModal>
</ScrollView>

This would match what the RN Modal already does. The RN Modal already injects those two contexts to each modal.

Things to note
Our app is too large to convert all our RN Modals to full blown React Navigation modals. The effort is going to be very high to figure out how to share data and callbacks for all our forms that currently live in RN modals right with the calling components. That's why I'm trying to directly use React Native Screens modal directly.

[huntie]

This is interesting.

• <VirtualizedListContextResetter> looks like an intentional API.
• I'm less sure about ScrollView.Context.Provider.

@cortinico @cipolleschi — do we know the best POC on lists to inform an API decision here?