Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[standards] Umbrella issue to track migration to standard path-based requires (remove Haste) #24316

Closed
ide opened this issue Apr 4, 2019 · 2 comments

Comments

@ide
Copy link
Collaborator

commented Apr 4, 2019

This issue tracks commits that rewrite require() calls to use standard module paths instead of Haste module names. This brings the RN repo closer to how the React repo is set up, and also opens the door for greater compatibility with the last 10 years of tooling that uses path-based module locations, and eliminates the entire class of issues related to the Haste map outside of the Facebook context.

All modules in the RN repository will still be requireable via Haste. That is, if there's Facebook application code that uses Haste, there will be no change.

This is a spiritual continuation of #18598, which has more technical details.


Draft Announcement Notes

Replacing Haste with standard imports

In the 0.61 release of React Native, we are internally replacing "Haste"-style module imports with standard path-based imports. Instead of require('View'), React Native will internally use require('./View'). Haste is a proprietary module system with a global namespace that is used within Facebook. Path-based imports are used by browsers, Node.js, and various tools and libraries in the greater JavaScript ecosystem. Moving to the standard means React Native will be more compatible with the ecosystem. Also, this creates a path to optimize the bundling step, as the bundler no longer needs to scan all files to create the Haste module map.

Some out-of-tree implementations of other platforms, like React Native Windows, may be affected by this change if they rely on overriding files using overlapping Haste module names. There are two potential solutions for maintainers of platforms like this.

Vendoring React Native

One solution is to follow React Native for Web's approach of vendoring (copying) React Native's code into the out-of-tree platform repository. This approach is also more future-proof and works if React Native were to publish itself as a single "flat bundle" in the same manner as React, which would also be a breaking change for out-of-tree platform implementations. It also simplifies the work required if React Native were to rely on the JS interpreter's built-in import/export module system, which does not implement Haste.

React Native for Web's entry point (index.js) exports web-specific implementations of all the public APIs in React Native. But, sometimes, parts of React Native's code also run on the web without any changes. To share code with React Native, React Native for Web imports the code it vendored from React Native. For example, React Native for Web's implementation of PanResponder uses React Native's implementation:

import PanResponder from '../../vendor/react-native/PanResponder';
export default PanResponder;

Finally, React Native for Web provides a Babel plugin that rewrites all imports of react-native in your application code to import react-native-web instead. For example, import { View } from 'react-native' is rewritten to import { View } from 'react-native-web'.

React Native for Web's approach provides stability, as newly published patch versions of React Native -- which may have internal breaking changes despite keeping the public API unchanged -- will not affect the vendored code at all until the maintainer intentionally updates it.

Overriding imports with Babel

Another solution is to write a Babel plugin that rewrites imports to files that need to be overridden. For example, let's say an out-of-tree platform needs to override React Native's View.js and that the overriding file is under react-native-xx/View.xx.js. Using a Babel plugin, one can rewrite all imports of React Native's View.js to instead import react-native-xx/View.xx.js. This Babel plugin simulates the current behavior of overriding files using Haste.

@ide ide added the Type: Discussion label Apr 4, 2019

ide added a commit to expo/react-native that referenced this issue Apr 4, 2019

[standards] Rewrite imports in RNTester to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

Test Plan: Run RNTester and verify that it loads without any issues. Tap through each screen to ensure the JS modules load (that is, were bundled) correctly.

ide added a commit to expo/react-native that referenced this issue Apr 4, 2019

[standards] Rewrite imports in RNTester to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

Test Plan: Run RNTester and verify that it loads without any issues. Tap through each screen to ensure the JS modules load (that is, were bundled) correctly.

ide added a commit to expo/react-native that referenced this issue Apr 4, 2019

[standards] Rewrite imports in RNTester to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

Test Plan: Run RNTester and verify that it loads without any issues. Tap through each screen to ensure the JS modules load (that is, were bundled) correctly.

ide added a commit to expo/react-native that referenced this issue Apr 5, 2019

[standards] Rewrite imports in RNTester to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

Test Plan: Run RNTester and verify that it loads without any issues. Tap through each screen to ensure the JS modules load (that is, were bundled) correctly.

ide added a commit to expo/react-native that referenced this issue Apr 5, 2019

[standards] Rewrite imports in YellowBox to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the YellowBox component.

[General] [Changed] - Replaced Haste-style imports with standard path-style imports for YellowBox

Run RNTester and verify that it loads without any issues when it display a warning.

ide added a commit to expo/react-native that referenced this issue Apr 5, 2019

[standards] Rewrite imports in YellowBox to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the YellowBox component.

[General] [Changed] - Replaced Haste-style imports with standard path-style imports for YellowBox

Run RNTester and verify that it loads without any issues when it display a warning.

facebook-github-bot added a commit that referenced this issue Apr 8, 2019

Set up .flowconfig to support Haste and path-based imports (#24318)
Summary:
See #24316 for the motivation.

By adding the .android.js and .ios.js extensions to the respective .flowconfig files, Flow is able to find files that either:

- Are required using Haste
- Are required using standard paths and have a .js extension
- Are required using standard paths and have a .platform.js subextension

[General] [Changed] - Adjusted .flowconfig to support both Haste and standard path-based requires
Pull Request resolved: #24318

Differential Revision: D14822356

Pulled By: cpojer

fbshipit-source-id: dde0c83692d6170f4a44cd3fb8ede162054157e9

zhongwuzw added a commit to zhongwuzw/react-native that referenced this issue Apr 9, 2019

Set up .flowconfig to support Haste and path-based imports (facebook#…
…24318)

Summary:
See facebook#24316 for the motivation.

By adding the .android.js and .ios.js extensions to the respective .flowconfig files, Flow is able to find files that either:

- Are required using Haste
- Are required using standard paths and have a .js extension
- Are required using standard paths and have a .platform.js subextension

[General] [Changed] - Adjusted .flowconfig to support both Haste and standard path-based requires
Pull Request resolved: facebook#24318

Differential Revision: D14822356

Pulled By: cpojer

fbshipit-source-id: dde0c83692d6170f4a44cd3fb8ede162054157e9

zhongwuzw added a commit to zhongwuzw/react-native that referenced this issue Apr 9, 2019

Rebase
Expose collapsable as React Prop in LayoutShadowNode

Summary: This diff exposes the collapsable prop as part of LayoutShadowNode, fixing the bug of the collapsable prop being filtered by JS in Fabric

Reviewed By: shergin

Differential Revision: D14594522

fbshipit-source-id: a892ba8228e76f11232acc6fe5c8d75e991d8fc6

Add logs in mounting layer

Summary: Adds debug logging in FabricUIManager and the mounting layer of Fabric.

Reviewed By: shergin

Differential Revision: D14594521

fbshipit-source-id: a5c0ee39e1bac8a340849ca3e044694cbee5427e

Refactor mapping of FabricComponentNames

Summary: Simple diff that refactors the usage of the sComponentNames to not require components to be part of the mapping when the name in JS is the same as the name in Native side.

Reviewed By: shergin

Differential Revision: D14594659

fbshipit-source-id: d1948b27e04686fefbf9b6e2b06d4f9317b97062

Fix scrolling of Android Horizontal Scroll View

Summary:
This diff fixes the scrolling of Android Horizontal Scroll View, the root cause was that Binding was mounting a ScrollView instead of an AndroidHorizontalScrollView component.
This will be automatically fixed when all the View components are autogenerated.

Reviewed By: shergin

Differential Revision: D14594622

fbshipit-source-id: 7c477ca167188ea9c473f61145461d3cf1696e17

Small changes to State objects to support Android

Summary: Small changes to State objects to support Android. See following diffs.

Reviewed By: mdvacca

Differential Revision: D14663470

fbshipit-source-id: 878f4dc39265991a7b8ff54ca80bdb862f1dd3de

TM iOS: force flush message queue when calling into JS from native

Summary: When calling into JS (e.g. promise resolve/reject, callback) in TurboModule, we bypass the bridge's message queue. At times this causes race condition, where there are a bunch of pending UI operations (in RCTUImanager) waiting to be flushed, but nothing adds calls to the message queue. Usually tapping the screen will trigger the flush because we're sending down touch events to JS.

Reviewed By: JoshuaGross

Differential Revision: D14656466

fbshipit-source-id: cb3a174e97542bf80f0a37b4170b6a8e6780fa35

Fix invalid CGContext when invalidate layer (#24195)

Summary:
If size is zero, the `CGContext` would invalid, so we need to filter zero things.
cc. shergin

[iOS] [Fixed] - Fix invalid CGContext when invalidate layer
Pull Request resolved: https://github.com/facebook/react-native/pull/24195

Differential Revision: D14683396

Pulled By: shergin

fbshipit-source-id: b5b45fb86ca3158284281460cf1d95d1b22eab0d

use shared mutex in RCTSurfacePresenter

Summary:
Otherwise reloading from metro deadlocks like this:
`[RCTSurfaceRegistry _stopAllSurfaces]` is calling `[RCTSurfaceRegistry enumerateWithBlock]` which locks `_mutex` and then we call `surfaceForRootTag` which then deadlocks on the same mutex:
https://pxl.cl/tmm1

Reviewed By: shergin

Differential Revision: D14679843

fbshipit-source-id: 9f4ecdfa7a79fcf7f3fc2ce437d4399b00910f26

TM Android: temporarily disable callback support to unbreak build

Summary: With the recent change, JSCallInvoker now expects `Instance` to be passed in, not just the `MessageQueueThread`. There needs to be more plumbing to get the instance of `Instance` from the Java side, but this commit is just to unbreak the build temporarily.

Reviewed By: JoshuaGross

Differential Revision: D14687622

fbshipit-source-id: 42e0173ee8336fc5660fe8188a1e1f8517611521

Move WebView JS files to FB internal

Summary: This moves all the JS files and updates the BUCK files. The next step is to move the Android and iOS native files.

Reviewed By: TheSavior

Differential Revision: D14618890

fbshipit-source-id: 42984acdf5920e712f272d5742c778943be37ac5

Back out "[react-native][PR] There is a small gap in the SynchronizedWeakHashSet implementation. T?"

Summary: Original commit changeset: 2998bffb06e2

Reviewed By: JoshuaGross

Differential Revision: D14689422

fbshipit-source-id: 2638bed8005859cc95972ba5f78a9e9cace878ef

Back out "[react-native][PR][Microsoft] This change fixes currently broken ReactContext listeners mechanism."

Summary: Original commit changeset: d506e5035a7f

Reviewed By: JoshuaGross

Differential Revision: D14689559

fbshipit-source-id: 9a8c8be0d2b7b9dd9be1ec038d7c3b356a5e3adf

Move requireNativeComponent calls to standalone files

Summary: Moves a number of requireNativeComponent calls to standalone files to support codegen

Reviewed By: TheSavior

Differential Revision: D14654018

fbshipit-source-id: 349b975cd3a99a9373b2b9b1a19aa311d7c36399

Fabric: Fixed a bug in Diffing algorithm

Summary: Before the fix, the algorithm compares ShadowViews to make a decision should it recursively call itself or not; that didn't work properly because a ShadowView doesn't fully represent the state of the subtree tree (e.g. they don't have information about children nodes). After the fix, we compare pointers to ShadowNodes (by comparing pairs).

Reviewed By: mdvacca

Differential Revision: D14696996

fbshipit-source-id: 560d623b15a272f13b08a11745dec6be39a5dbdd

Fabric: Removed log leftover

Summary: Trivial.

Reviewed By: mdvacca

Differential Revision: D14696997

fbshipit-source-id: 5f093ae5f343f2a2a2ee060f0574a6acf4c186d4

Disable view pooling

Summary:
Temporarily disable View Pooling in Fabric

Naming of classes will change in the near future

Reviewed By: JoshuaGross

Differential Revision: D14685009

fbshipit-source-id: 83573dd09af0202a67d0d0aa11e37c1660c3991f

Implement auto-conversions from primitives to Objects

Summary:
If a NativeModule method requires an optional boolean argument, our codegen translates those optional booleans into `NSNumber*` instead of `BOOL`. The reason why is probably because this is the closest object analogue to `BOOL` in Objective C. The same boxing occurs with numbers. If the type of a number argument in JavaScript is optional, we'll map it to the `NSNumber*` Objective C type instead of `double`. Our existing TurboModules argument conversion code would not take this behaviour into account. Therefore, we'd try to insert a `BOOL` where the `NSInvocation` would expect a `NSNumber*`. This, in turn, would cause the app to crash. (Why would it crash at the point of NSInvocation retainArguments, I'm still not sure).

Our flow typechecking ensures that if the type of a method argument is a boolean, we pass in a boolean. Therefore, on the Native side, if we detect a boolean, we can check the type of the Native argument to see whether we should box the primitive. If the native argument type is an object, then we know it has to be an `NSNumber*` in both cases, so we simply wrap the `BOOL` or `double` in a `NSNumber*`.

Reviewed By: shergin

Differential Revision: D14679590

fbshipit-source-id: c394a878492aab8e98c71d74ec8740a94fc3a6c5

Use constructor attribute instead of +load objc method (#24155)

Summary:
Xcode 10.2 forbids creating categories for swift class that uses `+load` method. In react-native categories like this are used to register swift classes as modules (macro `RCT_EXTERN_MODULE`) This PR changes it to use `__attribute__((constructor))` instead of objc `+load` method.

I introduced new macro for this purpose, `RCT_EXPORT_MODULE_NO_LOAD`, it expands in something like:
```
void RCTRegisterModule(Class);

+ (NSString *)moduleName {
  return @"jsNameFoo";
}

__attribute__((constructor)) static void initialize_ObjcClassFoo{
  RCTRegisterModule([ObjcClassFoo class]);
}
```

Functions marked with `__attribute__((constructor))` are run before main and after all `+load` methods, so it seems like correct thing to do.

Fixes https://github.com/facebook/react-native/issues/24139
Doc about loading order https://developer.apple.com/documentation/objectivec/nsobject/1418815-load?language=objc

[iOS] [Fixed] - Fix runtime crash in xcode 10.2 when using RCT_EXTERN_MODULE for swift classes.
Pull Request resolved: https://github.com/facebook/react-native/pull/24155

Reviewed By: javache

Differential Revision: D14668235

Pulled By: shergin

fbshipit-source-id: 0c19e69ce2a68327387809773848d4ecd36d7461

Move Android code for Geolocation out

Reviewed By: cpojer

Differential Revision: D14692916

fbshipit-source-id: 6bcfda8aa8c7d22dce36828dae9f57068815ce20

moved all the properties used for layout outputs to YogaNodeJNI

Summary:
Moved layout outputs transfer logic from YogaNodeJNIBase to YogaNodeJNI.
This change set is for adding experiment for layout outputs batching using a float array

Reviewed By: davidaurelio

Differential Revision: D14642995

fbshipit-source-id: 5d0bc7fa18c1985be7e216d7351f5eab2e03861d

added test for reset method in YogaNodeJNI to verify all layout outputs are reset properly

Summary: This diff adds a test for reset method in YogaNodeJNI to verify all layout outputs are reset properly

Reviewed By: davidaurelio

Differential Revision: D14643926

fbshipit-source-id: fffbcd07ccb6d2df83fc0bf187d992ef194f3bd0

Added implementation for YogaNodeJNIBatching and logic for passing array from c++ to java

Summary: This diff adds the logic to transfer layout outputs using a float array

Reviewed By: davidaurelio

Differential Revision: D14368120

fbshipit-source-id: d1f22283bcea051d15657f42c15b90edaa0a8a7a

added flag for useBatchingForLayoutOutputs experiment

Summary:
Using a config flag to switch between different implementations of transferring layout outputs
- YogaNodeJNI uses multiple access of java fields to pass all properties like width, height, margin etc...
- YogaNodeJNIBatching uses a float array to pass all the data in one java field access

Reviewed By: davidaurelio

Differential Revision: D14378301

fbshipit-source-id: 0da5b28e6a67ad8fd60eb7efe622d9b2deaf177f

Turn on react-hooks/exhaustive-deps in FBSource

Summary: Looks like there are already a bunch of issues in the codebase because this wasn't on.

Reviewed By: cpojer

Differential Revision: D14701084

fbshipit-source-id: 09ff8e0d905b81fbe08c41d4f58758479b38187b

fix typo in DatePickerAndroidTypes.js (#24234)

Summary:
fix typo in DatePickerAndroidTypes.js, fixes https://github.com/facebook/react-native/issues/24137

[Android] [Changed] - fix typo in DatePickerAndroidTypes.js
Pull Request resolved: https://github.com/facebook/react-native/pull/24234

Differential Revision: D14705691

Pulled By: cpojer

fbshipit-source-id: 0d4aee045f7ec36b0cfcd5b4ce5a2cd47cee9ec5

Remove navigator.geolocation, use Geolocation

Summary: This is the first diff in an effort to remove Geolocation from React Native. This diff removes the globally injected navigator.geolocation feature and instead requires explicit importing of `Geolocation`. When using Web APIs, people will need to patch `navigator.geolocation` on their own from now on.

Reviewed By: sahrens

Differential Revision: D14692386

fbshipit-source-id: c57b290b49728101250d726d67b1956ff23a9a92

Fabric `ShadowTree` (and co) was moved to `mounting` module

Summary: Because it's kinda more logical and we will rely on this in comming diffs.

Reviewed By: mdvacca

Differential Revision: D14587124

fbshipit-source-id: 94ae9410b4ffeffd0fcb4da4a0518f0bb0d2ba63

Fabric: Introspection (self testing in debug mode) in ShadowTree

Summary:
We suspect that we have some error in diffing algorithm that cause some crashes in mounting layer, so we decided to write a comprehensive unit tests for that.

Writing them we realized that it would be cool to also enable that for normal app run in the debug more, so we can catch the problem in real environment when/if it happens.

Reviewed By: mdvacca

Differential Revision: D14587123

fbshipit-source-id: 6dcdf451b39489dec751cd6787de33f3b8ffb3fd

Add the ability to customize webview response to client cert requests

Summary:
Add the ability to set a custom handler on ReactWebViewManager to handle client certificate challenges during TLS authentication.

[Android][Added] - Public method setCustomClientCertRequestHandler to the native com.facebook.react.views.webview.ReactWebViewManager, that allows using a custom response for client certificate challenges.

Reviewed By: mjhu

Differential Revision: D14609697

fbshipit-source-id: 567c95458af638d1f8233fc3ca0d9cefc061c2bf

Harmonize spacing after colons (#24186)

Summary:
Harmonizes the spacing after colons to have a more consistent coding style.
Pull Request resolved: https://github.com/facebook/react-native/pull/24186

Differential Revision: D14668167

Pulled By: cpojer

fbshipit-source-id: 8f1ba71eec186b3a2221d1f4fac851e51afc52cc

Fix setting the contentOffset value when refresh ends (#24191)

Summary:
It closes #24170.
I opened the issue yesterday, and I think I found the way how to resolve it. So, I'm opening this PR directly without any comment on the issue.

In the `endRefreshProgrammatically` of `RCTRefreshControl.m`, the comment says that " The contentOffset of the scrollview MUST be greater than 0". However, if the `contentInset` prop is set for the `FlatList`, I think `contentOffset` can be a negative value after refreshing and should be greater than `-contentInset.top`.

As I reported the bug in that issue, If I am using `contentInset` prop to the `FlatList`, making `contentOffset` value be always 0 when refreshing ends causes something wrong situation.

[iOS] [Fixed] - Fix setting the contnetOffset when refreshing ends
Pull Request resolved: https://github.com/facebook/react-native/pull/24191

Differential Revision: D14710987

Pulled By: sahrens

fbshipit-source-id: 03f06df9a93a2a46a7cc0b56269091778805917e

Revert D14423742: Use of TraceCompat

Summary:
D14423742 introduced a regression on OSS test_android due to androidx.core.os not being available. I spent some time investigating a fix forward this morning, with no success. Reverting.

Changelog:

[Android] [Changed] - Revert 92f019c666c4933b8553b60038803819f4204e5d

Reviewed By: cpojer

Differential Revision: D14668728

fbshipit-source-id: c7542992805551dc4302626e1536759794efaa82

Fix retain cycle in RCTDevMenu

Summary: A retain-cycle regression was added by D14162776 and detected here: T41208740. Fix should be trivial.

Reviewed By: shergin

Differential Revision: D14709784

fbshipit-source-id: bad6ab31a5170e9320c4432cbd20d02ec6164f38

Move Geolocation JS code to FB internal

Summary: This removes the JS parts of Geolocation from React Native open source.

Reviewed By: yungsters

Differential Revision: D14693179

fbshipit-source-id: 1da5b7ec0e3e9d21d2019b7ee43e5f85661795b4

Improvement: Adjust template to match new init command (#24138)

Summary:
Adjusting template to new init command (https://github.com/react-native-community/react-native-cli/pull/241).

PR with new init command needs to be merged before we land this.

[General] [Changed] - Adjust template to match new init command
Pull Request resolved: https://github.com/facebook/react-native/pull/24138

Differential Revision: D14617568

Pulled By: cpojer

fbshipit-source-id: f4b90920d47d3e0d2b08470e0eaad1abd733e4cc

Android: Enable views to be nested within <Text> (#23195)

Summary:
Potential breaking change: The signature of ReactShadowNode's onBeforeLayout method was changed
  - Before: public void onBeforeLayout()
  - After:  public void onBeforeLayout(NativeViewHierarchyOptimizer nativeViewHierarchyOptimizer)

Implements same feature as this iOS PR: https://github.com/facebook/react-native/pull/7304

Previously, only Text and Image could be nested within Text. Now, any view can be nested within Text. One restriction of this feature is that developers must give inline views a width and a height via the style prop.

Previously, inline Images were supported via FrescoBasedReactTextInlineImageSpan. To get support for nesting views within Text, we create one special kind of span per inline view. This span is called TextInlineViewPlaceholderSpan. It is the same size as the inline view. Its job is just to occupy space -- it doesn't render any visual. After the text is rendered, we query the Android Layout object associated with the TextView to find out where it has positioned each TextInlineViewPlaceholderSpan. We then position the views to be at those locations.

One tricky aspect of the implementation is that the Text component needs to be able to render native children (the inline views) but the Android TextView cannot have children. This is solved by having the native parent of the ReactTextView also host the inline views. Implementation-wise, this was accomplished by extending the NativeViewHierarchyOptimizer to handle this case. The optimizer now handles these cases:
  - Node is not in the native tree. An ancestor must host its children.
  - Node is in the native tree and it can host its own children.
  - (new) Node is in the native tree but it cannot host its own children. An ancestor must host both this node and its children.

I added the `onInlineViewLayout` event which is useful for writing tests for verifying that the inline views are positioned properly.

Limitation: Clipping
----------

If Text's height/width is small such that an inline view doesn't completely fit, the inline view may still be fully visible due to hoisting (the inline view isn't actually parented to the Text which has the limited size. It is parented to an ancestor which may have a different clipping rectangle.). Prior to this change, layout-only views had a similar limitation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23195

Differential Revision: D14014668

Pulled By: shergin

fbshipit-source-id: d46130f3d19cc83ac7ddf423adcc9e23988245d3

update url for apk-splits user-guide (#24253)

Summary:
Changed apk-splits user-guide url.

[ANDROID] [CHANGED] - Apk tools url.
Pull Request resolved: https://github.com/facebook/react-native/pull/24253

Differential Revision: D14724834

Pulled By: cpojer

fbshipit-source-id: 8e9e21ebdcb0d585f1f262640e259ccf71112adb

Bump react-native version in template in release script (#24262)

Summary:
Since template has a fixed version in `template/package.json`, we want to automate this process.

[General] [Added] - Bump react-native in `template/package.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/24262

Differential Revision: D14724831

Pulled By: cpojer

fbshipit-source-id: 164d13001a889941398f3db3b9b96eb9d5114cc3

add ram bundle to android template (#24264)

Summary:
I plan to do this for a long time :)
Still a little surprised so much people not know it https://twitter.com/geekykaran/status/1112756026611257344

[Android] [Feature] - add ram bundle to android template
Pull Request resolved: https://github.com/facebook/react-native/pull/24264

Differential Revision: D14725396

Pulled By: cpojer

fbshipit-source-id: b8e424f0be81978465259c82024f206d232acb55

Prevent crash when setting underlineColorAndroid (#24183)

Summary:
Try to prevent the crash described in https://github.com/facebook/react-native/issues/17530

There seems to be a bug in `Drawable.mutate()` in some devices/android os versions even after you check the constant state. This error is hard to reproduce and to fix, so just try to catch the exception to prevent crash.

[Android][Fixed] Prevent random crash when setting underlineColorAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/24183

Differential Revision: D14710484

Pulled By: cpojer

fbshipit-source-id: 3af20a5cb0ecd40839beaf85118c0f5aa6905414

Move WebView Android files to FB internal

Summary: This moves the Java files to FB internal and updates all the buck files

Reviewed By: TheSavior

Differential Revision: D14622521

fbshipit-source-id: a8d293e9f9e08868cca3ed2986a08d0db16dec15

bump gradle to 5.2.1 (#23879)

Summary:
Bump Gradle to 5.2.1, includes many bug fixes and improvements, especially improved Kotlin DSL support.

[Android] [Changed] - bump Gradle to 5.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/23879

Reviewed By: hramos

Differential Revision: D14486430

Pulled By: cpojer

fbshipit-source-id: 3476516352ff2c947d65103cff6f37e27d888c2d

@allow-large-files xplat flow 0.96 upgrade

Summary:
bypass-lint
allow_many_files

Reviewed By: panagosg7

Differential Revision: D14727932

fbshipit-source-id: 66b2fce7753450204c5daa131ffe43dcd4736539

Move iOS Geolocation code out from the repo

Summary:
@public
This resolves the iOS side of #20879.

Reviewed By: natestedman, cpojer

Differential Revision: D14712066

fbshipit-source-id: 88dd0ff80d3467b314cacb9349029dadca4ddf19

Make it possible to run JSBigString tests

Summary: Add a target for JSBigString tests that can be run with a normal `buck test` invocation. Also fix an issue in the test when `getenv` returns null by defaulting to `/tmp`.

Reviewed By: ridiculousfish

Differential Revision: D14716270

fbshipit-source-id: f2eb6d3aab93c32a4b41f5786aedd04a70468d75

TM iOS: Use weak_ptr to pass around Instance to avoid unreleased refs

Summary:
There is a timing issue when reloading the bridge (in dev mode) and the tear down of the TurboModules. This causes `Instance` to never get freed, hence the "bridge" isn't cleaning up properly. The side effect can be bogus error saying that it's unable to find a module.

To address this, JSCallInvoker should just take in weak_ptr<Instance>.

Reviewed By: RSNara

Differential Revision: D14739181

fbshipit-source-id: f9f2a55486debaeb28d3d293df3cf1d3f6b9a031

Guard against content view being null in onOverScrolled

Summary:
It seems that the content view can sometimes be null when onOverScrolled is called (presumably when the scrollview gets unmounted while it's in the middle of scrolling?).

Changelog: [Android][fixed] - Guard against content view being null in onOverScrolled.

Reviewed By: mdvacca

Differential Revision: D14737534

fbshipit-source-id: e88ec6f585e50517b734a8809fc3843c0b22df10

Log uri for guessContentTypeFromName exceptions

Summary: Add additional logging around the exception to figure out what kind of uris are causing the exception for `getContentTypeForFileName`

Reviewed By: PeteTheHeat

Differential Revision: D14715917

fbshipit-source-id: 46299d2ff3f1f06991d7800784a025a85815ae8c

Remove legacy AnimationManagerModule

Summary: This code was shipped as part of the initial open-source release but was never used.

Reviewed By: sahrens

Differential Revision: D14649389

fbshipit-source-id: 0c068ca69b91d275008f4a7af77a23a4f1470c18

Implement completion callback for LayoutAnimation on Android

Summary: All animations are scheduled by the UIManager while it processes a batch of changes, so we can just wait to see what the longest animation is and cancel+reschedule the callback.

Reviewed By: mdvacca

Differential Revision: D14656733

fbshipit-source-id: 4cbbb7e741219cd43f511f2ce750c53c30e2b2ca

Remove experimental gating for LayoutAnimation on Android

Reviewed By: sahrens

Differential Revision: D14658087

fbshipit-source-id: 378ef4a5c5336d428b5045772d094a297b2767c7

Removing unused and very old versions of the support library resources

Summary: TSIA

Differential Revision: D14727969

fbshipit-source-id: 1c73534dea7225f2d952ef0f20ea602894d78f04

Change default Inspector Proxy port to 8081

Summary: Change default Inspector Proxy port to 8081

Reviewed By: cwdick

Differential Revision: D14745974

fbshipit-source-id: f4b3b158f55c6f5f1b3d9cc2528c5ddb59774a8b

Move `YGSetUsedCachedEntries` to internal header

Summary:
@public

In order to get out of pre-releases again, we move `YGSetUsedCachedEntries` from `Yoga.h` to `Yoga-internal.h`.
This way, it’s obvious that the function is not public, and we can remove it from future versions without breaking semver contracts.

Reviewed By: SidharthGuglani

Differential Revision: D14726029

fbshipit-source-id: 8d7e747e843bf5c4b5e1d4cfbfa37ca9d240dffb

Make Jest transform @react-native-community packages by default (#24294)

Summary:
Currently, `react-native` Jest preset will not automatically transpile extracted Lean Core modules (all under `react-native-community` org), so maintainers will likely need to update their docs on how to do that (it's a common pain in RN testing story).

We can make it easier for users and maintainers by adding RNC modules to the `transformIgnorePatterns` whitelist we have in Jest preset. Some of them are not necessary to transpile, but I'd say it's a small sacrifice to make (having first test run possibly slower) for having less friction around migrating to extracted modules.

[General] [Added] - make Jest transform react-native-community/ packages by default
Pull Request resolved: https://github.com/facebook/react-native/pull/24294

Differential Revision: D14748962

Pulled By: cpojer

fbshipit-source-id: 36300ee021f03b8c13275a6e0cf28d988ee5beba

fix gradle wrapper in template (#24275)

Summary:
Fix Gradle wrapper in template

[Android] [Changed] - fix Gradle wrapper in template
Pull Request resolved: https://github.com/facebook/react-native/pull/24275

Differential Revision: D14750280

Pulled By: cpojer

fbshipit-source-id: 9aadb1a674503f3fbbdf6cc03a8f8e3d9d2692aa

bump fresco to 1.13 (#24274)

Summary:
Bump Fresco to 1.13, which uses libc++ and many improvements.

[Android] [Changed] - Bump Fresco to 1.13
Pull Request resolved: https://github.com/facebook/react-native/pull/24274

Differential Revision: D14750275

Pulled By: cpojer

fbshipit-source-id: 3c040fccd4cb484e31d9c6e849ec285666f140c7

Rename ios project name with new template (#24292)

Summary:
With new `init` implementation we replace all occurrences of the project name (`HelloWorld`) inside `ios` and `android` directories. For some reason, a product name field in `ios` was named wrongly. This shouldn't impact initialization using `global-cli`

[iOS] [Fixed] - Change productName in iOS in new init.
Pull Request resolved: https://github.com/facebook/react-native/pull/24292

Differential Revision: D14749249

Pulled By: cpojer

fbshipit-source-id: aaf4294ab23180770aac3075789d3ffb4d5a4f3f

Avoid failing Obj-C tests when xcpretty is not installed (#24173)

Summary:
Fixes an issue where `scripts/objc-test-ios.sh` would fail if `xcpretty` is not installed. As this tool is not bundled with macOS, and it's not explicitly called out in our docs on testing, the script should not fail if it's not present.

In a related change, JUnit reports are written to a more sensible location when the script is run outside of Circle CI.

[iOS] [Fixed] - Fixed test script failure when xcpretty is not present
Pull Request resolved: https://github.com/facebook/react-native/pull/24173

Differential Revision: D14726101

Pulled By: hramos

fbshipit-source-id: 9f3081a75a4a262f55aef8498241fe7d1e04b931

fixed touchable longpress (#24238)

Summary:
This diff fixes a bug in TouchableNativeFeedback where a long press is not registered.

cause of the bug is _touchableHandleResponderMove_ being invoked **regardless** of a moving gesture ( even when movedDistance is 0) in some devices ( including OnePlus5t ), which was eventually clearing out  the long-press timeout.

fix is to prevent _touchableHandleResponderMove_ from Implementing if the state of touchable is RESPONDER_INACTIVE_PRESS_IN.

[General] [Fixed] - Touchable onLongPress fix.
Pull Request resolved: https://github.com/facebook/react-native/pull/24238

Reviewed By: cpojer

Differential Revision: D14712986

Pulled By: rickhanlonii

fbshipit-source-id: e85a66a7e8b61e0a33146b2472e2e055726a0e93

Add YogaNode.cloneWithoutChildren

Summary: Adding flat clone method back to YogaNode for reconciliation.

Reviewed By: davidaurelio

Differential Revision: D14683019

fbshipit-source-id: 08ed2ffbb16052cb11aa464f67a7ba9a64297985

TM Android: fixed up JSCallInvoker creation

Summary: A previous commit changed the signature of the Instance (the arg to JSCallInvoker) to be a weak ref, so this callsite needs updating.

Reviewed By: mmmulani

Differential Revision: D14757188

fbshipit-source-id: 1a8663e56a42b26c6202881c57a7caafa71da2ab

Add scrollToOverflowEnabled prop to ScrollView (#24296)

Summary:
ScrollView's scrollTo behavior on iOS was recently changed to limit the offset to the content size plus any content inset (see #23427). This departure from the old behavior created UI issues for anyone that is using the over-scroll ability for the purpose of positioning elements at specific coordinates on the screen. Examples include using this behavior to position TextInputs above the virtual keyboard programmatically when focused or moving drop down elements positioned near the bottom of the content toward the top of the screen when selected to show a larger absolutely positioned item list. Default behavior does not change and this is an "opt-in" type of prop to re-enable the old behavior.

[iOS] [Added] - Added scrollToOverflowEnabled prop to ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/24296

Differential Revision: D14762619

Pulled By: cpojer

fbshipit-source-id: d2a552b5cb321d52e8ea4116327bf9ec647a3aae

Pre-allocate Fabric views even when React is running in the UI Thread

Summary: Before D14297477, the pre-allocation of views was ONLY necessary when react was running in the JS Thread, this is because the batch of mount items used to contain mount items for creation of views. After D14297477, views are only created during pre-allocation, that means that pre-allocation of views need to be trated the same way independently the thread where it is running.

Reviewed By: shergin

Differential Revision: D14714933

fbshipit-source-id: 7bd19cd33b624a5b0daaafabb476bb06707eea17

Implement AxialGradientView in Fabric Android

Summary: This diff integreates AxialGradientView in Fabric Android

Reviewed By: shergin

Differential Revision: D14631690

fbshipit-source-id: 54785466ab4cd7251c6667c8dc12d69d9d194832

Fix crash in RCTText in open source RNTester

Summary: See https://github.com/facebook/react-native/issues/24288

Reviewed By: sahrens

Differential Revision: D14765625

fbshipit-source-id: f7275f3735691e1f0c87e682f6dd675e5ba5a7c0

Android - Add a ReactFragment (#12199)

Summary:
React Native on Android has currently been focused and targeted at using an [Activity](https://developer.android.com/reference/android/app/Activity.html) for its main form of instantiation.

While this has probably worked for most companies and developers, you lose some of the modularity of a more cohesive application when working in a "brown-field" project that is currently native. This hurts more companies that are looking to adopt React Native and slowly implement it in a fully native application.

A lot of developers follow Android's guidelines of using Fragments in their projects, even if it is a debated subject in the Android community, and this addition will allow others to embrace React Native more freely. (I even assume it could help with managing navigation state in applications that contain a decent amount of Native code and would be appreciated in those projects. Such as sharing the Toolbar, TabBar, ViewPager, etc in Native Android)

Even with this addition, a developer will still need to host the fragment in an activity, but now that activity can contain native logic like a Drawer, Tabs, ViewPager, etc.

**Test plan (required)**
* We have been using this class at Hudl for over a couple of months and have found it valuable.
* If the community agrees on the addition, I can add documentation to the Android sections to include notes about the potential of this Fragment.
* If the community agrees on the addition, I can update one or more of the examples in the `/Examples` folder and make use of the Fragment, or even create a new example that uses a native layout manager like Drawer, Tabs, Viewpager, etc)

Make sure tests pass on both Travis and Circle CI.

_To Note:_
* There is also talk of using React Native inside Android Fragment's without any legit documentation, this could help remedy some of that with more documentation included in this PR https://facebook.github.io/react-native/releases/0.26/docs/embedded-app-android.html#sharing-a-reactinstance-across-multiple-activities-fragments-in-your-app
* Others have also requested something similar and have a half-baked solution as well http://stackoverflow.com/questions/35221447/react-native-inside-a-fragment

[ANDROID][FEATURE][ReactAndroid/src/main/java/com/facebook/react/ReactFragment.java] - Adds support for Android's Fragment system. This allows for a more hybrid application.
<!--
Help reviewers and the release process by writing your own release notes

**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**

  CATEGORY
[----------]        TYPE
[ CLI      ]   [-------------]      LOCATION
[ DOCS     ]   [ BREAKING    ]   [-------------]
[ GENERAL  ]   [ BUGFIX      ]   [-{Component}-]
[ INTERNAL ]   [ ENHANCEMENT ]   [ {File}      ]
[ IOS      ]   [ FEATURE     ]   [ {Directory} ]   |-----------|
[ ANDROID  ]   [ MINOR       ]   [ {Framework} ] - | {Message} |
[----------]   [-------------]   [-------------]   |-----------|

[CATEGORY] [TYPE] [LOCATION] - MESSAGE

 EXAMPLES:

 [IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
 [ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
 [CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
 [DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
 [GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
 [INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/12199

Differential Revision: D14590665

Pulled By: mdvacca

fbshipit-source-id: b50b708cde458f9634e0c14b3952fa32f9d82048

Back out "[react-native] Remove experimental gating for LayoutAnimation on Android"

Summary: We've identified a couple of remaining issues that need to be re-tested before we can ship this more broadly.

Reviewed By: fred2028

Differential Revision: D14775730

fbshipit-source-id: 22402149066c5fbe72c36fcf7f547d63feaf5241

Do not overwrite Object.freeze

Summary: Now that React Native ships with a newer version of JSC, we do not need this code to wrap `Object.freeze` any longer.

Reviewed By: mmmulani

Differential Revision: D14779239

fbshipit-source-id: 1a6e1a9c7f4312572bd08ba604fa8c9d6b1927e1

Adding Flow types for FabricUIManager measure calls

Summary: These are the same types as the existing measure calls on Paper's UIManager except ReactTag has been replaced with Node

Reviewed By: fkgozali

Differential Revision: D14732142

fbshipit-source-id: b757e0d1f8d168232d8ba58938cdcd3b30e006ff

Fabric: Improvements in DebugStringConvertible

Summary:
* Small improvements in pretty-printing algorirhm (adding spaces and new-line caracters). Now it's even more pretty.
 * The `depth` parameter was integrated into `DebugStringConvertibleOptions` which simplifies evething a bit and reduce amount of arguments that `getDebugDescription` requires.

Reviewed By: sahrens

Differential Revision: D14715082

fbshipit-source-id: 3ea0b8db3c1816c5cb43f40ccec9cdc1943f33a5

Fabric: `toString` methods were moved into `DebugStringConvertible` with an implementation in .cpp file

Summary:
They need to be in DebugStringConvertible because it depends on they (and because `debugStringConvertibleUtils` depends on `DebugStringConvertible`).
We also moved they implementation to cpp file to avoid leaking Folly's features to consumer namespace.

Reviewed By: mdvacca

Differential Revision: D14715080

fbshipit-source-id: 7277e17b39a14a2d7ba7e5a9b44a70178feb1045

Fabric: *Informal* `DebugStringConvertible` interface

Summary:
Informal `DebugStringConvertible` interface serves the same purpose as `DebugStringConvertible` abstract class (providing universal pretty-printing interface) but relies on C++ static overloading instead of virtual dispatch.

This approach has some advantages and disadvantages:
Pros:
 * It's more clear and scoped. It's simpler to implement debug-printing functionality aside of normal production code.
* It's more composable.
* It allows print types that are not classes.
* For some classes using `DebugStringConvertible` means that we have to use virtual inheritance (which might be undesirable and affect *production* performance (if a compiler isn't smart enough to remove empty base class).
* For some highly lean classes (that designed to be as small as possible) adding base (even empty-in-prod) classes kinda... smells.

Cons:
The particular implementations cannot rely on dynamic dispatch which can complicate printing classes with meaningful differences between sampling classes (e.g. ShadowNode subclasses). That's why we don't remove `DebugStringConvertible` class yet.

Reviewed By: mdvacca

Differential Revision: D14715081

fbshipit-source-id: 1d397dbf81dc6d1dff0cc3f64ad09f10afe0085d

Fabric: `getDebugDescription` implementation for `shared_ptr`, `weak_ptr` and `unique_ptr`

Summary: Trivial.

Reviewed By: mdvacca

Differential Revision: D14715083

fbshipit-source-id: 92031cbbf166ea00569a6076d41575a9fd741043

Fabric: `getDebugDescription` for `ShadowView` and `ShadowViewMutation`

Summary:
Trivial.
Now we can print actual list of mutations in case of some failure in the diffing algorithm.

Reviewed By: mdvacca

Differential Revision: D14715079

fbshipit-source-id: d0af7c756287643892d7120c199bc8028a6b3431

Fix crash if set text and set selection at the same time. (#22723)

Summary:
Since text and selection has dependency, handle text selection in
updateExtraData as well.

The root cause is due to setText is handled on extra data update but setSelection is handled on set property. And extra data update will be handled after all properties are handled. Since selection and text has dependency, move selection to extra data update as well.

Changelog:
----------
[Android] [Fixed] - Fix crash when set text and selection on textinput at the same time
Pull Request resolved: https://github.com/facebook/react-native/pull/22723

Differential Revision: D14783791

Pulled By: cpojer

fbshipit-source-id: a4065f3e151d23f4813d76e91d68362cfd4daaf4

Use node package dependency to manage JSC version (#24276)

Summary:
In origin approach, we packed libjsc.so inside react-native.aar and it is difficult for user to choose different JSC variants. E.g., [the Intl supported version](https://github.com/react-native-community/jsc-android-buildscripts#international-variant).

This change list allows application to determine JSC versions or variants by npm/yarn package.

There is a |useIntlJsc| flag in build.gradle, it will use the same JSC version but with Intl support.

`yarn add jsc-android@canary`

[Android] [Changed] - Allow application to select different JSC variants

**MIGRATION**
Note that there are some changes in build.gradle.
Existing application needs to change their android/build.gradle and android/app/build.gradle.
Hopefully, the rn-diff-purge should handle the case well.
Pull Request resolved: https://github.com/facebook/react-native/pull/24276

Differential Revision: D14752359

Pulled By: cpojer

fbshipit-source-id: a4bfb135ad8e328f404a2d1a062412f40ebf4622

- VirtualizedSectionList/SectionList: replace enableVirtualization prop annotation by correct underlying disableVirtualisation of VirtualizedList (#24312)

Summary:
It seems (I used git history to confirm) that FlatList/VirtualizedList have ([since the begining](https://github.com/facebook/react-native/blame/c13f5d48cfe3e7c0f6c6d0b745b50a089d6993ef/Libraries/Lists/VirtualizedList.js#L79)) a `disableVirtualization` prop.
SectionList ([since it's begining](https://github.com/facebook/react-native/blame/abe737fe746406533798f9670e8e243cb18d5634/Libraries/Lists/VirtualizedSectionList.js#L98)) have a `enableVirtualization` prop, but since SectionList is VirtualizedSectionList which use VirtualizedList, this prop probably never did something. This fix just rename the prop properly so it can have an effect on the underlying VirtualizedList when you use a SectionList.

Since props are spread it's kind of working already, but the flow annotation are wrong (so it tells you it won't work/ you can't use it) which sucks.

(NB: I am doing this since I was trying to use a SectionList with react-native-web & server side rendering to get the all list, you can laugh).

[General] [Fixed] - VirtualizedSectionList/SectionList: replace enableVirtualization prop annotation by correct underlying disableVirtualisation of VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/24312

Differential Revision: D14779449

Pulled By: cpojer

fbshipit-source-id: e51e1d639d2bb265b5b286786010d01ffd9d90e0

Remove Polyfills from RN Open Source

Summary:
We don't need these polyfills in RN Open Source any longer because JSC supports these features natively.

We also don't need these internally at FB, but I want the removal to be a step by step process and separate from the open source work.

Reviewed By: rickhanlonii

Differential Revision: D14762827

fbshipit-source-id: 114626bd18516c42ced43c3f7aa29d42d1d95335

Move iOS WebView files to FB internal

Summary: This moves the iOS WebView files to be fb internal which completes the removal of WebView from React Native open source as part of the Lean Core effort.

Reviewed By: TheSavior

Differential Revision: D14630076

fbshipit-source-id: 7bc11d6c1470bb748c823c86cbb8b5ee94b508ff

Fix #23755 ("RCTImagePickerManager requires main queue setup" warning) (#24314)

Summary:
Fix #23755 - Which is to remove the warning:
```
Module RCTImagePickerManager requires main queue setup since it overrides `init` but doesn't implement `requiresMainQueueSetup`. In a future release React Native will default to initializing all native modules on a background thread unless explicitly opted-out of.
```

General Fixed - Warning "RCTImagePickerManager requires main queue setup
Pull Request resolved: https://github.com/facebook/react-native/pull/24314

Differential Revision: D14788772

Pulled By: cpojer

fbshipit-source-id: e2017136008367d36468debb258afa698b5402bc

Fix duplicate definition Flow error in HMRLoadingView

Summary: Fix duplicate definition Flow error in HMRLoadingView, and match latest changes made to Facebook's internal .flowconfig

Reviewed By: cpojer

Differential Revision: D13110965

fbshipit-source-id: 8c22cab8232e1f539e77014b21e258de8b08d2b3

Back out "[react-native][PR] Android - Add a ReactFragment"

Summary: Original commit changeset: b50b708cde45

Reviewed By: mdvacca

Differential Revision: D14792438

fbshipit-source-id: c5e0b5f7663fe70110f73ae94a6fa99388f87ae3

Support experimental re-mmap wrappers

Summary: Add experimental support for reordering the pages of a file that is mmap:ed by JSBigFileString. The wrapper is auto-detected (by checking file size and magic header) and transparently reorders the pages.

Reviewed By: ridiculousfish

Differential Revision: D14721397

fbshipit-source-id: 34e095350a9eeb9b07105bed6f3379f2fe472ae6

add flow check to windows ci (#21401)

Summary:
add flow check to windows ci
Pull Request resolved: https://github.com/facebook/react-native/pull/21401

Differential Revision: D14807935

Pulled By: hramos

fbshipit-source-id: 38354aa498fe7783966e8bf1895286c690eed90a

Set scroll view throttle by default

Summary:
Setting the scroll throttle for every animated scrollview is a pain, and if you forget it's super janky and can be confusing and frustrating.

Enables setting default props in createAnimatedComponent and uses it for scrollview.

Reviewed By: TheSavior

Differential Revision: D14790093

fbshipit-source-id: dd8f6f6540813245e87d696351f09ebb2e6ed5f2

Cleanup native anim example

Summary: Makes things a little more clear.

Reviewed By: TheSavior, yungsters

Differential Revision: D14790256

fbshipit-source-id: 42e47487adfd48b8de5e987ac0e73a128a200824

Upgrade Jest to 24.7.1

Summary: Update Jest to 24.7.1, which has performance improvements I've built over the last few weeks.

Reviewed By: rubennorte

Differential Revision: D14766905

fbshipit-source-id: 9ebb3b6f2a9ed656ca0a41a27099fe1ea6e92710

Android plumbing for State and LocalData update mount items

Summary: Android plumbing for State and LocalData update mount items. See other commits in stack for usage

Reviewed By: mdvacca

Differential Revision: D14663522

fbshipit-source-id: 5604a6a9af292805e9ce46c68e5ce7472eef0218

Fabric: Fixing const correctness in ShadowNodeFragment (and some prettification)

Summary:
Previously, all placeholders methods have return type `SomeType &` which is not correct because it allows the called to modify enclosed `static` value of the placeholders; the type should be `SomeType const &`.
Besides that this diff migrates some type aliases to the new style (which makes evething much prettier and readable).

Reviewed By: mdvacca

Differential Revision: D14819076

fbshipit-source-id: 87e68d546f16d7a9ad1fb65e1b238859f9381eb7

fix typo (#24343)

Summary:
"Built from source" is past tense - if anything, it should be "Build from source". However, all other heading end with "ing" so it makes sense here too.
Pull Request resolved: https://github.com/facebook/react-native/pull/24343

Differential Revision: D14822098

Pulled By: cpojer

fbshipit-source-id: 3d07f2e6f8ed4a21e0311ef4f675f2d41553b619

change jest native method mocks to jest functions (#24337)

Summary:
Currently calling native methods on internal react native components throw a warning. I believe this is problematic because _users_ aren't calling native methods on internal components, the _component_ is making the call.

So for instance, if I unmount a component that has a form with a few uses of `TextInput`, which is a perfectly valid test case, my test output will be full of warnings that I can't call `.blur()` in the test renderer environment. That's very misleading, because I didn't, the internal component did. In fact, as far as I can tell, there's not really even anything I can do to stop that call or use the output from it, its all internal. `TextInput` is a black box, and 99% of users writing tests probably won't even know it calls `.blur()` under the hood on unmount.

I want to change these to `jest.fn()` because I think this eliminates a lot of chatter in test output, but also doesn't send users down a rabbit hole of trying to find workarounds that may involve filtering console output, which could potentially lead them to inadvertently filter out real warnings that they should see.

So I'm willing to change the implementation of how I did this, but I don't think its right to warn users that they called a native method when they didn't. If they build a component that calls these methods, I believe it's on them to do something similar to this, and maybe we can make this exposed as a helper that can be used for third party component mocks?

[General] [Changes] - Changed MockNativeMethods for core components to `jest.fn()` instead of function that warns about calling native methods.
Pull Request resolved: https://github.com/facebook/react-native/pull/24337

Differential Revision: D14822126

Pulled By: cpojer

fbshipit-source-id: 2199b8c8da8e289d38823bdcd2c43c82f3f635c9

useAndroidX and enableJetifier config in template gradle.properties (#24319)

Summary:
enable useAndroidX and enableJetifier that transforms non-Androidx third-party libraries to use AndroidX.

[Android] [Changed] - useAndroidX and enableJetifier config in template gradle.properties
Pull Request resolved: https://github.com/facebook/react-native/pull/24319

Differential Revision: D14822125

Pulled By: cpojer

fbshipit-source-id: 596a92f26fb06b077da507583b72af2b5abf712a

Fix bugs around `align-content`

Summary:
@public

Regenerating the “golden master” tests with chrome surfaced different bugs around `align-content`:

- a misunderstanding that values in `align-content` only applied *if there is only one line.* In fact, it applies *every time* a container is set to `flex-wrap: wrap`. Chrome had this wrong, and as such our tests were generated with incorrect parameters.
- empty children growing to the cross axis size of the container, even when `align-content` is different from `stretch`. This was implemented incorrectly in Chrome as well. Here, we fix it with an extra check.

Reviewed By: SidharthGuglani

Differential Revision: D14725402

fbshipit-source-id: a45bebdadb9c694dc0eb7e27cb52b3d247f81c50

Support callbacks in synchronous native functions

Summary:
We need to move animated native module calls to synchronous so we can properly thread them in with mounting instructions in Fabric. Some of them take callbacks so we need to add support for that when switching to synchronous.

A side benefit is that we can unify codepaths a little more with async callbacks.

Reviewed By: shergin

Differential Revision: D14790898

fbshipit-source-id: dc222b9e74375e046e8a9b1b19d72f652dc6722c

Add some native module method test cases

Summary: Just a little more rigorous

Reviewed By: shergin

Differential Revision: D14790912

fbshipit-source-id: 0a4c9b6ea68466efb060c9c90572ff8987fdbd26

More iOS animation fixes

Summary:
Main change is to the property diffing - we now use the last known props set on the view rather than the default props to compute the diff. This requires exposing a `getProps` method on all view components which should be fine I think.

I also realized that in more complex animations with multiple nodes, the node that the animation starts on might not be connected to a view, so we don't know if it's fabric just based on that, so we have to do a recursive search through the children to find if there are any that are associated with a fabric view to decide we should start the animation immediately. Unfortunately there can still be a timing gap here since the animated API is async and the uimanager API is sync - I'll need to change the animated API to be sync to completely fix this.

Reviewed By: shergin

Differential Revision: D14732028

fbshipit-source-id: 882c056b0b63aa576f8e42439be405cf7fb3147a

ignore dropView method when view is null (#24347)

Summary:
In #20288, we solved `com.facebook.react.uimanager.NativeViewHierarchyManager.dropView (NativeViewHierarchyManager.java:536)` by adding codes that prevent to run method on `view` object when `view.getId()` is null.

But if `view` is null, `view.getId()` can make error about NullPointerException. So, I think `dropView` method  needs to check if `view` is null.

If you need more information, Please read #24346.

[Android] [Fixed] - Ignore dropView method when view is null.
Pull Request resolved: https://github.com/facebook/react-native/pull/24347

Differential Revision: D14833822

Pulled By: cpojer

fbshipit-source-id: 88b6a05090ea8e8d6737c1f10b40e93649fab151

Remove wrapper around ListEmptyComponent (#24339)

Summary:
This pull request fixes #24257.

The wrapper around ListEmptyComponent doesn't allow to use flex on the ListEmptyComponent.
The wrapper was removed in this [commit](https://github.com/facebook/react-native/commit/db061ea8c7b78d7e9df4a450c9e7a24d9b2382b4), and then put back in this [commit](https://github.com/facebook/react-native/commit/e94d3444dcface90bd20234d13143462690ff23c) but I think the relevant part was removing the condition on `itemCount !== 0` to apply the inversionStyle on the ScrollView and everything is still working without the wrapper.

[GENERAL] [FIXED] - Remove wrapper around ListEmptyComponent
Pull Request resolved: https://github.com/facebook/react-native/pull/24339

Differential Revision: D14822221

Pulled By: cpojer

fbshipit-source-id: 623e1ab3f228e9b75b92cdcd568683232a403c1a

Make FlatList's renderItem return React.Node

Summary:
Flow typing can be annoying because the `renderItem` prop for FlatList always has to specifically be of type `React.Element`.

Since really we just want to return something renderable, it should be fine to type this as `React.Node` instead.

I'm not sure if this is valid, but it seems like since we just need to implant the `key` property, we should be able to accomplish this with a `React.Fragment` wrapper instead of needing to call `cloneElement`. Looking for feedback on if this is a sensible fix.

Changelog:
[General][Changed] Updated FlatList's renderItem Flow type from React.Element<any> to React.Node

Reviewed By: sahrens

Differential Revision: D14814805

fbshipit-source-id: ce6793dea5a92619babe048dcfddee0e4519979c

Set up .flowconfig to support Haste and path-based imports (#24318)

Summary:
See https://github.com/facebook/react-native/issues/24316 for the motivation.

By adding the .android.js and .ios.js extensions to the respective .flowconfig files, Flow is able to find files that either:

- Are required using Haste
- Are required using standard paths and have a .js extension
- Are required using standard paths and have a .platform.js subextension

[General] [Changed] - Adjusted .flowconfig to support both Haste and standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24318

Differential Revision: D14822356

Pulled By: cpojer

fbshipit-source-id: dde0c83692d6170f4a44cd3fb8ede162054157e9

Export JNativeRunnable from react/jni

Summary: Adding JNativeRunnable to exported headers in react/jni/BUCK so I can use it outside of CatalystInstance.

Reviewed By: axe-fb

Differential Revision: D14817655

fbshipit-source-id: 15aa794e50f273778da337956c887c235a5aec3d

Fix Docker Android tests container issue related to the JSC (#24360)

Summary:
[Fixes an issue where the Docker Android tests container cannot be built.](https://github.com/facebook/react-native/pull/24276#issuecomment-480915232) The JSC is now pulled from the npm registry, so we need to run `yarn` prior to pulling the Gradle dependencies.

[Android] [Fixed] - Fixed React Native Android tests Docker container issue related to the JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/24360

Differential Revision: D14842534

Pulled By: hramos

fbshipit-source-id: 3a1a714879e9c52a812b1077dce449470c30bddd

Fix tests with JavaOnlyMap

Summary: Need to force the double thing in more places.

Reviewed By: cpojer

Differential Revision: D14835792

fbshipit-source-id: fb7a5435675b322d5fbbe9858e08804e9abe65db

ide added a commit to expo/react-native that referenced this issue Apr 10, 2019

[standards] Rewrite imports in RNTester to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

Test Plan: Run RNTester and verify that it loads without any issues. Tap through each screen to ensure the JS modules load (that is, were bundled) correctly.

cpojer added a commit to expo/react-native that referenced this issue Apr 10, 2019

[standards] Rewrite imports in RNTester to use standard paths
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

Test Plan: Run RNTester and verify that it loads without any issues. Tap through each screen to ensure the JS modules load (that is, were bundled) correctly.

facebook-github-bot added a commit that referenced this issue Apr 10, 2019

Rewrite imports in RNTester to use standard paths (#24317)
Summary:
See #24316 for the motivation. This commit rewrites the imports in the RNTester project.

[General] [Changed] - Replaced Haste-style imports with standard path-style imports for RNTester
Pull Request resolved: #24317

Differential Revision: D14870504

Pulled By: cpojer

fbshipit-source-id: b14f22e7ce559efc332ced032617ca581196d90f

dsyang added a commit to dsyang/react-native that referenced this issue Apr 12, 2019

Set up .flowconfig to support Haste and path-based imports (facebook#…
…24318)

Summary:
See facebook#24316 for the motivation.

By adding the .android.js and .ios.js extensions to the respective .flowconfig files, Flow is able to find files that either:

- Are required using Haste
- Are required using standard paths and have a .js extension
- Are required using standard paths and have a .platform.js subextension

[General] [Changed] - Adjusted .flowconfig to support both Haste and standard path-based requires
Pull Request resolved: facebook#24318

Differential Revision: D14822356

Pulled By: cpojer

fbshipit-source-id: dde0c83692d6170f4a44cd3fb8ede162054157e9

dsyang added a commit to dsyang/react-native that referenced this issue Apr 12, 2019

Rewrite imports in RNTester to use standard paths (facebook#24317)
Summary:
See facebook#24316 for the motivation. This commit rewrites the imports in the RNTester project.

[General] [Changed] - Replaced Haste-style imports with standard path-style imports for RNTester
Pull Request resolved: facebook#24317

Differential Revision: D14870504

Pulled By: cpojer

fbshipit-source-id: b14f22e7ce559efc332ced032617ca581196d90f

ide added a commit to expo/react-native that referenced this issue May 8, 2019

[standards] Migrate TurboModule example in RNTester to use path-based…
… requires

See facebook#24316 for the motivation. This commit rewrites a couple more new imports in the RNTester project so they use path-based requires.

Test plan: run RNTester and ensure the TurboModule example loads.

facebook-github-bot added a commit that referenced this issue May 8, 2019

Migrate TurboModule example in RNTester to use path-based requires (#…
…24754)

Summary:
See #24316 for the motivation. This commit rewrites a couple more new imports in the RNTester project so they use path-based requires.

[General] [Changed] - Migrate TurboModule example in RNTester to use path-based requires
Pull Request resolved: #24754

Differential Revision: D15258015

Pulled By: cpojer

fbshipit-source-id: adb298cb3006ea0afcd3b813a2e2fe85017764d2

facebook-github-bot added a commit that referenced this issue May 8, 2019

Migrate IntegrationTests from Haste to path-based requires (#24750)
Summary:
This is another step in moving RN towards standard path-based requires. All the requires in `IntegrationTests` have been rewritten to use relative requires. This commit uses requires that are relative to `react-native/...` assuming that IntegrationTests are meant to try consuming RN rather than being part of it.

See the umbrella issue at #24316 for more detail.

[General] [Changed] - Migrate IntegrationTests from Haste to path-based requires
Pull Request resolved: #24750

Differential Revision: D15258019

Pulled By: cpojer

fbshipit-source-id: 01ac01ba4699f8ba424353f74e745b4057f79b59

facebook-github-bot added a commit that referenced this issue May 8, 2019

Migrate "Libraries" from Haste to standard path-based requires (sans …
…vendor & renderers) (#24749)

Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.

See the umbrella issue at #24316 for more detail.

[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: #24749

Differential Revision: D15258017

Pulled By: cpojer

fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323

ide added a commit to expo/react-native that referenced this issue May 9, 2019

[standards] ReactPrivate, an explicit interface between the renderer …
…and RN

This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

Test Plan: Run unit tests, CI. This commit should be safe since it just introduces new modules.

Also tested with newly generated renderers (not in this commit; needs to happen in the React repo) that use ReactPrivate instead of Haste and verified that RNTester loads and that unit tests pass.

ide added a commit to expo/react-native that referenced this issue May 9, 2019

[standards] ReactPrivate, an explicit interface between the renderer …
…and RN

This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

Test Plan: Run unit tests, CI. This commit should be safe since it just introduces new modules.

Also tested with newly generated renderers (not in this commit; needs to happen in the React repo) that use ReactPrivate instead of Haste and verified that RNTester loads and that unit tests pass.

ide added a commit to expo/react-native that referenced this issue May 9, 2019

[standards] ReactPrivate, an explicit interface between the renderer …
…and RN

This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

Test Plan: Run unit tests, CI. This commit should be safe since it just introduces new modules.

Also tested with newly generated renderers (not in this commit; needs to happen in the React repo) that use ReactPrivate instead of Haste and verified that RNTester loads and that unit tests pass.

ide added a commit to expo/react-native that referenced this issue May 9, 2019

[standards] ReactPrivate, an explicit interface between the renderer …
…and RN

This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

Test Plan: Run unit tests, CI. This commit should be safe since it just introduces new modules.

Also tested with newly generated renderers (not in this commit; needs to happen in the React repo) that use ReactPrivate instead of Haste and verified that RNTester loads and that unit tests pass.

ide added a commit to expo/react-native that referenced this issue May 10, 2019

[standards] ReactPrivate, an explicit interface between the renderer …
…and RN

This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

Test Plan: Run unit tests, CI. This commit should be safe since it just introduces new modules.

Also tested with newly generated renderers (not in this commit; needs to happen in the React repo) that use ReactPrivate instead of Haste and verified that RNTester loads and that unit tests pass.

ide added a commit to expo/react-native that referenced this issue May 14, 2019

[standards] ReactPrivate, an explicit interface between the renderer …
…and RN

This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

Test Plan: Run unit tests, CI. This commit should be safe since it just introduces new modules.

Also tested with newly generated renderers (not in this commit; needs to happen in the React repo) that use ReactPrivate instead of Haste and verified that RNTester loads and that unit tests pass.

facebook-github-bot added a commit that referenced this issue May 20, 2019

ReactPrivate, an explicit interface between the renderer and RN (#24782)
Summary:
This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

## Changelog

[General] [Changed] - Add a private interface (do not use) between the renderer and RN
Pull Request resolved: #24782

Differential Revision: D15413477

Pulled By: cpojer

fbshipit-source-id: 3766ad4cf129fad0c82f0ddc7a485a4ba313b2c4

ide added a commit to expo/react-native that referenced this issue May 22, 2019

[standards] Replace more Haste imports with path-based imports
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at facebook#24316 for more detail.

ide added a commit to expo/react-native that referenced this issue May 22, 2019

[standards] Replace more Haste imports with path-based imports
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at facebook#24316 for more detail.

facebook-github-bot added a commit that referenced this issue May 23, 2019

Replace more Haste imports with path-based imports (#25001)
Summary:
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at #24316 for more detail.

## Changelog

[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: #25001

Differential Revision: D15467829

Pulled By: cpojer

fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f

@ide ide changed the title [standards] Umbrella issue to track migration to standard path-based requires [standards] Umbrella issue to track migration to standard path-based requires (remove Haste) Jun 5, 2019

@ide

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 6, 2019

Closing this out as part of 0.61. Thank you @cpojer for pushing this through internally.

@ide ide closed this Jun 6, 2019

@cpojer

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

Yay we did it!

Cauldrath added a commit to Cauldrath/react-native that referenced this issue Jul 30, 2019

Migrate "Libraries" from Haste to standard path-based requires (sans …
…vendor & renderers) (facebook#24749)

Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.

See the umbrella issue at facebook#24316 for more detail.

[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: facebook#24749

Differential Revision: D15258017

Pulled By: cpojer

fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323

# Conflicts:
#	Libraries/AppState/AppState.js
#	Libraries/Blob/__tests__/URL-test.js
#	Libraries/Components/CheckBox/CheckBox.android.js
#	Libraries/Components/DatePicker/__tests__/DatePickerIOS-test.js
#	Libraries/Components/DrawerAndroid/DrawerLayoutAndroid.android.js
#	Libraries/Components/DrawerAndroid/__tests__/DrawerAndroid-test.js
#	Libraries/Components/MaskedView/__tests__/MaskedViewIOS-test.js
#	Libraries/Components/Picker/__tests__/Picker-test.js
#	Libraries/Components/ProgressBarAndroid/__tests__/ProgressBarAndroid-test.js
#	Libraries/Components/ProgressViewIOS/__tests__/ProgressViewIOS-test.js
#	Libraries/Components/SafeAreaView/SafeAreaView.js
#	Libraries/Components/SafeAreaView/__tests__/SafeAreaView-test.js
#	Libraries/Components/ScrollView/ScrollView.js
#	Libraries/Components/Slider/RCTSliderNativeComponent.js
#	Libraries/Components/TextInput/__tests__/InputAccessoryView-test.js
#	Libraries/Components/Touchable/TouchableWithoutFeedback.js
#	Libraries/Components/UnimplementedViews/UnimplementedNativeView.js
#	Libraries/Components/View/View.js
#	Libraries/Components/View/ViewPropTypes.js
#	Libraries/Core/Devtools/setupDevtools.js
#	Libraries/Core/InitializeCore.js
#	Libraries/Core/SegmentFetcher/NativeSegmentFetcher.js
#	Libraries/Core/setUpBatchedBridge.js
#	Libraries/Core/setUpSegmentFetcher.js
#	Libraries/Core/setUpXHR.js
#	Libraries/Image/__tests__/Image-test.js
#	Libraries/Inspector/PerformanceOverlay.js
#	Libraries/Interaction/JSEventLoopWatchdog.js
#	Libraries/Linking/Linking.js
#	Libraries/Lists/SectionList.js
#	Libraries/Lists/__tests__/VirtualizedSectionList-test.js
#	Libraries/Modal/__tests__/Modal-test.js
#	Libraries/Network/RCTNetworking.android.js
#	Libraries/Network/RCTNetworking.ios.js
#	Libraries/ReactNative/AppRegistry.js
#	Libraries/ReactNative/FabricUIManager.js
#	Libraries/ReactNative/renderApplication.js
#	Libraries/Text/TextProps.js
#	Libraries/TurboModule/samples/NativeSampleTurboModule.js
#	Libraries/Utilities/GlobalPerformanceLogger.js
#	Libraries/Utilities/PerformanceLoggerContext.js
#	Libraries/Utilities/__tests__/DeviceInfo-test.js
#	Libraries/Utilities/__tests__/Dimensions-test.js
#	Libraries/Utilities/__tests__/PerformanceLogger-test.js
#	Libraries/Utilities/__tests__/PixelRatio-test.js
#	Libraries/Utilities/__tests__/binaryToBase64-test.js
#	Libraries/Utilities/__tests__/clamp-test.js
#	Libraries/Utilities/__tests__/infoLog-test.js
#	Libraries/Utilities/__tests__/logError-test.js
#	Libraries/Utilities/__tests__/mergeIntoFast-test.js
#	Libraries/Utilities/__tests__/stringifySafe-test.js
#	Libraries/Utilities/__tests__/warnOnce-test.js
#	Libraries/Utilities/createPerformanceLogger.js
#	Libraries/YellowBox/YellowBox.js
#	Libraries/promiseRejectionIsError.js
#	packages/react-native-codegen/src/Helpers.js

vovkasm added a commit to vovkasm/react-native that referenced this issue Aug 7, 2019

ReactPrivate, an explicit interface between the renderer and RN (face…
…book#24782)

Summary:
This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.

Motivation: The main goal is to move one step closer to turning off Haste for RN (facebook#24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.

Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.

There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.

## Changelog

[General] [Changed] - Add a private interface (do not use) between the renderer and RN
Pull Request resolved: facebook#24782

Differential Revision: D15413477

Pulled By: cpojer

fbshipit-source-id: 3766ad4cf129fad0c82f0ddc7a485a4ba313b2c4
(cherry picked from commit 9cd8825)

vovkasm added a commit to vovkasm/react-native that referenced this issue Aug 7, 2019

Replace more Haste imports with path-based imports (facebook#25001)
Summary:
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at facebook#24316 for more detail.

[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: facebook#25001

Differential Revision: D15467829

Pulled By: cpojer

fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f
(cherry picked from commit a7a7970)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.