Skip to content

Replace use of private HostInstance types in Fantom tests#56947

Closed
huntie wants to merge 2 commits into
facebook:mainfrom
huntie:export-D106128324
Closed

Replace use of private HostInstance types in Fantom tests#56947
huntie wants to merge 2 commits into
facebook:mainfrom
huntie:export-D106128324

Conversation

@huntie
Copy link
Copy Markdown
Member

@huntie huntie commented May 22, 2026

Summary:

Context

For the Strict TypeScript API rollout, I'm understanding how we've defined, exposed, and applied component ref/element types for built-in React Native components. These are currently inconsistent and breaking between languages (Flow, manual TS types, and generated Strict TS types) and are a key surface area for migration incompatibilities and user confusion.

As a first phase, I want to align all Flow usages towards one pattern — even if this isn't the pattern we end up shipping for TypeScript.

This diff

Replace use of the private TextInputInstance type in our Fantom test code.

  • TextInput-itest.js now depends on public APIs only, and aligns with how external Flow callers (xplat/js) need to access this type.

Notably, this preserves HostInstance (<View>) uses (exported at root) as the remaining exception to the rule — which remains an open design problem I'm looking to address in T270727973 (via RN WG consultation).

Changelog: [Internal]

Differential Revision: D106128324

huntie added 2 commits May 22, 2026 14:00
Summary:

Discovered while I try to understand the best shape for ref types.

We have no other 1P component usage pattern for `React.ElementRef<ViewNativeComponentType>`, except for two now-removed fbsource instances, replaced with `React.ElementRef<typeof View>`.

Changelog: [Internal]

Reviewed By: cortinico

Differential Revision: D106093290
Summary:
#### Motivation

- This aligns with how all `xplat/js` callers need to access this type via the public Flow API.

This leaves `HostInstance` (exported at root) as the remaining exception to the rule — and remains an open design problem I'm looking to address in T270727973 (via RN WG consultation).

Differential Revision: D106128324
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label May 22, 2026
@meta-codesync
Copy link
Copy Markdown

meta-codesync Bot commented May 22, 2026

@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D106128324.

@huntie huntie added the JS API stabilization (1.0) Follow-up items from our JS API changes in 0.80 (deep imports deprecation and Strict TypeScript API) label May 22, 2026
@meta-codesync meta-codesync Bot closed this in b32a6c9 May 23, 2026
@react-native-bot
Copy link
Copy Markdown
Collaborator

This pull request was successfully merged by @huntie in b32a6c9

When will my fix make it into a release? | How to file a pick request?

@react-native-bot react-native-bot added the Merged This PR has been merged. label May 23, 2026
@meta-codesync
Copy link
Copy Markdown

meta-codesync Bot commented May 23, 2026

This pull request has been merged in b32a6c9.

@huntie huntie deleted the export-D106128324 branch May 23, 2026 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported JS API stabilization (1.0) Follow-up items from our JS API changes in 0.80 (deep imports deprecation and Strict TypeScript API) Merged This PR has been merged. meta-exported p: Facebook Partner: Facebook Partner

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants