Create styled-components package wrapper that lets you use components without react-native-web.

This may be necessary for styled-components/primitives SSR support, or for use cases where react-native-web isn't installed.

We should encourage the use of styled-components/primitives instead, in documentation.

This could be a new package like @react-platform/styled

Pseudo-code for the wrapper:

const styled = Platform.select({
  web: () => require('styled-components'),
  default: () => require('styled-components/primitives'),
})();

if (Platform.OS === 'web') {
  styled.View = styled.div;
  styled.Text = styled.span;
  styled.Image = styled.img;
} else {
  styled.div = styled.View;
  styled.img = styled.Image;
  styled.span = styled.Text;
}

module.exports = styled;

It appears that web window.screen.width and window.innerWidth have some unreliable behaviour on desktop, e.g. when resizing a window to mobile width, and on a mobile device, where the viewport is artificial, but innerWidth isn't.

I've implemented a hack with a comparison operator, but this needs to be tested, and needs feedback.

This deviates from using react-native-web, which uses window.innerHeight and window.innerWidth, which in my testing seem to not render density independent pixels, as they do on React Native: https://github.com/necolas/react-native-web/blob/master/packages/react-native-web/src/exports/useWindowDimensions/index.js#L19 . So maybe this should be raised as an issue there?

Need some better documentation around the react-primitives ecosystem, and examples of using the @react-platform namespace in each platform: e.g.

Since react-native-desktop-qt is no longer supported, an ideal replacement would be NodeGUI which already supports React via React NodeGUI, this would be ideal as it also is built on Qt.

As I haven't used Expo for React Native before, and generally like having control over native linking/code, would be great to have some feedback/testing from others on this.

I think this should be Expo compatible? Dependencies should already be installed and should just resolve fine?

Do we want to support React Native's Dimensions and PixelRatio? Or discourage their use?

I propose supporting them, and adding injection systems for react-sketchapp to use global screen dimensions and pixel ratio values, but to later have an opt-out console warning layer to discourage their use and push for using useWindowDimensions instead, as dimensions should not be used as static values.

The main use-case for this would be aliasing react-sketchapp/react-figma to @react-platform/native and keeping things somewhat working. While aliasing will be discouraged by this project, it's a nice way to get a quick proof-of-concept running before refactoring a codebase to import common primitives.

Develop a Rollup plugin to resolve platform cascades/extensions.

This could be accompanied by a Webpack plugin, for web entrypoints, but extension resolving for apps could be avoided by using this code pattern:

core.js

let _module;

if (typeof window !== 'undefined) {
  _module = require('./core.web');
} else {
  _module = require('./polyfill'); // JS/React only implementation e.g. render null + console.warns
}

module.exports = _module;

Implemented components:

Hooks

• useWindowDimensions – 7f98478
• useColorScheme

Components

• <ScrollView>
• <SafeAreaView>
• <Modal>
• <TextInput>
• TODO: Populate from sidebar at https://reactnative.dev/docs/components-and-apis

APIs

• AppState
• Alert
• Dimensions #3
• PixelRatio #3
• Linking (requires runtime I think? Is react-sketchapp support possible?)
• Share – Maybe this'll have to be a hook ? May need a context provider to handle the UI.
• TODO: Populate from https://reactnative.dev/docs/accessibilityinfo

[WIP umbrella issue for discussion/ideas, to help surface proposals]

What counts as a React platform?

Is using react-reconciler enough to count as a platform? Or does react-test-renderer count, for the case of react-sketchapp?

Will Metro be an explicit requirement, or will Webpack/ be supported as entrypoint bundlers?

• Some runtime environments may be in sandboxes where running bundlers like Metro aren't appropriate, such as in design software plugins, where file extensions are nice as a universally accepted standard across bundlers, especially with Babel extension preferences.
• Should file extensions remain a stable/supported default for out-of-tree platforms?

How should imports work?

• Is import { ... } from 'react-native'; a safe pattern for out-of-tree platforms?
• How can we make sure that props are types without tsconfig hacks?

Proposal

Standardise platform-specific imports around react-native-ios, react-native-windows, or @react-native/ios.

Support react-native as a common API surface across platforms, or have react-platform/react-primitives as a common API layer that maps to react-native-windows, etc. Or have react-primitives for react-reconciler platforms that don't have the full Metro/Fabric setup (e.g. react-primitives View import aliases to react-native-<platform> <View>, and react-native for those that do.

We should decide how the core package: @react-platform/core will work. For now, it should probably remain unpublished, and provide a set of common APIs like Platform, and maybe supported platform enums? With a core injection API that doesn't depend on platform specific internals like react-native-web?

Or just re-export react-primitives for now?

We should have a common injection layer package that allows the implementation of new platforms.