Summary: This was previously set to disallow trailing commas on function arguments which prettier would add. Since we are dropping support for node < 8, we can now change this setting to require trailing commas everywhere and be consistent with the prettier config at Facebook.
Reviewed By: hramos
Differential Revision: D7961098
fbshipit-source-id: fbe49513183a8c8e027bb05467a767235dbfb15b
Summary:
This fixes some build flavor:
```
error: destructor called on non-final 'facebook::react::Scheduler' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
```
Reviewed By: shergin
Differential Revision: D7958022
fbshipit-source-id: 6ff64bdaa221b5c6430a98244d40d6d3789ba937
Summary:
Quick update to switch to a new React Native CI org on Docker Hub. Note that the images are not yet automatically generated on CI. We could do this on Circle CI in certain scenarios:
- Base image needs to be updated whenever the Android development environment has changed (e.g. switch to a new SDK version, build tools, etc)
- Tests image should ideally be updated on each commit
This PR should be safe to land as Circle CI is not yet using these images.
Closes https://github.com/facebook/react-native/pull/19192
Differential Revision: D7939209
Pulled By: hramos
fbshipit-source-id: 0f845a8fffbf8f5b9cecef4fa0ba802bc755f7aa
Summary:
Fixes Xcode console output for web socket connections. Apple uses OSLog for logging within libnetworking starting 11.3+. The old way we hook into logging to prevent it will not work anymore.
Let's hook into `__nwlog_pack` that is exclusively used by libnetworking and prevent the logging in there.
Closes https://github.com/facebook/react-native/pull/18948
Reviewed By: fkgozali
Differential Revision: D7940969
Pulled By: mmmulani
fbshipit-source-id: a61beea34377044bfad7e3c446b2ec1138d6d1f5
Summary: ReactCommon subdir is supposed to be focused on C++, so Xcode projects shouldn't creep in.
Reviewed By: PeteTheHeat
Differential Revision: D7939858
fbshipit-source-id: 2e90491bdaec92829485aded071f74d004b24b21
Summary:
`FlatList` (actually `VirtualizedList`) allows recursive nesting of itself for easy and complex composition of lists such that it can support seemless virtualization and VPV events. It does this by only rendering a `ScrollView` for the outermost `VirtualizedList` and simply stacking `View`s for all the internal ones.
However, if a `Modal` is in a `FlatList` and also hosts a `FlatList`, e.g.:
```
<FlatList ListFooterComponent={<Modal><Foo /></Modal>} />
```
Then React context will propogate through to the inner `FlatList` and cause it to render as a plain `View`. Because the `Modal` actually portals the views into a different native hierarchy, one without a `ScrollView`, the `FlatList` won't scroll as expected.
The fix is to wipe out the context - not sure if there is a better way, but this doesn't seem terrible.
Differential Revision: D7863625
fbshipit-source-id: 38f41d72ed32b9f0eb1c9c82893f21d83a83f9ad
Summary:
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Fixes a crash with the Android Dialog. This occurs when the Activity is finishing or has been removed and React Native requests the modal to be shown.
Stacktrace here:
```
Caused by android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@f125ea3 is not valid; is your activity running?
at android.view.ViewRootImpl.setView(ViewRootImpl.java:683)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:319)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:85)
at android.app.Dialog.show(Dialog.java:326)
at com.facebook.react.views.modal.ReactModalHostView.showOrUpdate(ReactModalHostView.java:256)
at com.facebook.react.views.modal.ReactModalHostManager.onAfterUpdateTransaction(ReactModalHostManager.java:107)
at com.facebook.react.views.modal.ReactModalHostManager.onAfterUpdateTransaction(ReactModalHostManager.java:28)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:35)
at com.facebook.react.uimanager.NativeViewHierarchyManager.createView(NativeViewHierarchyManager.java:233)
at com.facebook.react.uimanager.UIViewOperationQueue$CreateViewOperation.execute(UIViewOperationQueue.java:153)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:816)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:929)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2100(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$2.runGuarded(UIViewOperationQueue.java:887)
at com.facebook.react.bridge.GuardedRunnable.run(GuardedRunnable.java:21)
at android.os.Handler.handleCallback(Handler.java:815)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loop(Looper.java:207)
at android.app.ActivityThread.main(ActivityThread.java:5728)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:789)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:679)
```
Related issues: #18570 & #18634
mdvacca added to this file in e5c2a66897
Doesn't look like the issue was introduced in the above change, but it masks the issue. The wrapping if block should not allow a null activity to display a dialog.
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
Run sample app on Android and display dialog when app is about to close.
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[ANDROID] [BUGFIX] [Modal] - Fix Android BadTokenException crash
<!--
**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 ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {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
-->
Closes https://github.com/facebook/react-native/pull/18996
Differential Revision: D7938147
Pulled By: hramos
fbshipit-source-id: f4ffd1746304d6184d727339072a7e926ffdaf39
Summary:
VirtualizedList sets high priority rendering when scrolled to the top of a list even if the bottom of the rendered list is still far away and there's nothing further to render above. This causes severe non-responsiveness while dozens of items are waiting to be rendered and user inputs can't get through.
The fix is simply to not consider it high priority to render more items when we reach the top and the first item has already been rendered, or when we reach the bottom and the last item has been rendered.
The code change just splits the two cases (hitting the top and bottom) instead of combining them into one.
I wrote a small application that switches between two FlatLists.
Demo of the original VirtualizedList
<img src="https://user-images.githubusercontent.com/3090032/39456709-2c87069e-4d1b-11e8-8535-5bda6d59400c.gif" width="270" height="480">
I'm clicking pretty often on the button, but you can see that it only switches lists a split second after the rendering is all done because the javascript thread was being blocked.
Demo of the fixed VirtualizedList
<img src="https://user-images.githubusercontent.com/3090032/39456844-00312448-4d1c-11e8-805f-cbe17aa3f95e.gif" width="270" height="480">
You can see this one is significantly more responsive than the previous one.
The source code for the demo application is available [here](https://gist.github.com/jabbawookiees/ba93a4e7b4f9b8f3acbc157e4fd04877)
[ GENERAL ] [ ENHANCEMENT ] [ Libraries/Lists/VirtualizedList.js ] - Prevent high priority rendering at the top or bottom of a list.
Closes https://github.com/facebook/react-native/pull/19081
Differential Revision: D7933994
Pulled By: sahrens
fbshipit-source-id: 13c9f73baeb3487620b720854a753287ac0aa1fa
Summary:
This diff deprecates `-[RCTSurface rootViewTag]` in favour of `-[RCTSurface rootTag]` which returns
same value but represented as `ReactTag` (`long`) instead of `NSNumber *`.
Reviewed By: mdvacca
Differential Revision: D7857044
fbshipit-source-id: f5427c30d3de2d3563e830f2caac70b7dc9631f9
Summary: ShadowTree is an abstraction around (commited) root shadow node and managing its lifecycle.
Reviewed By: mdvacca
Differential Revision: D7857049
fbshipit-source-id: 8d530e0366fc703e4aef4ec88dd8ea990dafaaf1
Summary: `RootShadowNode` is a dedicated class for managing the root node.
Reviewed By: mdvacca
Differential Revision: D7857050
fbshipit-source-id: f15f4b177f03cea4c0fd5a60d761ee2745319d77
Summary:
Apparently, we don't need this functionality in Fabric because we compute mutation instactions during diffing anyways.
But we still need (will need) `LayoutContext` for sure.
Reviewed By: mdvacca
Differential Revision: D7857045
fbshipit-source-id: 4be2744d9abea473ead847f35f698104f94af33d
Summary: Quite trivial but still very cool recycling of native view instances is finnally here, in React Native. �
Reviewed By: mdvacca
Differential Revision: D7804085
fbshipit-source-id: 644804da3185f9ed3fdea42d4d76c93e86934448
Summary:
No macros in product code.
(Not all callsites are converted yet.)
Reviewed By: mdvacca
Differential Revision: D7797561
fbshipit-source-id: da899421bf99669a0e0a2b83df6004daf14355c2
Summary:
I was shamed by Sebastian's sebmarkbage concerns (totally unrelated to this topic) about introducing another level of indirection into the system and decided to change my original plan not to support text attributes for the <Paragraph> component.
So, now <Paragraph> shares <View>, <Text> and <Paragraph> itself capabilities. That reduces the minimum amount of required components for trivial text fragment from three (Paragraph, Text, RawText) to two (Paragraph and RawText).
Special thanks for C++ for supporting multiple inheritance.
Reviewed By: mdvacca
Differential Revision: D7785889
fbshipit-source-id: dd9f2e2650bfbfd76d7d4b538adaf409f9429df3
Summary: We do not have a clear strategy how to deal with layout-only (view-less) components. Even if this particular solution is not so fancy, it prevents crashing during text rendering.
Reviewed By: mdvacca
Differential Revision: D7785885
fbshipit-source-id: f3ed8988aa2b41349fd1693c2a7f8c9368daee43
Eli White
Andrew Chen (Eng)
Irene Feng
Dmitry Zakharov
Kevin Gozali
Riley Dulin
Andrey Mishanin
Héctor Ramos
Marc Horowitz
Michael Schneider
Tim Yung
Spencer Ahrens
Andrew Jack
Payton Yao
Valentin Shergin
