TypeScript type definition ReactNode not compatible with React Native strings.

Description

Note
This report is similar to this existing bug report. The existing bug report is not actionable due to a missing reproducer and the use of an outdated React Native version.

In this bug report, a reproducer is included and the latest version is used.
Additionally, more specific details regarding the issue are provided.

Context
React and React Native come with TypeScript support.
Both the React documentation and the React Native documentation reference npm package @react/types as the package used to provide types.

In addition to the types defined by the package, Typescript itself includes some special, extra JSX type checks. Prior to TypeScript version 5.1, it would ensure that components that you used with JSX syntax such as <MyComponent/> could actually be used as JSX by making sure their return value matched global type JSX.Element. From TypeScript 5.1 onwards, it improved this type check to make sure that the return type matches JSX.ElementType.

@types/react makes sure that JSX.ElementType resolves to a function that returnsReact.ReactNode when type checking functional components.

Clearly, the type React.ReactNode has found its place as an integral part of typed React and React Native.
It is defined as the following type in TypeScript 5.0.4, the most recently supported version :

type ReactNode =
        | ReactElement
        | string
        | number
        | Iterable<ReactNode>
        | ReactPortal
        | boolean
        | null
        | undefined
        | DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_REACT_NODES[
            keyof DO_NOT_USE_OR_YOU_WILL_BE_FIRED_EXPERIMENTAL_REACT_NODES
        ];

This type matches the list of types belonging to a React Node as listed here in the React Native documentation.

Problem
Conceptually, the ReactNode is anything that can be rendered by React, and this is the same in React in the DOM as in React Native.

But in practice, React Native cannot actually render strings directly. They need to be wrapped with a <Text/> node to be used.

Since the same TypeScript package is used in both React in the DOM as in React Native, this leads to incorrect type checking at compile-time in React Native. By default, the types will assert that components can accept raw strings as children, when really only the Text component can. The result is possible run-time crashes due to broken type safety.

When React Native gets upgraded to support TypeScript 5.1, this will turn into a new issue. Functional components written
as JSX will be type checked by making sure that the function returns a ReactNode, as explained above. That means thay any functional component that returns a string will pass this check, but break at runtime. For instance, this will pass the type check but break:

<View><ComponentThatReturnsString /></View>

Possible resolution
A separate type could be created for React Native that more accurately reflects the types that the components actually support. Specifically, string could be removed from this new type, as string appears to explicitly be for React on the web. This solves the issue pre TS 5.1 where strings can be passed as children, and the issue post TS 5.1 where components can return strings. Next, the Text component should get its own separate type so that it can allow children to include a string as an exception to the rule.

Steps to reproduce

1. Clone the reproducer app here:
   https://github.com/MCOrdina/stringsinrn
2. install the node modules: npm install
3. run a typescript check in the project to see that there are no type issues: ./node_modules/.bin/tsc --noEmit
4. run the project. For instance using npm run start and npm run android
5. See that the project crashes with the following error:

React Native Version

0.73.4

Affected Platforms

Runtime - Android, Runtime - iOS, Build - MacOS, Build - Windows, Build - Linux

Output of npx react-native info

System:
  OS: macOS 14.3
  CPU: (12) arm64 Apple M2 Pro
  Memory: 121.06 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.10.0
    path: ~/.nvm/versions/node/v20.10.0/bin/node
  Yarn: Not Found
  npm:
    version: 10.2.3
    path: ~/.nvm/versions/node/v20.10.0/bin/npm
  Watchman:
    version: 2023.12.04.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.14.3
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 22.2
      - iOS 16.2
      - macOS 13.1
      - tvOS 16.1
      - watchOS 9.1
  Android SDK: Not Found
IDEs:
  Android Studio: 2022.2 AI-222.4459.24.2221.10121639
  Xcode:
    version: 14.2/14C18
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.9
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.4
    wanted: 0.73.4
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Stacktrace or Logs

ERROR  Error: Text strings must be rendered within a <Text> component.

This error is located at:
    in RCTView (created by View)
    in View (created by App)
    in App
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer
    in ReproducerApp(RootComponent), js engine: hermes

Reproducer

https://github.com/MCOrdina/stringsinrn

Screenshots and Videos

Inizia con il reproducer stringsinrn collegato, esegui npm install, ./node_modules/.bin/tsc --noEmit e l’app Android per confrontare la stringa raw accettata con il crash a runtime. Leggi il comportamento dei tipi React Native e ReactNode descritto nell’issue. Il lavoro è completato quando i tipi React Native rifiutano le stringhe raw non supportate preservando al contempo i figli string per Text, e il reproducer supera il type-checking e viene eseguito correttamente.