Skip to content

Replace use of private HostInstance types in Fantom tests#56947

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

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
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) meta-exported p: Facebook Partner: Facebook Partner

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant