[Web] Add Platform module for web target

[EvanBacon]

Summary

Added a Platform file for module for instances where internal modules need Platform.
ex:

react-native/Libraries/Utilities/Dimensions.js

Line 14 in 78be6ef

const Platform = require('Platform');

Changelog

• Added Libraries/Utilities/Platform.web.js
  [CATEGORY] [TYPE] - Message

Test Plan

everything should pass.

[pull-bot]

	Messages
📖	📋 Changelog Format - Did you include a Changelog? A changelog entry has the following format: [CATEGORY] [TYPE] - Message.

Generated by 🚫 dangerJS against 11b158c

[cpojer]

Please check out Platform.ios for the proper flow typing of this file. Otherwise, yeah let's do this!

[TheSavior]

Why does this need to live in core? Do we need to have Platform files for all the platforms people make? Platform.windows.js, Platform.vr.js, Platform.firetv.js? How do those projects currently support these additional platform checks without this file currently existing in the repo?

[EvanBacon]

@TheSavior the problem with this particular module is that libraries like Dimensions require it. In RNWeb they have a web module for Platform but react-native's version of Dimensions doesn't have access to it. If any module internally accesses Dimensions then it won't know how to properly handle this import.

Attempting to use something very unrelated like AnimatedEvent will create a tricky error. Currently I have a webpack monkey-patch but it adds significant time to the bundler.

Animated/src/AnimatedEvent -> Renderer/shims/ReactNative -> Renderer/oss/ReactNativeRenderer-dev -> Core/InitializeCore -> Devtools/setupDevtools -> WebSocket/WebSocket -> Utilities/Platform which doesn't exist.

A few modules have this same effect. HMRLoadingView, Systrace, and some networking stuff.

[TheSavior]

While we should probably merge this just to unblock, I'd really like to have a solution that doesn't require all the platforms to add themselves to the core. Could you think about this and see if you can come up with a solution? :)

[TheSavior]

In the case of Dimensions, it looks like Android is special cased because the object we get from the device is different on iOS than Android:
https://github.com/facebook/react-native/blob/master/Libraries/Utilities/Dimensions.js#L44-L56

Dimensions comes from native here:
https://github.com/facebook/react-native/blob/master/Libraries/Utilities/Dimensions.js#L125-L140

It seems like the platforms should be unified on the data they provide to JS so that it can be calculated consistently. At which point other platforms have a standard API to report dimensions through and it doesn't need platform checks.

[EvanBacon]

@TheSavior AFAIK this is (should be) the only place we define the platform OS value it would seem that adding a new file to Platform is the best solution. Perhaps we could read something from the bundler like process.env on web, but that seems hacky and not scalable.
Depending on how native modules work, maybe a platform could have a native platform module with the same name. That native module could then export the name of it's own OS as a constant. That way it's modular and dependent on the platform. On web we need to think of a way to "install" a native module so it could be accessed the same way as iOS and Android, but this should cover windows.

In the case of Dimensions, it looks like Android is special cased because the object we get from the device is different on iOS than Android:

This paradigm seems fine. I think there should be a way to access Platform from within any module. I would rather fix Platform than change every internal module that uses it.

[matthargett]

For an example of how another out-of-tree platform does this:
https://github.com/Microsoft/react-native-windows/blob/master/Libraries/Utilities/Platform.windows.js

Fully agree with @TheSavior , figuring out a way to do this that doesn't require RN itself having a master list of all platforms is key. At my previous job, we were able to bundle RN Windows app using haul which is webpack underneath.

Of course, I'm open to learning something if there's some counter-indication you have in your specific situation :D

[cpojer]

Agree we should figure out a long term plan but I don't think that's a reason to block landing this PR.

[facebook-github-bot]

@cpojer is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[react-native-bot]

@EvanBacon merged commit daa79b0 into facebook:master.