Exporting types

[necolas]

I'm looking for input from people who use typed JavaScript with this library.

1. If you use Flow or TypeScript, how do you type react-native-web exports?
2. If you work across platforms, how do you deal with platform-specific differences in the APIs or components like View?
3. Does this library need to export Flow and TypeScript types?
4. Is there a way to generate TypeScript interfaces from Flow types so you don't need to maintain both?

[EvanBacon]

Here is a useful dialog about TypeScript in RNW: #832

There is no DefinitelyTyped package for react-native-web. I'm not entirely sure how one would work (efficiently). I've seen people propose copying all react-native types and then extending them, and somehow aliasing types/react-native to types/react-native-web. This of course wouldn't work with other out-of-tree solutions so I would discourage the approach.

Personally I would opt for universal packages like "react animated" or "react text" (probably not with these names since they're all taken). These universal packages would implement iOS, Android, and web in the same place. Said approach would also fix some versioning issues and help reduce the custom bundler configuration required for universal React apps.

I will note that RN is now moving towards a monorepo structure (creating packages like react-native/normalize-color color and react-native/polyfills) which could make modifications like this more feasible.

At Expo, we've refactored all of our universal React packages from flow to TypeScript (as opposed to adding external type definitions files .d.ts) because we find this is easier to work with from a DX perspective.

I personally think that having better types will help bring more visibility to important react-native-web features (e.g. href on Text). Due to the high demand in the Expo/React community for TypeScript support on web, I may look at creating some abstract packages which reexport react-native(-web) modules with proper types.

[paularmstrong]

In Build Tracker (typescript, web-only), I pulled the react-native types from definitely-typed, then removed all of the iOS/Android specific stuff and added web-specific bits (source). Ideally I would take the few minutes to contribute this back, but I don't feel comfortable enough with my knowledge on Typescript to really be authoritative that any of it was done correctly.

At Twitter, we have our own flow definitions for react-native-web, but had built this up before this package was exporting most of its types. Ideally, we would love to use the source here, but have found that our type definitions tend to be more strict (which we like).

Is there a way to generate TypeScript interfaces from Flow types so you don't need to maintain both?

There is an inverse for this using flow-typed, though it's not 100% working. I've found it work for maybe 75% of the times I've used it. The times it didn't, some light hand-editing fixed it.

[necolas]

@EvanBacon I don't know that much of what you suggested is actionable. I'm a bit concerned about the implication that you're going to repackage everything under different packages

@paularmstrong I wasn't aware this package was exporting types at all 😅 Would be happy to hear about what your flow types look like and what stricter types could be upstreamed

[paularmstrong]

Ah, they're not exporting types, correct. I believe I had done something with the module.name_mapper to re-map to the src files. It worked out okay, but not everything was fully typed at the time. And the main index.js not having // @flow at the top was problematic as well.

I'm not as connected with that area of our code anymore, so I'm not certain what we have that's more strict. Maybe @comp615 has some thoughts on that.

The one thing that I've noticed that's really nice about the TypeScript types from react-native that I'm using in Build Tracker is that the StyleSheet props are fully typed and throws errors if you use a style that isn't allowed (like color on a View doesn't work, but will on Text). We definitely don't have that same level of strict typing in Flow.

[comp615]

I filed a ticket during the last update (pre 0.13) to look into using the RNW types by default (with Paul's mapper hack) instead of our typedef module file. As @paularmstrong mentioned, they are not currently exported in RNW, which would be a great (and I think easy?) starting point to alleviate some of the boilerplate.

In particular, it would really help with major updates since it makes it much more trivial to track down all the things that changed and have certainty around them since they'd rely on the real source definition and not our manual list. I found it very useful last upgrade to read the release notes and update our flow file accordingly, and then go fix each usage in our code where there was a flow error.

[necolas]

What's the best way to export the types? Babel is currently stripping them when it compiles the files.

[paularmstrong]

flow-copy-source or DIY copy every file over to your dist directory and add .flow as the final extension. Probably also need to ensure // @flow is at the top of every file that supports types

[Albert-Gao]

Environment:

• expo SDK v38 (managed workflow)
• "@types/react-native": "~0.63.6"
• "react-native-web": "~0.13.5"
• "typescript": "~3.9.7"
• "react": "0.0.0-experimental-4c8c98ab9"
• "react-dom": "0.0.0-experimental-4c8c98ab9"

I do not use any new API from RN v0.63, so so far no problem.

For my project, for any cross-platform components,

two cases:

1. the native and web share the same signature.
   • I create the components.tsx and components.web.tsx, and always use components.tsx as the source when importing.
2. the native and web share a different signature.
   • I create a single entry like component.tsx and deal with the platform difference from there, like the above and platform check.

And all the type info, I just use from @types/react-native

No problems and works great.

So, I always share the same signature across platforms. Because I do not want to propagate the platform differences to the caller, so the vast majority of the codebase can be platform agnostic.

In short,

I think if react-native-web can maintain an exact same type info match to @types/react-native, that will be awesome, but if there are any differences, just need to doc it, and I am fine with that, that just means, for any differences, we might need to create this one more abstraction (for example different file extension and implementation for a different platform) for every difference that we are using in the user-land code, but that is totally understandable.

But if the API surface can be 100% percent compatible (for non-supported, won't throw an error), then it should be fine to just use the @types/react-native, otherwise, seems unnecessary and maintaining the types are a big task

thanks for the awesome package, so beautiful.

[necolas]

I came here because I was shocked to find out that there's no Typescript types

Well, RN is Flow typed and doesn't provide TS types, so I don't know what you're pretending to be so shocked about.

I would advice leveraging on @types/react-native instead

Those types aren't accurate for Windows or Web.

[aelesia]

Well, RN is Flow typed and doesn't provide TS types, so I don't know what you're pretending to be so shocked about.

Most RN libraries provide types.

Those types aren't accurate for Windows or Web.

Can you give examples of which parts aren't accurate?

Offhand I can only think of ScrollView: { bounces: boolean } , which itself isn't even accurate for mobile because it's not supported on Android.

[JavanPoirier]

I'm not entirely sure how one would work (efficiently). I've seen people propose copying all react-native types and then extending them, and somehow aliasing types/react-native to types/react-native-web. This of course wouldn't work with other out-of-tree solutions so I would discourage the approach.

@EvanBacon, At You.i TV we have a out of tree RN solution to extend to 11+ platforms and I did just that for our type definitions. I extend from the official RN types and Omit/Pick the types as needed. You mention, "This of course wouldn't work with other out-of-tree solutions so I would discourage the approach." I fail to see how this is the case. Can you please explain?

As omitting/picking the types is a job of its own, for now I am happy to have all RN types for RN Web vs none. So I just pointed the RN types to it with: yarn add -D @types/react-native-web@npm:@types/react-native

You can also just install @types/react-native and point the type package to react-native-web through your tsconfig.js:

{
  "compilerOptions": {
    ...
    "baseUrl": "./", // Required with the use of paths. May differ depending on project structure.
    "paths": {
      "@types/react-native-web": ["./node_modules/@types/react-native"]
    },
    ...
  }
}

[JavanPoirier]

@necolas, I could look into writing the initial TypeScript definition file for this library. I see that the Flow types are include in the repo. I am not experienced with Flow, however would you like to the types to be included here (like Flow) or in Definitely Typed?