Add static platform check props

[ryanlntn]

Summary:

I've noticed that a lot of RN projects have something along the lines of the following in them:

export const isAndroid = Platform.OS === 'android'
export const isIOS = Platform.OS === 'ios'

This seems common enough that I think it makes sense to just export these from RN itself. Platform already has isPad and isTV. This would add another way to express platform checks with that API.

Changelog:

[GENERAL] [ADDED] - Adds isAndroid, isIOS, isMacOS, isNative, isWeb, and isWindows static properties to Platform

Test Plan:

I just patched these into a demo app. Here's a screenshot:

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,755,105	-147
android	hermes	armeabi-v7a	8,067,667	-159
android	hermes	x86	9,247,692	-161
android	hermes	x86_64	9,096,829	-156
android	jsc	arm64-v8a	9,316,217	-243
android	jsc	armeabi-v7a	8,506,127	-231
android	jsc	x86	9,379,701	-246
android	jsc	x86_64	9,632,951	-238

Base commit: c870a52
Branch: main

[Pranav-yadav]

This would be awesome!
But, this is kind of "redundant" since:

1. Android and iOS will use and read from their respective files.
2. If the platform is Android this would implicitly mean it's not iOS, etc., and vice-versa?
3. Why would an Android app would need a check for MacOS, native, web, and Win similarly for iOS app?
4. If we want to support (check) all these platforms then we should create another generic file (interface with "all props optional") that will define/expose them.

WDYT?
P.S.: I may be unaware of the full context here :)

[ryanlntn]

It is certainly redundant. I've just noticed that many RN projects have the same const isAndroid = Platform.OS === 'android' declared and thought there may as well be a utility for devs to express one off platform checks this way offered directly by RN.

[NickGerleman]

The current design here is that OS is a string constant, defined per platform. This allows platforms to work out-of-tree, public or private, by defining their own constant. So, the mechanism you use to check for iOS/Android is the same whether you are developing on a phone, on desktop, or a PlayStation. This is something we lose with this change.

It also means we need to update this centralized list, and if a platform loses support, we need to either break API, or keep around a dead interface.

Some of that has leaked into the TypeScript typings in this repo that used to be on DefinitelyTyped, but out-of-tree platforms like React Native Windows have more recently gained general ability to re-export their own types, and tell tsc to resolve types for a specific platform during typechecking.

@motiz88 pointed out offline that Metro has Babel transforms which use Platform.OS conditions in the AST to strip code for platforms not being bundled for. So switching to these helpers would defeat the dead code elimination.

[ryanlntn]

@NickGerleman Good to know. What do you think about something like Platform.is('ios') that just wraps the Platform.OS condition? That could use PlatformOSType for now and would still read similar. Not sure if Babel transforms would still be a problem with that.

[motiz88]

@ryanlntn

What do you think about something like Platform.is('ios') that just wraps the Platform.OS condition?

My main question here is "why?" What does this achieve from a user's perspective that Platform.OS === 'ios' doesn't?

I don't mean to sound harsh. It's just that, considering the extra effort required to optimise and then teach this proposed new API, I'm afraid such an API wouldn't be all that valuable. (If anything we should be looking at ways to deprecate and then remove the existing Platform.isPad and Platform.isTV.)

I think we'd certainly be open to a new API if one is warranted, but we should probably discuss the motivation and design in an RFC before going any further with an implementation.

[ryanlntn]

@motiz88

My main question here is "why?" What does this achieve from a user's perspective that Platform.OS === 'ios' doesn't?

In terms of functionality it doesn't accomplish anything new. And yet as stated above almost every RN project I've seen has something along the lines of const isAndroid = Platform.OS === 'android' in it. So there's something about expressing one off platform checks that way that appeals to people.

I don't mean to sound harsh. It's just that, considering the extra effort required to optimise and then teach this proposed new API, I'm afraid such an API wouldn't be all that valuable. (If anything we should be looking at ways to deprecate and then remove the existing Platform.isPad and Platform.isTV.)

I'm curious about these optimizations. I was unaware that there was a babel transform stripping dead code based on Platform.OS conditions. Would people assigning const isAndroid = Platform.OS === 'android' and checking against isAndroid break that or would it still work in that case? Is this documented somewhere?

I think we'd certainly be open to a new API if one is warranted, but we should probably discuss the motivation and design in an RFC before going any further with an implementation.

Fair enough.

[jamonholmgren]

Can confirm, having isAndroid etc is definitely common among our clients over the past 7+ years of doing RN consulting.

[ryanlntn]

Opened an RFC.

[NickGerleman]

I'm curious about these optimizations. I was unaware that there was a babel transform stripping dead code based on Platform.OS conditions. Would people assigning const isAndroid = Platform.OS === 'android' and checking against isAndroid break that or would it still work in that case? Is this documented somewhere?

I'm not sure this is documented, but here is a link to where Platform.OS is replaced with the platform being bundled for. https://github.com/facebook/metro/blob/c6a94bc170cf95a6bb21b5638929ec3311a9a5b7/packages/metro-transform-plugins/src/inline-plugin.js#L152

So, a condition might be transformed to a constant comparison like if ('android' === 'ios') { which is is able to be optimized away. I think the same would apply to the above example, but I am less familiar with the other transforms and optimizations to know if it has the same overall effect if used in a condition (Moti may know more). You can always inspect the bundled JS to know for sure what was emitted.

I tend to agree though, that adding Platform.is('android') doesn't seem to enable more than the existing Platform.OS === 'android', beyond saving a couple of keystrokes.

[github-actions]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stalled for 7 days with no activity.