[0.80] Deprecating deep imports from react-native — Feedback thread

[huntie]

Important

Shipped in 0.87! This thread is now locked. Please go to this discussion thread for further feedback: #1015

Introduction

See the RFC | See the 0.80 release post

🚨 Key change: In React Native 0.80, we are deprecating subpath imports (or "deep imports") from the react-native npm package.

By defining a clear, root-level JavaScript API contract, we aim to minimise future React Native breaking changes and improve long-term predictability for the ecosystem.

// Before - subpath imports allowed
import {Alert, AlertType} from 'react-native/Libraries/Alert/Alert';

// After - must import from 'react-native'
import {Alert, AlertType} from 'react-native';

Why it matters: While initially deprecated with warnings, we aim to remove these import paths entirely, which will be a breaking change.

This discussion thread

Please raise issues/questions about APIs you are using that are affected by this change. Over our API consultation period (beginning 0.80), we'll evaluate requests for exposing new APIs at the root, or providing alternatives.

Planned sequencing

• React Native 0.80: Deprecation of subpath imports, introduce runtime warnings.
• React Native 0.82 (or later): Removal of subpath imports via "exports" and the Strict TypeScript API.

What we've actioned!

https://github.com/facebook/react-native/issues?q=sort%3Acreated-desc%20label%3A%22JS%20API%20refinements%20(2025)%22

[kirillzyusko]

Hey @huntie

I believe that change will break react-native-keyboard-controller, because I rely on deep imports and I substitute NativeStatusBarManagerAndroid with own version that doesn't break edge-to-edge mode and removes keyboard listeners.

You can see here how it's done: https://github.com/kirillzyusko/react-native-keyboard-controller/blob/main/src/monkey-patch.android.ts (obviously the solution is a dirty workaround, but it was working for years 🙈)

I'll be happy to discuss a better solution/alternative for that or at least add temporarily NativeStatusBarManagerAndroid to official imports (but I don't think you want to do it?)

[huntie]

Noted, thanks. Yeah this is definitely a hack 😅

• Yup, promoting NativeStatusBarManagerAndroid directly to the public API isn't what we want.
• That's not to say we couldn't introduce an escape hatch, or a better API.

Give us some time as these requests stack up, and we'll loop back with an alternative (though in this case, not guaranteed).

[mrousavy]

[Done] Expose NativeComponentRegistry (react/react-native#52999)

Oh, sh*t. I just saw this - unfortunately I need a deep-import in Nitro.

I use NativeComponentRegistry (the default export from react-native/Libraries/NativeComponent/NativeComponentRegistry) to find a native view I registered using Nitro View components (custom ShadowNode stuff and all that).

I can't use codegenNativeComponent because I am not using codegen - the view code is generated using Nitrogen.

Is there any chance we can promote this to a public export?

[huntie]

@mrousavy Best to get some alignment first. I'm not particularly sure on this API decision. cc @cortinico @NickGerleman

[mrousavy]

Yea I think this is the only way to register a non-codegen'd component. And since the C++ APIs for creating ShadowNodes are public, it doesn't really make sense to make the API required to use said C++ component private.

See getHostComponent.ts.

[cortinico]

We'll have to discuss about this one. @mrousavy Having the PR out will facilitate the discussion IMHO 👍

Yea I think this is the only way to register a non-codegen'd component. And since the C++ APIs for creating ShadowNodes are public, it doesn't really make sense to make the API required to use said C++ component private.

Just note that sadly everything in C++ is practically public at this stage. This shouldn't be an argument to get more things exposed on the other layers though, as we might want to go the other way around (restricting the C++ visibility).

[mrousavy]

Wu created a PR for this here: react/react-native#52999

[cipolleschi]

My take here is that if it is impossible to create a Native Component without codegen (which is optional) with the API React Native provides because of this, then the NativeComponentRegistry must be public.
@cortinico @huntie

[mfkrause]

[Done] Expose unstable_NativeText and unstable_NativeView components (react/react-native#53777)

Just saw this through the 0.80 release.

Please consider exporting NativeText from react-native/Libraries/Text/TextNativeComponent and the default export from react-native/Libraries/Components/View/ViewNativeComponent. We use these in react-native-boost to replace Text and View components within apps, wherever possible, since they're more performant than the JS wrappers (especially Text). There's also a couple other libraries in the ecosystem that rely on them (Unistyles I think, for example).

[huntie]

Tentatively, sounds like libraries may need an interface to each Native* version of a component.

Thanks for the feedback, we're tracking these requests and will review what design might make sense down the line. cc @cortinico

[huntie]

Opened react/react-native#53777

[mfkrause]

@huntie Sorry to come back to this nearly a year later. Could I ask where deep imports currently stand? They've been deprecated for a while but are still resolvable in 0.86. Is there a timeline for actual removal?

More importantly, following on from react/react-native#53777, which exposed NativeText and NativeView (thanks for that!), is there any chance we can do the same for NativeVirtualText? I realize the use case is a lot narrower than Text/View. However, we're planning some improvements to the library mentioned in my original comment, which would require importing this. Happy to open a PR, but wanted your read first.

[huntie]

@mfkrause Hey — working on it. This work was backgrounded for a while, but have been making moves recently.

Re NativeVirtualText: might need to be covered under a library/frameworks opt-out (unstable API) in the medium term (particularly if this API doesn't have widespread use yet). Still deciding what shape this could be.

[Pnlvfx]

Sorry I dunno if this is the right place to say that, I tried the new strict api on my react native project and I'm getting 94 parsing errors, I had to disabled it for now.

Let me know if you need any more info

See parsing errors

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:128:34 - error TS1005: ';' expected.

128   get getNodeFromPublicInstance(): getNodeFromPublicInstance {
                                     ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:128:36 - error TS1435: Unknown keyword or identifier. Did you mean 'get NodeFromPublicInstance'?

128   get getNodeFromPublicInstance(): getNodeFromPublicInstance {
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:131:4 - error TS1128: Declaration or statement expected.

131   },
       ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:132:3 - error TS1434: Unexpected keyword or identifier.

132   get getInternalInstanceHandleFromPublicInstance(): getInternalInstanceHandleFromPublicInstance {
      ~~~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:132:52 - error TS1005: ';' expected.

132   get getInternalInstanceHandleFromPublicInstance(): getInternalInstanceHandleFromPublicInstance {
                                                       ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:132:54 - error TS1435: Unknown keyword or identifier. Did you mean 'get InternalInstanceHandleFromPublicInstance'?

132   get getInternalInstanceHandleFromPublicInstance(): getInternalInstanceHandleFromPublicInstance {
                                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:135:4 - error TS1128: Declaration or statement expected.

135   },
       ~

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:136:1 - error TS1128: Declaration or statement expected.

136 };
    ~

Found 94 errors in the same file, starting at: node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js:11.

I've some custom tsconfig but even after disabling them the result is the same.

[huntie]

@Pnlvfx This is expected — opting into the new API can be a breaking change. Please see our user guide for more information on tackling these breaking changes.

[Pnlvfx]

@Pnlvfx This is expected — opting into the new API can be a breaking change. Please see our user guide for more information on tackling these breaking changes.

Yes, I've read both blog posts. i did what the blog post say on the opt in section. the thing is that the errors are all coming from inside the node module, this are not error from my code.

more specifically they are all into this file:

node_modules/react-native/Libraries/ReactPrivate/ReactNativePrivateInterface.js

Should I add node modules on the exclude array on the tsconfig? I didn't see any mention about doing it

[j-piasecki]

@Pnlvfx Is there any chance you could prepare a reproduction for this? At first glance, it looks like TypeScript started picking up the Flow source code when you enabled the Strict API, but it didn't without it.

[Pnlvfx]

No, I'm sorry, I'm working on a mac with 120gb of memory and I don't even have space for the project I'm working on, I'm sorry. However I can provide my tsconfig in case you want to give them a shot and see if they break something, however as I said, I tried with the default and it still give me the same error.

N.B: I removed jest from the types array as written on the comment " removing jest from the default react-native tsconfig" because i'm not using jest and so I had to remove it from there, of course I've also removed all the test related packages including react-test-render. I don't think I changed anything else that could have affected typescript configs.

tsconfig.json

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "types": ["react-native"], // removing jest from the default react-native tsconfig
    "noImplicitAny": true /* Enable error reporting for expressions and declarations with an implied 'any' type. */,
    "strictNullChecks": true /* When type checking, take into account 'null' and 'undefined'. */,
    "strictFunctionTypes": true /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */,
    "strictBindCallApply": true /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */,
    "strictPropertyInitialization": true /* Check for class properties that are declared but not set in the constructor. */,
    "noImplicitThis": true /* Enable error reporting when 'this' is given the type 'any'. */,
    "useUnknownInCatchVariables": true /* Default catch clause variables as 'unknown' instead of 'any'. */,
    "alwaysStrict": true /* Ensure 'use strict' is always emitted. */,
    "noUnusedLocals": true /* Enable error reporting when local variables aren't read. */,
    "noUnusedParameters": true /* Raise an error when a function parameter isn't read. */,
    "noImplicitReturns": true /* Enable error reporting for codepaths that do not explicitly return in a function. */,
    "noFallthroughCasesInSwitch": true /* Enable error reporting for fallthrough cases in switch statements. */,
    "noUncheckedIndexedAccess": true /* Add 'undefined' to a type when accessed using an index. */,
    "noImplicitOverride": true /* Ensure overriding members in derived classes are marked with an override modifier. */,
    "noPropertyAccessFromIndexSignature": true /* Enforces using indexed accessors for keys declared using an indexed type. */,
    "verbatimModuleSyntax": true,
    "removeComments": true,
    // "customConditions": ["react-native-strict-api"],
    "paths": {
    }
  }
}

[AlekseyP18]

same problem

[alexbrazier]

react-native-network-logger uses XHRInterceptor to intercept and display network requests the app makes. This is useful in dev and even prod builds (behind a flag) for devs and QAs to debug issues with an app after it's been built. Currently this is imported from react-native/src/private/devsupport/devmenu/elementinspector/XHRInterceptor. This is obviously an internal api that shouldn't be used by accident, so probably shouldn't be exposed at the root level, but if this was blocked and not exposed elsewhere then this library would stop working.

[huntie]

Definitely a private API.

• We're on track to ship first party Network debugging in React Native DevTools, in an upcoming release and before deep imports removal.
• Along with this, there will be somewhat of a replacement API from the JS side, via performance.getEntries().

[joshuayoes]

This is also used by Reactoton, Radon IDE, and this library.

https://github.com/search?q=react-native%2Fsrc%2Fprivate%2Fdevsupport%2Fdevmenu%2Felementinspector%2FXHRInterceptor&type=code

This is definitely a private API, but I feel maintaining some backwards compatibility for a while for this is important. I've been using React Native DevTools for a while and I really like it, but there are thousands of React Native developers using these tools that have filled this need for several years and have certain development habits built around using these tools.

[miquelbeltran]

The API XHRInterceptor is used as well by https://github.com/MindscapeHQ/raygun4reactnative for its Realtime User Monitoring network tracking.

[edoko]

Are there any additional measures to resolve this issue?
Has it been decided that the private API will not be used?

[jamonholmgren]

Just dropping this here -- Callstack has a Network Activity Plugin package they use in Rozenite. It looks like we could piggyback Reactotron on that, or use a similar approach. (Thanks to Callstack for building this!)

https://github.com/callstackincubator/rozenite/tree/main/packages/network-activity-plugin

[Titozzz]

[Done] Expose unstable_TextAncestorContext (react/react-native#52368)

Internally we import TextAncestorContext from import TextAncestor from 'react-native/Libraries/Text/TextAncestor';

It allows us to detect if we are rendering something inside a Text (we want to block it)

const useWarnHook =
  getNodeEnv() === 'development'
    ? () => {
        const isTextAncestor: boolean = useContext(TextAncestor);

        if (isTextAncestor) {
          printWarning('[ComponentName] should not be used inside a Text component');
        }
      }
    : undefined;

[huntie]

Are you able to replace this with findNodeHandle (docs)?

[tomekzaw]

findNodeHandle is not compatible with React.StrictMode I believe, that's why we had to migrate off from findNodeHandle in Reanimated and Gesture Handler

[huntie]

Alright, raising internally 👍🏻

[huntie]

Opened react/react-native#52368.

[vonovak]

Hello,
I just wanted to flag that while most RN deep imports were never advertised as correct, there is an exception which is the codegen: codegen stuff was always documented with deep imports and hence is widely used:

example GH search

migrating these to import from react-native will take a while (some libs will never migrate) and will remove support for pre-RN 0.80 versions in those libraries. Maybe these imports should stay available.

The new imports are done like this. This could be valuable to mention in the FAQ for library maintainers here.

[huntie]

We'll pay attention to this (high usage count + indeed previous status quo of documented subpaths). It should be functionally trivial to migrate libraries, but appreciate there could be a long tail.

A solution we could pursue is preserving + allowing these Codegen subpaths in our package (via package.json#exports), but continue to leave them out of our TypeScript API (type errors in each library, not surfacing to consuming apps).

[deusflow]

Thanks for the clarification! I wasn’t aware that deep imports were so widely used in the ecosystem. Looking forward to seeing what alternatives will be officially supported.

[troZee]

Does it mean the following mock will stop working in RN 0.82?

jest.mock('react-native/Libraries/Utilities/BackHandler', () => {
  const _backPressSubscriptions = new Set();
  const exitApp = jest.fn();
  return {
    __esModule: true,
    default: {
      getSubscriptions: function (): number {
        return _backPressSubscriptions.size;
      },
      exitApp,
      addEventListener: function (_eventName: string, handler: () => boolean) {
        _backPressSubscriptions.add(handler);
        return {
          remove: () => {
            _backPressSubscriptions.delete(handler);
          },
        };
      },

      mockPressBack: function () {
        let invokeDefault = true;
        const subscriptions = [..._backPressSubscriptions].reverse();
        for (let i = 0; i < subscriptions.length; ++i) {
          // @ts-expect-error it is just a mock
          if (subscriptions[i]()) {
            invokeDefault = false;
            break;
          }
        }

        if (invokeDefault) {
          exitApp();
        }
      },
    },
  };
});

hence, I should convert that into this:

jest.mock('react-native', () => {
  const _backPressSubscriptions = new Set();
  const exitApp = jest.fn();
  return {
    ...jest.requireActual("react-native"),
    BackHandler: {
      __esModule: true,
      default: {
        getSubscriptions: function (): number {
          return _backPressSubscriptions.size;
        },
        exitApp,
        addEventListener: function (
          _eventName: string,
          handler: () => boolean,
        ) {
          _backPressSubscriptions.add(handler);
          return {
            remove: () => {
              _backPressSubscriptions.delete(handler);
            },
          };
        },

        mockPressBack: function () {
          let invokeDefault = true;
          const subscriptions = [..._backPressSubscriptions].reverse();
          for (let i = 0; i < subscriptions.length; ++i) {
            // @ts-expect-error it is just a mock
            if (subscriptions[i]()) {
              invokeDefault = false;
              break;
            }
          }

          if (invokeDefault) {
            exitApp();
          }
        },
      },
    },
  };
});

Could you confirm that?

[huntie]

Tentatively yes — this aligns with any consumer of the react-native package not being able to reference internals, and we've migrated some of our own tests at Meta this way already.

As this is wide reaching, we may pursue a workaround for Jest and/or provide a migration guide when ready.

[jerone]

Am using the same mock for BackHandler in a similar fashion:

jest.mock<typeof import("react-native")>("react-native", () => {
  const originalModule =
    jest.requireActual<typeof import("react-native")>("react-native");

  const mockBackHandler = jest.requireActual<
    typeof import("react-native/Libraries/Utilities/BackHandler")
  >("react-native/Libraries/Utilities/__mocks__/BackHandler.js");

  // Mock `BackHandler` to use the mocked version that allows to simulate back button presses.
  Object.defineProperty(originalModule, "BackHandler", {
    get: () => mockBackHandler,
  });

  return originalModule;
});

I might as well copy-paste the mocked source, but hoping for an official solution...

[shirakaba]

My comment here flags some more Jest mocking (of the Platform API) that will stop working if deep imports are removed: #893 (comment)

[tido64]

[Done] Expose ReactNativeVersion (react/react-native#52784)

Is there a replacement for react-native/Libraries/Core/ReactNativeVersion? We use it in RNTA to display the current version. We copied this pattern from NewAppScreen.js which is also still using it.

(NOBRIDGE) WARN  Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Core/ReactNativeVersion'). Source: /~/example/App.tsx 14:0

[huntie]

Yeah needs to be promoted, and good to learn of another call site. I'll export a PR soon (as a mini RFC).

• Confusingly, we also have Platform.constants.reactNativeVersion, which is already public. However, this is not equivalent to ReactNativeVersion.js, as it's read from the native side and these values are actually compared at runtime in case of incompatibility.

[huntie]

react/react-native#52784

[graszka22]

[Resolved] Blob and BlobManager — use expo-blob

In our project we're using Blob and BlobManager from react-native/Libraries/Blob/Blob.js and react-native/Libraries/Blob/BlobManager.js for encrypting binary files obtained by fetching them with fetch:

const response = await fetch(url);
const blob = await response.blob();
// do stuff with blob and encrypt it

Will it be available in future react-native versions or will be there a replacement for it?

[reichhartd]

expo-blob provides a web standards-compliant Blob implementation for React Native.

[cipolleschi]

@graszka22 are you sure you need them for those purposes? I can't find anything related to encrypting binaries in the Blob.js and BlobManage.js files.

As @reichhartd mentioned, expo-blob provides an implementation. If you can't use expo, there is also react-native-blob-utils that you can use

[shirakaba]

Please expose parseErrorStack() and symbolicateStackTrace(), as there's really no alternative to them. Currently they're only available as deep imports, e.g.:

import parseErrorStack from "react-native/Libraries/Core/Devtools/parseErrorStack";

parseErrorStack() is necessary for doing things like printing out error.cause the same way Node.js does.

I notice they're not currently in the provisional public API.

Currently both React Navigation and Sentry are manually parsing the error stack, which seems fragile (especially with Static Hermes on the horizon), and an unreasonable maintenance burden to have to do in userland.

I also want to implement proper stack traces for my userland util.inspect() polyfill that brings error.cause logging to React Native.

[cortinico]

cc @vzaidman @huntie

[shirakaba]

I am currently relying on a deep import of react-native/Libraries/Utilities/Platform in order to mock Platform fully in Jest.

The Platform API is incompletely mocked in both React Native and Expo's Jest presets (react-native/jest-preset.js and jest-expo/jest-preset.js, respectively). Specifically, the Version field is left undefined. For lack of any documented way to mock it otherwise, the only solution I was able to get working relies on a deep import:

const ReactNative = require("react-native");
// This approach only works with a deep import, not a shallow import.
const Platform = require("react-native/Libraries/Utilities/Platform");

/** @type {"ios" | "android"} */
const OS = "ios";

/** @type {import("react-native").Platform} */
const PlatformCommon = {
  OS,
  constants: {
    reactNativeVersion: {
      major: 1000,
      minor: 0,
      patch: 0,
      prerelease: undefined,
    },
  },
  __constants: null,
  isPad: false,
  isTV: false,
  isVision: false,
  isTesting: undefined,
  isDisableAnimations: undefined,
  isMacCatalyst: false,
  select: function select(spec) {
    return OS in spec
      ? spec[OS]
      : "native" in spec
        ? spec.native
        : spec.default;
  },
};

// TODO: find a way to swap between these based on test
const IosPlatform = { ...PlatformCommon, Version: "17.5" };
const AndroidPlatform = { ...PlatformCommon, Version: 33 };
const ResolvedPlatform = OS === "ios" ? IosPlatform : AndroidPlatform;

Object.assign(Platform, ResolvedPlatform);

Object.defineProperties(ReactNative, {
  Platform: {
    get: () => ResolvedPlatform,
  },
});

To be clear, I'm not proposing to expose the Platform deep import, but saying that improving the Jest presets (and docs for mocking React Native in general) should be a prerequisite to removing deep imports. Because if deep imports were to be removed today, it would break a lot of userland Jest tests, with no viable workarounds.

[jerone]

@shirakaba I don't have a use-case for the Version inside Platform, but I did need select and got it working without needing deep-imports. Maybe you can find some inspiration...

/**
 * Mocks the `react-native` package.
 * It mocks the `Platform.select` method to return the value for the current platform.
 */
jest.mock<typeof import("react-native")>("react-native", () => {
  const originalModule =
    jest.requireActual<typeof import("react-native")>("react-native");

  // Mock the `Platform.select` method to return the value for the current platform.
  jest
    .spyOn(originalModule.Platform, "select")
    .mockImplementation((specifics: PlatformSelect<unknown>): unknown =>
      originalModule.Platform.OS in specifics
        ? specifics[originalModule.Platform.OS]
        : "native" in specifics
          ? specifics.native
          : specifics.default,
    );

  return originalModule;
});

[huextrat]

[Done] Expose Animated.CompositeAnimation type

CompositeAnimation is no longer exposed, before it was accessible Animated.CompositeAnimation

So if we have a parallel animation which has “CompositeAnimation” as its return type, it is not possible to correctly type my props

const bounceAnimation = Animated.parallel([
    Animated.sequence([
      Animated.timing(bounceAnim, {
        toValue: 1.04,
        duration: 100,
        useNativeDriver: true,
      }),
      Animated.timing(bounceAnim, {
        toValue: 1,
        duration: 100,
        useNativeDriver: true,
      }),
    ]),
  ]);

bounceAnimation: CompositeAnimation but there is no way to import the type

[huntie]

react/react-native#53538

[huextrat]

[Done] Expose ListViewToken type (react/react-native#53539)

ViewToken is no longer exposed, this one is useful for inViewableItemsChanged on FlatList

const onViewableItemsChanged = React.useRef(
    ({ changed }: { changed: Array<ViewToken> }) => {
      console.log("changed", changed);
    },
  );

<FlatList
    ref={flatListRef}
    onViewableItemsChanged={onViewableItemsChanged.current}
    ...

There doesn't seem to be any alternative to typing this correctly.

[huntie]

react/react-native#53539

[jbroma]

Re.Pack Development APIs

Context

Re.Pack's HMR client (WebpackHMRClient) reimplements React Native's HMRClient and uses the following APIs:

1. NativeRedBox & NativeExceptionsManager

Module Paths:

• react-native/Libraries/NativeModules/specs/NativeRedBox
• react-native/Libraries/Core/NativeExceptionsManager

Purpose:
Dismissing error overlays during HMR updates.

Implementation:

if (__PLATFORM__ === 'ios') {
  const NativeRedBox =
    require('react-native/Libraries/NativeModules/specs/NativeRedBox').default;
  NativeRedBox?.dismiss?.();
} else {
  const NativeExceptionsManager =
    require('react-native/Libraries/Core/NativeExceptionsManager').default;
  NativeExceptionsManager?.dismissRedbox();
}

Source: WebpackHMRClient.ts

---

2. DevLoadingView

Module Paths:

• react-native/Libraries/Utilities/DevLoadingView

Purpose:
Displaying and hiding loading HMR refresh/reload messages.

Implementation:

const LoadingView = require('react-native/Libraries/Utilities/DevLoadingView');
LoadingView.showMessage(text, type);

Source: WebpackHMRClient.ts

[natew]

+1 One/vxrn both use a variety of internals to do HMR - if you search the https://github.com/onejs/one there's few usages like ^^^

[exploIF]

Hi, in react-native-enriched we would like to use TextInputState, more precisely registerInput, unregisterInput, focusInput and blurInput.

import TextInputState from 'react-native/Libraries/Components/TextInput/TextInputState'

We need this to ensure that EnrichedTextInput and TextInput behave consistently inside scrollable elements (e.g., keyboardShouldPersistTaps).

[kosso]

Hi, I have just started seeing this warning after upgrading.

I use EventEmitter in various places in my tvOS and AndroidTV apps.

import EventEmitter from 'react-native/Libraries/vendor/emitter/EventEmitter'

What alternative do you suggest?

Thanks.

[valery-lavrik]

Hi! I have the same problem. Have you found a solution?

[AnaBearThis]

Same problem!

[tamlyn]

Expo has a similar class available import { EventEmitter } from "expo"

[chrisarts]

im creating a native video player implementation and im relying on resolveAssetSource some helpers in the RN lib are useful for library authors specially for tvOS and ATV due lack of tooling.

import resolveAssetSource from 'react-native/Libraries/Image/resolveAssetSource';

[liamjones]

@chrisarts This one is available on Image directly: https://reactnative.dev/docs/image#resolveassetsource

E.g. you can do Image.resolveAssetSource()

[ybentz]

I'm currently using polyfillGlobal from "react-native/Libraries/Utilities/PolyfillFunctions" to polyfill global JS APIs that I need but are missing in Hermes. Is there a different/better way to polyfill in React Native?

[huntie]

From user code, I'm pretty sure you can mutate global as with the web. polyfillGlobal is just a fancier internal util.

const originalXMLHttpRequest = global.XMLHttpRequest;
global.XMLHttpRequest = MyXMLHttpRequest;

[m1guelpf]

I'm currently using SceneTracker from "react-native/Libraries/Utilities/SceneTracker" to know which scene I'm in (my app renders multiple scenes simultaneously). Is there a better way to access this state?

[natew]

We use usePressability so we can avoid wrapping a new component and let our View/Text have the nicer onPress behavior like Pressables do:

https://github.com/tamagui/tamagui/blob/main/code/core/core/src/vendor/Pressability.native.tsx

[natew]

https://tamagui.dev uses usePressability to add press handling directly to styled View/Text
components. This avoids wrapping everything in , which:

1. Adds an extra View to the hierarchy
2. Can break flex layout expectations
3. Is inefficient when you already have the View you want to be pressable

The hook gives us the same quality press interactions that Pressable, Text, and TextInput use
internally—smooth press+hold+move behavior, scroll cancellation, hit slop support.

Proposed solution:

I've opened a PR to add this export: #54813

This is a stable internal API already used by multiple core components, so exposing it publicly
seems low-risk.

[huntie]

Looks good, will import and review with the team next week.

[t0maboro]

Hello,

In react-native-screens, we use AppContainer (ref. https://github.com/software-mansion/react-native-screens/blob/4.18.0/src/components/DebugContainer.tsx#L42) to ensure that LogBox is rendered above our modals. This approach is consistent with how modals are implemented in React Native (see: https://github.com/facebook/react-native/blob/v0.83.0-rc.4/packages/react-native/Libraries/Modal/Modal.js#L308-L312), and we'd like to keep this consistency.

I wanted to ask whether you've considered exposing AppContainer as part of the public API, or if you would recommend another equivalent solution to achieve the same behavior?

Thanks in advance!