Summary: This check isn't needed in prod as the bundle is served with the app. In dev mode it's possible to have native and JS out of sync.
Reviewed By: yungsters
Differential Revision: D15268485
fbshipit-source-id: 9aeeb6cf5ca91baa90b85e18c848c3b10d85b0f7
Summary:
The `measure` API receives LocalData and Props, it should also receive State.
This will also be used in future diffs.
Reviewed By: mdvacca
Differential Revision: D15325182
fbshipit-source-id: 6cb46dd603ce7d46673def16f0ddb517e2cf0c4f
Summary: In D15252375 I made JSCallInvoker an abstract class and extended it in BridgeJSCallInvoker, but I forgot to add the `override` keyword for overridden methods.
Reviewed By: fkgozali
Differential Revision: D15328292
fbshipit-source-id: 3e75faf1b4a968b80643b8a97071ab2e122fd643
Summary: If some stack frames in a trace fail to symbolicate (or are genuinely unmapped), their `frame` field will be null, and `ExceptionsManager.js` will currently crash. This diff lets it recover gracefully and show whatever information is available.
Reviewed By: dcaspi
Differential Revision: D15296220
fbshipit-source-id: 2b1006b1354295171b25bfc6230c5b3e0c57f67f
Summary:
Fixes redbox/yellowbox symbolication when the Java delta client is enabled. Previously the modules would get concatenated in a nondeterministic order (owing to Metro's parallelism) which differed from their order in the source map, where they're explicitly sorted by module ID.
This diff changes the data structure holding modules in memory from a `LinkedHashMap` (which iterates in insertion order) to a `TreeMap` (which iterates in key order).
NOTE: Similar to this change in the Chrome debugger's delta client: https://github.com/react-native-community/cli/pull/279
Reviewed By: dcaspi
Differential Revision: D15301927
fbshipit-source-id: 27bdecfb3d6963aa358e4d542c8b7663fd9eb437
Summary:
In ContextContainer, only in Debug mode, we store type information alongside with data to detect typemismatch in runtime. We used type hashes before, but seems they are not so stable and can cause some false negative crashes.
This diff changes that to store mangled typenames instead of hashes, so it should be much more reliable now.
Reviewed By: JoshuaGross
Differential Revision: D15325728
fbshipit-source-id: 3a0f1116e1336af79adb51f38ce83c37aee4cad1
Summary:
This PR is related to #24760 and adds the `openURLInBrowser` functionality introduced on react-native-community/cli#383.
[General] [Changed] - Open links from new app in computer's browser.
Pull Request resolved: https://github.com/facebook/react-native/pull/24843
Reviewed By: rickhanlonii
Differential Revision: D15334011
Pulled By: cpojer
fbshipit-source-id: 947ad1b113923989cf706e60851e02a87e1099e8
Summary:
first, I edited this post so that the comment below are NOT relevant any more
problem: `scrollToLocation` behavior in SectionList on master is inconsistent between platforms.
Recently, there have been two PRs changing this function: https://github.com/facebook/react-native/pull/21577 and https://github.com/facebook/react-native/pull/24034
let me just quote the [docs](https://facebook.github.io/react-native/docs/sectionlist#scrolltolocation) here
> Scrolls to the item at the specified sectionIndex and itemIndex (within the section)
originally, the code was `let index = params.itemIndex + 1;`
so if we call
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
inside scrollToLocation, index is incremented and that results into the list scrolling to the first item (the first section heading is not visible - see the gif). If I specify `itemIndex = -1`, it will scroll all the way up. I was expecting `itemIndex = 0` to bring me all the way up, so that the first section heading is visible. Not sure which way this should work but at least this behavior is in line with the docs.
next, there was https://github.com/facebook/react-native/pull/21577 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex: params.itemIndex - 1;`
so that https://github.com/facebook/react-native/issues/18098 is fixed. The PR had a bug and so next, there was https://github.com/facebook/react-native/pull/24034 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex : params.itemIndex + 1;`
the reasoning was
> Note however, how the sign for non iOS changed from + to - causing a crash on Android when trying to scroll to index 0 as that will be evaluated to -1 instead of 1 and thus be out of bounds.
with this change, the list does not crash. However, the behavior is not consistent between platforms (see gifs):
So, this PR works under the assumption that
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
should scroll all the way up, so that even the first section heading is visible. This should keep this bug https://github.com/facebook/react-native/issues/18098 fixed. However, this change means different behavior from how it used to be and from how it is documented, which should be pointed out in release notes and docs need to be updated.
Finally, if we agree this is the way to go, it'd be nice to have some automated tests.
cc melina7890 danilobuerger
[Android][Fixed] - fix scrollToLocation not consistent between platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/24734
Differential Revision: D15334565
Pulled By: cpojer
fbshipit-source-id: f7122ef4a5c252fc3e0d2112861d1460742e9fa4
Summary:
This replaces the "new app screen" in the template with the new design from https://github.com/react-native-community/discussions-and-proposals/issues/122
This uses components that are shipped as part of the `react-native` module, but not necessarily as proper components exported by the main `react-native` module. To use these, we use absolute imports to those components.
Related to #24760
[General] [Changed] - Updated new app template design 💖
Pull Request resolved: https://github.com/facebook/react-native/pull/24805
Differential Revision: D15334459
Pulled By: cpojer
fbshipit-source-id: d0b67d08f936eeabd9e93d4e0ff78302b4d6429f
Summary:
When running Android app for the first time, the packager is requesting delta bundles from metro instead of a bundle (in dev settings delta bundles are disabled by default and marked as experimental). UI of dev settings is not consistent with the current state, to turn off delta bundles you have to enable them and then disable.
[Android] [Fixed] - Disable delta bundles on the first app run
Pull Request resolved: https://github.com/facebook/react-native/pull/24848
Differential Revision: D15334059
Pulled By: cpojer
fbshipit-source-id: 384a8abba64c54db3656a4d5d0e24acc825870c8
Summary:
The files in `ReactAndroid/src/androidTest/js` use Haste names; this commit migrates them to use path-based imports. This helps us move RN towards standard path-based requires. All the requires in `androidTest` have been rewritten to use relative requires.
[General] [Changed] - Migrate "androidTest" JS from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24813
Differential Revision: D15318108
Pulled By: cpojer
fbshipit-source-id: dddc68f992b8dea48afb01fd4481bd5b846231ca
Summary:
We provided `ReactNetworkForceWifiOnly` in https://github.com/facebook/react-native/pull/24242, but it's a string type, actually the value only YES or NO, so let's change it to Boolean type, we can benefit from:
1. Users don't need to type string `YES`, just select bool YES or NO directly by click the button:
<img width="789" alt="image" src="https://user-images.githubusercontent.com/5061845/57634311-a8af7400-75d7-11e9-9f8a-ebf865d672e3.png">
2. Don't need to do string compare.
3. More looks what it should looks, Boolean is the Boolean. :)
cc. cpojer ericlewis .
[iOS] [Changed] - Change ReactNetworkForceWifiOnly from String to Boolean
Pull Request resolved: https://github.com/facebook/react-native/pull/24829
Differential Revision: D15323685
Pulled By: cpojer
fbshipit-source-id: c626d048d0cbea46d45f232906fd3ac32a412741
Summary:
Original commit changeset: f149721d6b4d (D15238379)
This commit was causing the following crash: Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7fb3453eda00 of class RCTUITextField was deallocated while key value observers were still registered with it.
FB: See also P64445585 T44107377 T44169319
Reviewed By: mmmulani
Differential Revision: D15323255
fbshipit-source-id: 037c34ae387d912c5ea03eaa364b8c60367df357
Summary:
The bug description can see https://github.com/facebook/react-native/issues/24688, we add `contentView` size check before center the content, because in some cases, the contentView's size not yet be calculated, in those cases, we don't adjust the `contentOffset`.
cc. cpojer .
[iOS] [Fixed] - Fixes ScrollView centerContent not work in some cases
Pull Request resolved: https://github.com/facebook/react-native/pull/24817
Differential Revision: D15322502
Pulled By: sahrens
fbshipit-source-id: e2081f13e9f2e8597a379a9db1607451ea496909
Summary: The existing implementation of JSCallInvoker holds a reference to Instance (aka the bridge). This diff makes JSCallInvoker an abstract base class that's extended by BridgeJSCallInvoker, which is what's returned by CatalystInstance to initialize TurboModules. This will allow us to add another class that derives from JSCallInvoker that doesn't rely on the bridge.
Reviewed By: shergin
Differential Revision: D15252375
fbshipit-source-id: 75eee2ca149235a63e2a2cd8cdd361b163d1d1ab
Summary:
@public
RocksDB was originally available when RN open sourced but is no longer used, so removing it from AsyncStorage.js.
Changelog: [General] Removed RocksDB from AsyncStorage.js
Reviewed By: fkgozali
Differential Revision: D15218709
fbshipit-source-id: 82993f86bbb3f32e61d1e9895aafd67701351860
Summary:
We are getting errors where views are being dropped twice.
This is following from logic that viewManagers are only removed from `mTagsToViewManagers` from `dropView`.
This log will hopefully identify if we are getting improper operations because we shouldn't be re-using tags
Reviewed By: mdvacca
Differential Revision: D15152869
fbshipit-source-id: 914ee9c1772fa066adefde0753075ecba6377a0c
Summary:
Now that inline views are supported on iOS and Android, we can add some examples to RNTester. I brought back examples from https://github.com/facebook/react-native/commit/03663491c6e68409f73d5c9bbc1a2e3c02ee0966.
I also added some new inline view examples in TextInlineView.js. Note that some examples are only supported on iOS because they rely on the inline view being able to size to content. Android's implementation requires that a width and height be specified on the inline view.
Here are the known bugs illustrated by these examples:
- ClippedByText
- Expected: The image/view wraps to the next line (because it is too wide) and gets clipped vertically (because it is too tall).
- iOS bug: The image/view does not get wrapped to the next line
- Android bug: The view gets wrapped to the next line but doesn't get clipped vertically. The image appears to be positioned too low.
- ChangeImageSize/ChangeViewSize:
- Expected: The "Change Image/View Width" button causes the image/view to toggle between a width of 50 and 100.
- iOS bug: First update works. Subsequent updates don't get rendered.
- Android bug: No updates get rendered.
- ChangeInnerViewSize:
- Expected: The "Change Pink View Width" button causes the pink inner view to toggle between a width of 50 and 100.
- iOS bug: First update works but second update **CRASHES** the app.
- Android bug: No updates get rendered.
[Internal] [Added] - Added inline view examples to RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24814
Differential Revision: D15318070
Pulled By: cpojer
fbshipit-source-id: 35a4aaab88e477d627456eeb4208c509c42927df
Summary:
Add link to ECOSYSTEM.md and clean up markdown formatting.
[Internal] [Added] - Edit to CONTRIBUTING.md, add link to ECOSYSTEM.md
Pull Request resolved: https://github.com/facebook/react-native/pull/24808
Differential Revision: D15316889
Pulled By: cpojer
fbshipit-source-id: 1805b957d7480ca5e3a8a36bf86b75d23193cd55
Summary:
Bugs like https://github.com/facebook/react-native/issues/24789, we don't apply tintColor to GIF. We fixes it by setting a poster image before add animation.
cc. cpojer .
[iOS] [Fixed] - Fixes renderingMode not applied to GIF images
Pull Request resolved: https://github.com/facebook/react-native/pull/24794
Differential Revision: D15316913
Pulled By: cpojer
fbshipit-source-id: 611a07ec17afc962d1eb6b8fc193f118fa623e73
Summary:
This adds in a link to the reactnative Twitter handle so our users can follow along with the latest and greatest of React Native!
Related to #24760
[General] [Added] - Added link to reactnative Twitter handle to Learn More section
Pull Request resolved: https://github.com/facebook/react-native/pull/24806
Differential Revision: D15316771
Pulled By: cpojer
fbshipit-source-id: cd45f005cfbcbd277fadb48be8943d60f4386767
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries/vendor` have been rewritten to use relative requires. Talking to cpojer, the vendored code in RN can be modified directly.
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.
Closes#24769.
[General] [Changed] - Migrate vendored code from Haste to path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/24807
Differential Revision: D15316831
Pulled By: cpojer
fbshipit-source-id: 19475823ce9f506600bd09b001156e306bff4db8
Summary:
Some users (me included) have projects located in quirky places, resulting whitespaces in the path.
An example, , I symlink into my iCloud drive which result in the following path
```
/Users/r/Library/Mobile Documents/com~apple~CloudDocs/_/work/{a_company}/repos.nosync/app
```
This commit quotes the variable to make sure it gets properly passed to the CLI.
For reference, similar issue that has been resolved: https://github.com/react-native/react-native/commit/7d4e94edccfc2f642fcbd1d6aa00756f02e3a525
Pull Request resolved: https://github.com/facebook/react-native/pull/24810
Differential Revision: D15316898
Pulled By: cpojer
fbshipit-source-id: 4ed2c8391d65d1680e836bfce8c51dfb5763caed
Summary:
On iOS in React Native, immediately after successfully connecting to a WiFi network, if 4G is also on, it is possible that network requests sent via fetch get sent over 4G instead of WiFi for several seconds (between 1 and 40+ seconds depending on the device and network in my experience). If the calls are meant to be communicating with a local Wireless Device (such as a wireless router, etc.), then API calls that get sent over 4G to the internet are lost. Note that Reachability/NetInfo are saying that we are connected to a WiFi network and are not sufficient to prevent this from happening. To prevent this, I would like to be able to set an instance property that iOS exposes for network requests allowsCellularAccess to NO to ensure a request is never sent over 4G.
This code needs to be able to accept a flag to allow the user to override the default value of YES, but only when they explicitly opt in to this decision. I am not sure the best place to set and pass in this value, so I created [this issue](https://github.com/react-native-community/discussions-and-proposals/issues/113), where it was recommended that I make a PR and discuss how best to do this here. Before this PR could be merged we would need to allow the NO to be configurable in some way.
Additional information about the [allowsCellularAccess](https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/1409406-allowscellularaccess?language=objc) property can be found in the [Apple documentation.](https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/Platform-SpecificNetworkingTechnologies/Platform-SpecificNetworkingTechnologies.html#//apple_ref/doc/uid/TP40010220-CH212-SW9)
[iOS] [Added] - Ability to force network requests to use WiFi using the allowsCellularAccess property. This can ensure that network requests are sent over WiFi if communicating with a local hardware device and is accomplished by setting a flag. Default behavior of allowing network connections over cellular networks when available is unchanged.
Pull Request resolved: https://github.com/facebook/react-native/pull/24242
Differential Revision: D15316760
Pulled By: cpojer
fbshipit-source-id: 96df43b4eff6b4301c853df6b2e5c6e1bb1abda0
Summary:
Adds `LayoutPassStart` and `LayoutPassEnd` events.
The existing `NodeLayout` event in isolation is not as useful as it could be. Having events that mark start and end of a layout pass are a useful addition.
Differential Revision: D15305467
fbshipit-source-id: 14af6f65e698fb1e3112eb2ffd87a74d31df4840
Summary:
This diff ensures the method scheduler.constraintSurfaceLayout is executed before the JS run application start.
This is necessary to properly set the pointScaleFactor for the Root before running JS.
This is a workaround to fix a bug when the pointScaleFactor changes over time for the rootShadowNode. The bug is easily reproducible when rendering the "fabric" indicator on Fabric screens. During the first render of a Fabric screen this method was called before "JS run application" starts, and the Fabric indicator was render correctly.
Beacuse of timing of measure APIS, the second time a Fabric screen is rendered the method is called after the "JS run application process started", as a consecuence the Fabric indicator is not rendered correctlly (the pointScaleFactor is incorrectly assigned into the layout metrics of the Fabric indicator text).
We still need to analyze why the pointScaleFactor is not correctly assigned when it is set after the "JS run application process started", but this will be part of another diff.
Reviewed By: shergin
Differential Revision: D15303554
fbshipit-source-id: 7d985cefee20fd40dbe04166c1a1358b3f3ddc85
Summary:
Previously the pointScaleFactor field was not being compared properly in LayoutMetrics equality method.
This diff fixes that
Reviewed By: shergin
Differential Revision: D15303555
fbshipit-source-id: 8863e9e1fbad15b43400afc32b97bf6d252cbe55
Summary: `YogaStylableProps.yogaStyle` is designed to be consumed by Yoga only. Making it `protected` allows us to avoid confusion and misuse of this props.
Reviewed By: JoshuaGross
Differential Revision: D15296474
fbshipit-source-id: cf9e416afee99fb426d72765557b34d303a63dbe
Summary: We needed that in the very beginning when diffing algorithm produces mount instructions for <Text> nodes which don't have ComponentView representation, so we simply silence those error here. That's not the case anymore, so we don't need those ugly checks.
Reviewed By: JoshuaGross
Differential Revision: D15296473
fbshipit-source-id: ea3717062056907e5395776fe95e3d581d3e9b09
Summary: RCTComponentViewRegistry is not a thread-safe class and must be accessed only from the main thread.
Reviewed By: JoshuaGross
Differential Revision: D15296475
fbshipit-source-id: 67192abd6290191f3b8119972efc41cec48a793a
Summary: self should be assigned to result of [super init]
Reviewed By: shergin
Differential Revision: D15295275
fbshipit-source-id: 722ae9ad3f9fb8ee3a86892bfb5b2a4cb7b8c708
Summary:
ReactNativeRenderer has `require('scheduler')` in it but we don't seem to declare a dependency. As a result, the latest sync broke `useEffect` in open source master:
```js
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(c => c + 1);
}, 1000)
return () => clearInterval(id);
}, [])
return <View><Text>{count}</Text></View>
}
```
<img width="535" alt="Screen Shot 2019-05-10 at 3 26 05 PM" src="https://user-images.githubusercontent.com/810438/57535832-e04dc000-733a-11e9-8e3e-d685171ec55a.png">
This adds an explicit dependency on the same version we're currently using internally.
<img width="535" alt="Screen Shot 2019-05-10 at 3 47 42 PM" src="https://user-images.githubusercontent.com/810438/57535886-f65b8080-733a-11e9-82c3-78e6c3a3888b.png">
Pull Request resolved: https://github.com/facebook/react-native/pull/24802
Differential Revision: D15295252
Pulled By: hramos
fbshipit-source-id: cd897ac590de1b719f28234f7631b0dcc069d043
Summary:
Fixes#13351
Two root causes:
1. Android Spinner will reset selection to undefined after setAdapter()
which will trigger onValueChange().
The behavior is not expected for RN.
And the solution is to setSelection() explicitly
2. In original implementation, it setups `items` immediately,
but delays the `selected` setup after update transaction.
There will be some race condition and incosistency
if update `items` only.
The fix will do the setup all after update transaction.
[Android] [Fixed] - Fix#13351 PickerAndroid will reset selected value during items update.
Pull Request resolved: https://github.com/facebook/react-native/pull/24793
Differential Revision: D15293516
Pulled By: cpojer
fbshipit-source-id: 5a99a60015c7e1b2968252cdc0b2661d52a15b9d
Summary:
Fixes this issue:
https://github.com/facebook/react-native/issues/24468
It was incorrectly closed by a fix on react-native-community CameraRoll implementation. CameraRoll in react-native still crashes when finding a file with # sign
[Android] [Fix] - Fix Android Camera Roll crash on mime type guessing
Pull Request resolved: https://github.com/facebook/react-native/pull/24780
Reviewed By: mdvacca
Differential Revision: D15281062
Pulled By: lunaleaps
fbshipit-source-id: ca3364c8478d9bfc9a0a6657b531ffb384145d8c
Summary:
This is the first step in revamping the Contribution Guide at `/CONTRIBUTING.md`. This work will require changes to the React Native website repository, as well as the React Native GitHub wiki. For review purposes, changes to copy that exists outside of this repository will be included within a `.github/wiki` directory in this PR, but they are not intended to be part of the final PR that gets merged.
[General] [Changed] - Contribution Guide Revamp
Pull Request resolved: https://github.com/facebook/react-native/pull/24705
Differential Revision: D15290268
Pulled By: hramos
fbshipit-source-id: b09c86738e75143fbdf2fea97ccd860da79362d2
Summary: In the future we're planning to decouple ThemedReactContext from the bridge (CatalystInstance). For now, we just need to be able to create a ThemedReactContext with a ReactContext that has no Catalyst instance.
Reviewed By: mdvacca
Differential Revision: D15246442
fbshipit-source-id: 99ebda6521f4df72969011ea0e6ea41b046875c8
Summary: This diff replaces usage of abort() with assert() when a prop-value is not found during parsing of prop values
Reviewed By: shergin
Differential Revision: D14563338
fbshipit-source-id: c799420e6b49df35e1d7ccdbd4bc4845067d33cc
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D15246287
fbshipit-source-id: 4b8c53e68112af7eded47d8c31311500cc296dfe
Summary: Now it's implementled differently (see -[RCTComponentViewRegistry preallocateViewComponents]), so this code is not being used.
Reviewed By: mdvacca
Differential Revision: D15242045
fbshipit-source-id: c02eceb978cf1eae778f84a73456e7156ccf503b
Summary:
ImageLoader is an actual external dependency, not a ImageManager.
That change allows to remove dependency on ImageManager from SurfacePresenter and make some other code simpler.
Reviewed By: mdvacca
Differential Revision: D15242047
fbshipit-source-id: 8622d15b8fdb5c3a7e25091adf7be1108f87ecd5
Summary: The particular meaningful piece of code that diff removes was added as (successful) attempt to fix an issue which was lately fixed by D14868547.
Reviewed By: mdvacca
Differential Revision: D15242046
fbshipit-source-id: 88a3e3c629d7c5f84c402b03e45034644147fec4
Summary:
Related to #24760 and #24737
This simplifies some styling within the components used for the New App Screen to help advocate for best practices when styling with CSS-like styles in React Native, as well as using React Native's own unique components.
There's a bit more detail in each commit. Let me know if you'd like me to pull that info out into the PR description here!
[General] [Changed] - Polished up new app screen component styling
Pull Request resolved: https://github.com/facebook/react-native/pull/24783
Differential Revision: D15284851
Pulled By: cpojer
fbshipit-source-id: 954db00d39fc0082bbd4dc96afa7d38dfb7f67d5
Summary:
UITextView is accessible by default (some nested views are) and disabling that is not supported.
The problem happened because JS side sets `isAccessible` flag for UITextView and UITextField to `true` (with good intent!), which actually disables (surprise!) bult-in accessibility of TextInput on iOS.
On iOS accessible elements cannot be nested, so enabling accessibily for some container view (even in a case where this is view is a public API of TextInput on iOS) shadows some features implemented inside the component.
(Disabling accessibility of TextInput via `accessible=false` was never supported.)
Reviewed By: JoshuaGross
Differential Revision: D15280667
fbshipit-source-id: 72509b40383db6ef66c4263bd920f5ee56a42fc1
Summary: Right now TurboModuleManager gets the JSCallInvokerHolder from the bridge in its constructor; this diff changes the constructor to make the JSCallInvokerHolder a required argument so that TurboModuleManager doesn't directly depend on the bridge.
Reviewed By: axe-fb, RSNara
Differential Revision: D15227184
fbshipit-source-id: b16e6abaa727587986a132d0e124163acdf55408
Summary:
This diff changes the condition in `ViewShadowNode::isLayoutOnly()` removing checking for `onLayout` event listener.
We needed that before because the mechanism of emitting events was based on analyzing mutation instructures (we needed those to be generated for nodes with `onLayout`).
Recenly we changed that algorithm deeply integrating in layout infra, so we don't need this anymore.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15273491
fbshipit-source-id: 2d43f00d1b87369d5993fe5ba70c2de36b8ce0c5