Summary: Renames `ReactFiberErrorDialog-test` to `ExceptionsManager-test` and adds tests for `console.error` and exceptions not captured by React. Some of this functionality is covered by the RNTester integration tests, but this JS test suite is both more comprehensive and easier to iterate against.
Reviewed By: cpojer
Differential Revision: D16363166
fbshipit-source-id: 32a4b89bb50131fae86e3c03db7eacbbcf86966b
Summary: Right now we register ReactFabric as a callable module with the bridge so that we can call `ReactFabric.unmountComponentAtNode` in `ReactInstanceManager.detachViewFromInstance`. In bridgeless mode we don't have callable modules, so I'm just setting a global variable that can be called from C++ instead. Using this in a new `unmount` method in FabricUIManager.
Reviewed By: shergin, mdvacca
Differential Revision: D16273720
fbshipit-source-id: 95edb16da6566113a58babda3ebdf0fc4e39f8b0
Summary: When turning on Fast Refresh, we might have a compile error in previously saved files. We used to ignore it until a file is saved again, leading to a confusing experience. This changes it so that we remember the last compile error, and show it _either_ when we get it (if Fast Refresh is off), or when we _turn it on_.
Reviewed By: cpojer
Differential Revision: D16359160
fbshipit-source-id: 8dc237563c2a271a23019a32ff85b57de99cfabe
Summary: Right now we are using a local boolean and `bundle-registered` to hide the "Refresh" banner on the first update from the server (right after loading the bundle). This change adds `isInitialUpdate` to the `update-start` message which I'm now using to disable the banner. This also simplifies the HMRClient a little bit.
Reviewed By: cpojer
Differential Revision: D16357287
fbshipit-source-id: 29e72774989c4ba895a85be06a366e1b2fe7c02f
Summary:
If you change a file while Fast Refresh is off, this now stashes an update instead of ignoring it. When/if you turn it on, we will apply those stash updates. This solves the confusion that can happen when you enable it midway after making a bunch of changes, and therefore makes the experience more reliable.
**This current implementation is unfortunate because the app memory load increases with the number of file saves. This isn't really sustainable. So in the next diff I will change it to only remember the *latest versions* of every edited file instead.**
Reviewed By: cpojer
Differential Revision: D16344332
fbshipit-source-id: 69609a00eb9022f6b2797269fa091fa1b4125dd1
Summary:
We want to move to a world where Fast Refresh is on by default. As a first step, we can register the bundle early. This means we'll start receiving hot updates via the socket even if Fast Refresh is off. We'll just be ignoring those.
Anecdotally people with Fast Refresh on have had good experience even with invasive changes like branch switches. So this seems like a good way to test the waters further. It's also a prerequisite to unlocking a nicer experience where you can turn it on anytime and "catch up" on the changes you've missed. (That's out of scope of this diff.)
Reviewed By: cpojer
Differential Revision: D16344019
fbshipit-source-id: 6e5f8278909810b32c80e0af010251c876e4313b
Summary:
Two changes:
1. `disable` -> `close` to better match what's happening.
2. `enable` is inlined in the constructor because it's always called right after the constructor.
Reviewed By: rickhanlonii
Differential Revision: D16340009
fbshipit-source-id: 38a906b1ab3f5b39a57d2598ba400a2f03903951
Summary:
https://github.com/facebook/react-native/pull/25671 added a shallow unit test for `ReactFiberErrorDialog`, mocking out the (JS) `ExceptionsManager` module. This rewrites that test in terms of `NativeExceptionsManager` instead, so the integration with `ExceptionsManager` is also tested.
Also adds tests for the behaviour of the `framesToPop` and `jsEngine` extended error fields, and for passing a frozen error object (seeing as we potentially mutate the error).
Reviewed By: rickhanlonii
Differential Revision: D16330341
fbshipit-source-id: 0b514d1c8f193a114748739ec31ddb4e06e4d2fd
Summary:
I discovered failing snapshot tests (T47222928, T47222859). They fail because `<Image>` doesn't work with base64 anymore.
There are two problems that are causing this.
1st is on iOS https://fburl.com/pw246vgw where if the image has 1 frame count, nothing is displayed.
2nd is in https://fburl.com/3im0u38r where if image is not within assets, we don't display it.
Reviewed By: shergin
Differential Revision: D16334151
fbshipit-source-id: 1ea8ef676b7207834ba63f4264e6ef2f05f24b96
Summary: This diff removes the unused `markerNote` method from QPL.
Differential Revision: D16331769
fbshipit-source-id: c35006af03d6129dc690cfd05bc1bc1c4a0856ba
Summary:
This adds a loading indicator when loading split bundles so that users get a visual indicator about what is going on.
Note that I am currently trying to get the dynamic message that shows the number of modules and percentage to work but it appears that the JavaScript networking client (XMLHttpRequest + RCTNetwork) are not set up to deal with multipart responses in the same way as our native multipart handlers are. I'd like to put this in place now and polish it later if it's possible to fix the issue (I spent all afternoon yesterday trying to make multipart messages work and failed :( ).
Reviewed By: gaearon
Differential Revision: D16281531
fbshipit-source-id: 84e53d7f25642398ed51d8f552919880b8090897
Summary:
This view will be re-used for bundle splitting so I'm changing the name to be more generic as it can be used for informing users of any loading activity.
I also cleaned up the files a bit from a class to just an object.
Reviewed By: gaearon
Differential Revision: D16281367
fbshipit-source-id: 5c2ee7790d29ccba473bd6e90737d2f0581e6291
Summary:
This diff builds on the previous ones and changes the setup process from using the WebSocket URL to using a message that is sent after the connection is established. It also exposes a function on the HMRClient that allows registering more bundles, which I will make use of in the next (and hopefully final :D ) diff.
I was initially planning on using structured data, like `{bundleName, platform}` but decided to keep using URLs as that is the format used throughout Metro. In fact, when we parse the options from the URL, we need to re-encode the input URL to create the `sourceMapUrl`. I thought it doesn't make sense to write more code to send structured data over the connection only to re-construct a URL on the server manually.
Finally, I also slightly modified the "Internal Bundler" error that is shown in a RedBox (now used by the websocket connection if an invalid message is received). I removed the "internal" wording from the message and I'm actually attaching the failure message to the error instead of directing users to the Terminal.
Reviewed By: gaearon
Differential Revision: D16162729
fbshipit-source-id: 977fde5f6c2f1c14efb4fd99ed30a6bf95a3b13e
Summary:
We've seen some crashes from exceeding property limits (>200k) from storing callbacks, which is insane since callbacks should be called and cleaned up right away in most cases. Browsing around I never see more than about 50 pending callbacks when firing off a whole much of animations and measures and stuff.
In order to track down the leak, I added some code in `__DEV__` to provide more info - hopefully some developers will hit it and report the issue. Unfortunately it's not easy to get any useful information in prod because we strip all the useful debug info, but if this continues to be a problem we could try capturing that info in prod as well (and maybe other info, too).
Reviewed By: PeteTheHeat
Differential Revision: D16267702
fbshipit-source-id: 8185bb8ff0d646b307c98238616950086b1a608f
Summary:
Previously, Fast Refresh socket was initialized lazily. This changes it to be initialized eagerly, even if Fast Refresh is off.
This makes it easier to reason about different states the app can be in. It also lets us later change the code to stash away updates even when Fast Refresh is off — and apply them when you turn it on. (That's out of scope of this diff).
This change should not be user observable. Even if setting up the socket fails, the error is saved, and should only be shown once you turn it on. (AFAIK, D16286232 fixes the last error that was shown unconditionally.)
Reviewed By: rickhanlonii
Differential Revision: D16287232
fbshipit-source-id: a88f9c9f72847074876087da46e19dffa4eb82eb
Summary: I originally added `forceFullRefresh` as an escape hatch in case Fast Refresh is too unreliable. In practice we haven't seen any major issues with it. Since this option is already very obscure, I'm just removing it.
Reviewed By: shergin
Differential Revision: D16286632
fbshipit-source-id: c3dc44cffd459912e194e273acf868f3380c64cc
Summary:
This fixes a problem that occurs when:
1. You run an Android app with Fast Refresh on
2. Kill the app
3. Start the app again
We used to redbox (on Android only). This is probably because we are missing some check on the native side, and we try to enable the socket anyway.
We could potentially fix this on the native side. But also, there's no good reason why this code needs to ever throw an error if Fast Refresh is disabled.
So I'm unifying it with the existing code path for other Fast Refresh errors. They are ignored when it's off, shown as yellowboxes when it's on, and shown as redboxes if you intentionally try to turn it off and on again.
I'm also adding core to prevent logging more than one Fast Refresh warning. Since they're not super actionable and usually indicate the same problem (e.g. Metro not running). The earliest one wins.
Reviewed By: rickhanlonii
Differential Revision: D16286232
fbshipit-source-id: bf3960f11c767a2352b1282d46950e4ba9e5031d
Summary: These warnings are both noisy and unactionable to product developers when you disconnect a Metro server. You also see them *after* the redbox is closed anyway, so you kind of already know if symbolication didn't work. So I'm downgrading it to a simple log.
Reviewed By: motiz88
Differential Revision: D16285591
fbshipit-source-id: c0e4c9168f66f4573404aa336ab889e4e9da0c22
Summary: We doesn;t support `onError: (string) => void,` is codegen so I change it to `onError: (error: string) => void,`
Reviewed By: TheSavior
Differential Revision: D16284628
fbshipit-source-id: a80a5da54823c827aa0bbe1f1f99613a35605489
Summary: Union type is not supported by codegen and doen not have any impact on generated cpp code so I feel we may get rid of this only one case in favor of any.
Reviewed By: TheSavior
Differential Revision: D16283000
fbshipit-source-id: 210a8fbb7c191031e887d66e28dca048006ce00f
Summary: Currently callback has type `callback: (result: boolean) => mixed` what is pointless (and breaks codegen), because value returning flow callback doesn't have any impact.
Reviewed By: RSNara
Differential Revision: D16282852
fbshipit-source-id: fe1036f17bff307ac91b280727eaa5bf81febd35
Summary:
@public
`reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated.
In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`).
This change is backwards compatible in two senses:
1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable.
2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`.
Naturally, both fallbacks mentioned above discard `extraData`.
NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback.
While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes.
Reviewed By: mmmulani
Differential Revision: D16133080
fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
Summary:
This diff allows for parsing more flexible AST format.
Reusing logic used for methods, I add similar support for props and commands in components. Now it's possible to define separated type for props and commands in another part of the file.
Also, extracted this method to another file for reusing purposes.
Added tests.
Reviewed By: rickhanlonii
Differential Revision: D16221445
fbshipit-source-id: 21553bf5ade66588dd7dc0320d25333260b0ada9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25671
Moves the RN-specific `ReactFiberErrorDialog` implementation from React to RN for easier iteration. Also adds new unit tests.
This current change is additive, so we're compatible with the current React renderer which still uses `ExceptionsManager` and not the file added here. After the corresponding React update we can remove `ExceptionsManager` from the RN private interface entirely.
Reviewed By: cpojer
Differential Revision: D16278938
fbshipit-source-id: 0c2c0c3e65e524e079730ae3b0cc23e0c0bdc5fd
Summary: It's ok to put VLists in ScrollViews with different scroll directions.
Reviewed By: yungsters
Differential Revision: D16217209
fbshipit-source-id: 7b1c3e93c19867da7414ccda4cda8cc89d25d522
Summary:
Original commit changeset: c45409a8413e
I was unable to find the cause of the problem.
Reviewed By: yungsters
Differential Revision: D16240754
fbshipit-source-id: c1e3f0aa615422f1156706f919e8f851f82c18b0
Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety`
Reviewed By: PeteTheHeat
Differential Revision: D16210888
fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25583
We now use CocoaPods for better maintainability.
Reviewed By: hramos
Differential Revision: D16193719
fbshipit-source-id: 26382f2da4eaba14a71771540b587fdc80b41108
Summary: For now, suppress this warning - they are harmless.
Reviewed By: mdvacca
Differential Revision: D16198994
fbshipit-source-id: b167d0e98bbc4abcd0461d50f01f364d8d560aec
Summary:
We added a test to make sure button and accessibility actions would not have unwanted behavior. Additionally we added support for accessibility actions for all touchables. However we discovered that RCTTextView and possibly anything else that does not derive from RCTView does not support accessibility actions and need to be children off a component that does support it for it to not crash in ios. This became noticeable when TouchableWithoutFeedback only worked if text is a child of view on ios.
In a local branch we where able to modify RCTTextView to support accessibility actions and text no longer needed to be a child of view for it to work.
## Changelog
[General] [Added] - Button test with accessibility actions
[General] [Added] - Support for accessibility actions to all Touchables. With TouchableWithoutFeedback being a special case where text must be a child of view. (See AccessibilityExample.js for an example)
Pull Request resolved: https://github.com/facebook/react-native/pull/25582
Test Plan:
Test plan is testing in RNTester making sure the examples work
## Open Question
What would you say is the best practice for adding accessibility action support for all the components that do not extended from RCTView?
Reviewed By: cpojer
Differential Revision: D16192919
Pulled By: osdnk
fbshipit-source-id: 7d4e186ba1f30393f2b4d08a0e227b960f83586c
Summary:
Adding viewIsDescendantOf back again, more context 9ae7f0c7da
This method might no not be implemented in Fabric
Reviewed By: fkgozali
Differential Revision: D16186405
fbshipit-source-id: da91822845e3c7b1f48ebf8c4782f8a2ee593bfe
Summary: This fixes the following warning from appearing when you have a FlatList render a Modal where the content of the Modal also contains a FlatList: https://fburl.com/p953k985. Spencer addressed an issue similar to this in D7863625, but we still get a yellow box due to the fact that `scrollContext` still exists, but `this.context.virtualizedList` is null from this line in Modal.js https://fburl.com/nqc261a1.
Reviewed By: cpojer
Differential Revision: D16160666
fbshipit-source-id: ba222d3eef234f4c8c4c2bddbc71bec27df81e0a
Summary:
returning type of Bubbling and Direct Event should be always void of Promise (if async). Other situations shouldn't be permitted.
Reformated all cases when it the function wasn't void.
Reviewed By: rickhanlonii
Differential Revision: D16165962
fbshipit-source-id: 7c1377c3ed4bd54a431a13e5bcda4f7ec0adf4dc
Summary:
I'd like to use `Modal`’s flow types in my application to make a reusable component.
## Changelog
[JavaScript] [Added] - Exported `Modal`’s types
Pull Request resolved: https://github.com/facebook/react-native/pull/25554
Test Plan: n/a
Differential Revision: D16180231
Pulled By: cpojer
fbshipit-source-id: 9cfd5163a187954783102bfe4d9b4d1dbc8c6e6d
Summary: It's pointless to handle non optional key if value has withDefaul so I'm adding a rule into parser preventing from such cases
Reviewed By: lunaleaps
Differential Revision: D16166709
fbshipit-source-id: 38cef522b217917a3a4886d857720932f2ebb475
Summary: This diff changes a few things around so that a diff coming on top of this stack will be smaller. The aim of this change is to add a method `registerEntryPoint` which will allow a client to subscribe to updates for multiple bundles.
Reviewed By: gaearon
Differential Revision: D16131963
fbshipit-source-id: d460d6647b15a711021c7a3a51f52486a1aea535
Summary:
Running a PROD JS bundle with a DEV binary used to redbox with Fast Refresh on. The error said "HMRClient is not a registered callable module".
This isn't a new issue: https://www.google.com/search?q=%22hmrclient%20is%20not%20a%20registered%22. However, now it happens every time because `setup()` is now called unconditionally in a DEV native build.
Because a combination of DEV binary + PROD JS is technically possible, I'm adding a tiny shim that will make it a no-op instead of crashing. It will also explain what's wrong if you *intentionally* try to turn on Fast Refresh.
Reviewed By: sahrens
Differential Revision: D16145378
fbshipit-source-id: 0b9c0a6f30c02ca7f4a0133048450bdde3576ad2
Summary:
I know StyleSheet.create doesn’t do anything special on react-native yet but it does on react-native-web and possibly other targets.
This small change is mainly so react-native-web don’t need to keep making this change on their code base when updating the rn version.
## Changelog
[Internal] [Changed] - Move inline static styles at VirtualizedList to StyleSheet.create
Pull Request resolved: https://github.com/facebook/react-native/pull/25501
Test Plan:
It’s basically the same code, just moved.
Also it’s the same change that it’s on react-native-web project: 45f94eb43d/packages/react-native-web/src/vendor/react-native/VirtualizedList/index.js (L1650-L1654)
Differential Revision: D16130700
Pulled By: cpojer
fbshipit-source-id: 20639e2e1a795ff4819c16af15569bf12759a62c
Summary: These files are generated by tool, not for manual edit. So let this marker tell IDEs so.
Reviewed By: hramos, cpojer
Differential Revision: D16097171
fbshipit-source-id: 1f98a4d4e21acca0a7fbd386ff174dd9197c2129
Summary:
This PR adds initial support for Project Catalyst a.k.a. UIKitForMac. This is not yet meant for production, but this is enough for RNTester to successfully compile and mostly work :)
Some APIs are not supported on the Mac -- e.g. telephony, and deprecated APIs are removed on Mac ���-- those had to be ifdef'd out via platform checks.
The biggest limitation right now is that I couldn't get Web Socket code to successfully compile, and so there are a lot of temporary platform checks for that , and the RCTWebSocket.xcodeproj is marked as not supporting UIKitForMac. Again -- temporary, until someone with more knowledge knows how to fix this.
https://github.com/react-native-community/discussions-and-proposals/issues/131
## Changelog
[iOS] [Added] - Fixed compilation for macOS (Project Catalyst) -- not meant for production use yet
Pull Request resolved: https://github.com/facebook/react-native/pull/25427
Test Plan:
- Open RNTester/RNTester.xcodeproj with Xcode 10.2, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
- Open the same project with Xcode 11 beta 2 (or higher) on macOS Catalina beta, select "My Mac" as device target, and run -- see that it actually compiles and runs. **Note** there are unfortunately some required steps:
- change build configuration to Release (because packager doesn't work correctly yet)
- change development team to yours if Xcode tells you to
- go to RNTester project → Build phases → Link binary with libraries, and change `platforms` for `libRCTWebSocket.a` to `iOS` (without Mac compatibility). I can't commit that change because it breaks compatibility with earlier Xcode versions
The two extra steps for successful compile will disappear once web socket compilation for Catalyst is fixed
Reviewed By: mmmulani
Differential Revision: D16088263
Pulled By: sammy-SC
fbshipit-source-id: 9c0b932b048e50a8e0f336eaa0612851b1909cae
Summary: There is a `setUpDeveloperTools.js` and a `setupDevtools.js` files. While they do set up different devtools it is very confusing to have these two files. This diff inlines one in the other which should bring more clarity.
Reviewed By: gaearon
Differential Revision: D16121236
fbshipit-source-id: 45641c7af9639ede6dc237ac53b763cd804a05c2
Summary:
This adds a few more methods that are forwarded to Metro, most notably `console.group`, `console.groupCollapsed` and `console.groupEnd`. When using `console.group`, node.js's `console` implementation will use indentation for log messages. `console.groupCollapsed`, for now, will simply not print anything to the console. This removes all of the Relay information that was impossible to look at in Metro before.
In the future, I'd like to consider somehow including collapsed groups in the output with a way to interact and navigate through them but for now, if people would like to debug Relay queries, they should use whatever they have been using before Metro had logs.
Reviewed By: gaearon
Differential Revision: D16108266
fbshipit-source-id: 97337d93eed0b8cb464df78b59ade1fe340b7f6f
Summary:
This simplifies the first log message for every single reload. Here are the changes:
* I dropped the "application" word because at Facebook we consider these views "surfaces". However, the method is explicitly called "runApplication" because in open source most people will only have a single "application". Removing the word and instead relying on the user specified string avoids the naming problem and doesn't take away from the information.
* I removed the `__DEV__` and performance optimization log. The way RN is set up, developers will always have the correct settings for these in either dev or prod and printing them every time is superfluous. Also, it had a typo. How is it possible nobody ever noticed this?
* I also simplified the invariant below to be half as long. I think it still has the same amount of information with fewer words (this is shown in a RedBox where there isn't that much space)
Reviewed By: rubennorte
Differential Revision: D16108248
fbshipit-source-id: 57351c68fa855c02bfbb1db6416d8db61eab4c19
Summary: Visible property isn't used by native modal, neither in iOS nor in Android
Reviewed By: osdnk
Differential Revision: D16107927
fbshipit-source-id: 6f8b8db11abc0942f5af3abcc0245bc066da8c6b
Summary: D16107933 disabled the logs around setup unless they are explicitly enabled and this diff disables all logs from this module entirely unless they are explicitly turned on at the top of the file.
Reviewed By: gaearon
Differential Revision: D16108151
fbshipit-source-id: 355aaf8624fb0778884f25f02d58fe4e1237d686
Summary: This module logs helpful messages in `__DEV__` but it only logs actionable performance logs when the flag on top of the file is enabled. This diff changes those to only log when the toggle on top of the file is enabled as well.
Reviewed By: gaearon
Differential Revision: D16107933
fbshipit-source-id: 7671bc521af984d617a0f5ffc0eacd1aa5674a62
Summary:
Using Ricky's last changes I managed to subscribe for both new and old event name.
Fixed event to proper one for codegen in native code.
Reviewed By: TheSavior
Differential Revision: D16065660
fbshipit-source-id: b5d3762d673a34bbdf5a8e60ff4d51617c8adb81
Summary:
`WithDefault` appears not to be required to be prefixed with `?` because it's option value per se.
Fixed tests, removed `?` where needed, updated snapshots and review them. Added mechanism fro throwing error when `?WithDefault` found. Add tests for it.
Reviewed By: rubennorte
Differential Revision: D16048463
fbshipit-source-id: f55ed7454aacf0b8c42944a9b5c1037ad1b360fe
Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs.
Reviewed By: PeteTheHeat
Differential Revision: D16043221
fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
Summary:
This PR adds support for custom `StickyHeaderComponent` to be used in ScrollView (and by extension in FlatList, SectionList..).
Motivation: I've been working on a FlatList with hidable header that has a search field in it. Something like https://medium.com/appandflow/react-native-collapsible-navbar-e51a049b560a but using a FlatList w/ pull-to-refresh. The implementation can be found at https://snack.expo.io/vonovak/hidable-header-flatlist .
I used the `ListHeaderComponent` prop to render the custom header - as opposed to absolute positioning which is used in the linked article because I also need the loading indicator (I added `refreshing` and `onRefresh` for that) to show up above the header.
I proceeded by adding `stickyHeaderIndices={[0]}` to keep the header at the top, which seems to be the idiomatic way to do so. Then I added `Animated.View` with custom translation logic to the rendered header.
All appears to be working fine at the first sight - when you tap any item, you'll see it react to touch (red underlay). You'll also see the header becomes hidden if I scroll far enough and appears again after scrolling up. BUT - when you scroll down so that the header becomes hidden and tap the first visible item in the list, it will not react to touches! The reason is that `ScrollViewStickyHeader`
9a84970c35/Libraries/Components/ScrollView/ScrollView.js (L984)
has its own translation logic and when I tap onto the item at the top of the list, it seems like I'm tapping the item but I'm in fact tapping that `ScrollViewStickyHeader`.
I tried working around this by not specifying `stickyHeaderIndices={[0]}` and using `ListHeaderComponentStyle` prop (this needed some additional changes in 9a84970c35/Libraries/Lists/VirtualizedList.js (L786), and the animation is junky for some reason - as if the header always needed to "catch up" with the scroll offset, causing jitter) and `CellRendererComponent` (junky animations too), but concluded that allowing to specify custom `StickyHeaderComponent` is the cleanest way to make something like this work. I'm slightly surprised I needed to do all this to make such a usual pattern work - am I missing something?
## Changelog
[GENERAL] [ADDED] - allow custom StickyHeader in ScrollView-based components
Pull Request resolved: https://github.com/facebook/react-native/pull/25428
Test Plan: This is a minor change that should not break anything; tested locally.
Differential Revision: D16073016
Pulled By: cpojer
fbshipit-source-id: cdb878d12a426068dbaa9a54367c1190a6c55328
Summary:
See https://fb.workplace.com/permalink.php?story_fbid=2337018256625463&id=100009037038038&substory_index=58 for motivation.
I opted for using a substring that is unlikely to come up in warnings in product code but is shared across all lean core warnings. I think this is good enough and won't require updates every time we deprecate a new module.
Reviewed By: yungsters
Differential Revision: D16073431
fbshipit-source-id: 136b9e8ab53c85d2de5ed7844780f5d082087a7d
Summary:
It's not needed to keep required providing default values even if they are not actually relevant.
Here I add a support for `null`, `0` of `false` instead by default and remove throwing errors if no other default value provided.
Reviewed By: rubennorte
Differential Revision: D16049047
fbshipit-source-id: bc4961af3873190568f2753fc4ec975354896df5
Summary:
It appears that `(e: BubblingEvent<T>) = mixed` exists only in given context and it's pointless to keep in this way. It could be simplified to `BubblingEventHandler<T>` without any negative consequences and that's the motivation of this diff.
The only tradeoff of this decision is leaving an opportunity to declare Bubbling/Direct event in the top of the file bc then analysing the code becomes much more difficult. However, it's not used anywhere so it's not a problem now and probably any time.
Also, changes the names to `DirectEventHandler` and `BubblingEventHandler` which are more related to current state. The names were updated in many places in code.
Reviewed By: rubennorte
Differential Revision: D16054571
fbshipit-source-id: 741d075eb46b80bac8eb73a6b30fc0b448cb3902
Summary:
This breaks virtualization, viewability callbacks, and other features, so should be warned against.
Hopefully this would have made D15890785 trivial to figure out.
Reviewed By: PeteTheHeat
Differential Revision: D16040939
fbshipit-source-id: 593cd5da9891450fdcb501aef41455cf2d7baa4f
Summary:
This diff adds a way for the codegen to handle view configs with non-standard top event names by adding a `paperTopLevelNameDeprecated` field to events in the schema.
## The problem
The problem this is solving is that Android host components build their own options for event settings in the view config. So instead of enforcing `onChange` to use the top level event name `topChange` like iOS does, Android can use `change` or `forbarChange` or anything the person adding the component wanted at the time:
```
// Expected
topChange: {
registrationName: 'onChange',
},
// Android
bringBackStargateYouCowards: {
registrationName: 'onChange',
},
```
This is possible because of the way Android builds these settings
```
// On iOS, notice that there's no option to change the top level name:
RCT_EXPORT_VIEW_PROPERTY(onChange, RCTDirectEventBlock);
// On Android, you provide the top level event name
Override
public Map getExportedCustomDirectEventTypeConstants() {
return MapBuilder.of(
"bringBackStargateYouCowards",
MapBuilder.of("registrationName", "onChange"));
}
```
Since the codegen does not allow us to specify the top level event name (similar to iOS), we don't have a way to customize the names to support android
## The solution
To fix this, we're adding an extra option the event flow types:
```
onBubblingChange: (event: BubblingEvent<Event, 'customBubblingName'>) => void,
onDirectChange: (event: DirectEvent<Event, 'customDirectName'>) => void,
```
These will register **both** top level names in the view config:
```
{
directEventTypes: {
// Notice the same registration name is configured for different top level events
topChange: {
registrationName: 'onChange',
},
bringBackStargateYouCowards: {
registrationName: 'onChange',
},
}
}
```
This means when either `topChange` or `bringBackStargateYouCowards` fires it will call the onChange listener. **This gives us the flexibility to rename the native event name without breaking backwards compatibility.** Old apps will work when `bringBackStargateYouCowards` is fired, and new apps with an update will work when `topChange` fires.
Note: only the correct name will be generated for Fabric so technically we don't even really need to migrate the paper names and this prop can be deleted when paper is gone.
Reviewed By: cpojer
Differential Revision: D16042065
fbshipit-source-id: 40d076b43ffbbfc6c65c3c19de481d922a2add62
Summary:
Depending on the style props of an Animated.View it may be optimised away
by the NativeViewHierarchyOptimizer, which will make the animation to
fail, because the native view is virtual (it does not exists
in the native view hierarchy).
Although the createAnimatedComponent already sets the collapsable property
based on the this._propsAnimated.__isNative flag, it won't work on all
cases, since the __isNative flag is only set when one starts the animation.
Which won't cause a re-render to occuor, thus not setting the collapsable
property to false.
In order to prevent this issue the HOC will just set the collapsable property
to false.
## Changelog
[Javascript] [Fixed] - Properly set collapsable to false before starting a nativeDriver animation
Pull Request resolved: https://github.com/facebook/react-native/pull/25361
Test Plan:
### **Without this patch:**
Run the following App on an Android device without this patch and click start.
Outcome: The animation **will not** make the text invisible.
### **With this patch:**
Run the following App on an Android device with this patch and click start.
Outcome: The animation **will** make the text invisible.
```javascript
import React, { Component, ReactNode } from 'react';
import { View, Text, TouchableOpacity, Animated, StyleSheet, Easing } from 'react-native';
interface Props { }
const Constants = {
animation: {
duration: 500,
},
};
const text =
'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla sed orci erat. Suspendisse feugiat elit gravida elit consequat ultrices. Sed sollicitudin ullamcorper molestie. Mauris a diam neque. Vivamus in lectus.';
class App extends Component<Props> {
anim: any;
constructor(props: Props) {
super(props);
this.anim = new Animated.Value(0);
}
handleStartPress = () => {
this.anim.setValue(0);
console.log('start');
Animated.timing(this.anim, {
duration: Constants.animation.duration,
toValue: 1,
easing: Easing.linear(),
useNativeDriver: true,
}).start();
};
render(): ReactNode {
return (
<View style={styles.container}>
<Animated.View
style={{
opacity: this.anim.interpolate({
inputRange: [0, 1],
outputRange: [1, 0],
}),
}}>
<Text>{text}</Text>
</Animated.View>
<TouchableOpacity
style={styles.startButton}
onPress={this.handleStartPress}>
<Text style={styles.startButtonText}>START</Text>
</TouchableOpacity>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
alignItems: 'center',
backgroundColor: 'white',
flex: 1,
},
description: {
marginTop: 20,
paddingHorizontal: 10,
},
startButton: {
alignItems: 'center',
aspectRatio: 1,
backgroundColor: 'yellow',
borderRadius: 100,
height: 50,
justifyContent: 'center',
},
startButtonText: {
fontSize: 10,
fontWeight: 'bold',
},
});
export default App;
```
Closes https://github.com/facebook/react-native/issues/25318
Differential Revision: D15983822
Pulled By: cpojer
fbshipit-source-id: 1d790fbddc3103a2e34e114db956fa1fb465c1c9
Summary:
This is a revamp of how we decide whether to stop at a refresh boundary or to bubble to the next one.
We used to decide that at module initialization. However, that's both unnecessary overhead on start (for modules you don't plan to edit), and is actually insufficient.
In particular, even if a module only exports components (and thus is a Refresh Boundary), consecutive versions of that module might not be compatible.
For example, any of these changes should trigger reevaluation of parents:
- Adding or removing exports
- Renaming the exported component (which probably means you exported a different one, and we shouldn't preserve state)
- Converting from a class to a function, or back
- Wrapping something in a HOC
The new system handles these cases by comparing the Refresh "families" corresponding to exports, and bubbling the update up if some of them don't match up.
The tests have been rewritten from the webpack-inspired `module.hot` API (which we no longer use directly) to the Refresh API.
Reviewed By: rubennorte
Differential Revision: D16036044
fbshipit-source-id: 18018548d4aaa05877ae6fbaffe40c993c77cdf0
Summary: These files are no longer needed since all files codegen'd use flow types as the source 🎉
Reviewed By: cpojer
Differential Revision: D15961378
fbshipit-source-id: 510a298b2e97cd78a9a3648cbaa239e8134daa75
Summary:
Metro symbolication can be expensive in large apps. However, there is no need to symbolicate _runtime stacks from compile errors_. Those are pretty much useless anyway.
This will reduce the workload on Metro workers, and the delays when iterating with Fast Refresh, as the server will be busy much less often.
So I'm special-casing them and not sending the symbolication request anymore.
Reviewed By: rickhanlonii
Differential Revision: D16030087
fbshipit-source-id: 41f83ac01780c0a60cca777014e4ed95c0f3d14b
Summary:
On `textContentType` `newPassword` on ios, there is another property called `passwordRules` on ios 12 that can give hints to the os to generate a password with specific requirements like [here](https://developer.apple.com/password-rules/).
This is useful for apps that have a "register" screen with `emailAddress`/`username` and a `newPassword` fields, to let ios make a password that will satisfy the requirements and not one that might be not accepted after the user presses "register".
## Changelog
[iOS] [Added] - PasswordRules for new password textContentType input fields
Pull Request resolved: https://github.com/facebook/react-native/pull/25407
Test Plan: This is a bit harder, but to test you need to make an app that has associated domains with an apple-app-site-association file on that domain, enable iCloud Keychain on the test device, and then iOS will suggest a password, otherwise you will just get a warning on Xcode saying "Couldn't suggest password because of: blabla".
Differential Revision: D16028684
Pulled By: cpojer
fbshipit-source-id: d22426e07f1db45d1f79f5dad81f1465a9701f0b
Summary:
`TimePickerAndroid` has been merged With `DatePickerIOS` and `DatePickerAndroid` as part of Lean Core. See [repo](https://github.com/react-native-community/react-native-datetimepicker)
## Changelog
[General] [Deprecate] - Warning for `TimePickerAndroid`
Pull Request resolved: https://github.com/facebook/react-native/pull/25409
Test Plan: Warning prints when user imports `TimePickerAndroid`
Differential Revision: D16028676
Pulled By: cpojer
fbshipit-source-id: 5dfdb6d7cc144f7a171892ebd1f6b6b9b6334b56
Summary: The method 'viewIsDescendantOf' is not used in JS, to prevent future usages of this method we just remove it.
Reviewed By: JoshuaGross
Differential Revision: D16014666
fbshipit-source-id: da623a455df04851ce286427fb54849e4e9e720a
Summary: For consistency, we use the files checked in to github.
Reviewed By: JoshuaGross
Differential Revision: D15993128
fbshipit-source-id: 1e9fdd6b4111284c84cbd5a63d384ef481659b01
Summary:
Cleans up the implementation of `AndroidPicker` and the Flow types for the native components to almost work with `codegenNativeComponent`.
The remaining blocker is that the `items` prop is an array of objects: https://fburl.com/km8uj8x2
Reviewed By: rickhanlonii
Differential Revision: D15805611
fbshipit-source-id: 34bea83db8dbaaf6eb23b00e73e0c7ce292e8a32
Summary:
Note: iOS only.
This spec file (.h/.mm) was generated via FB internal codegen tool for TurboModule. The tool itself is not yet ready to be opensourced, but at least the generated file is. The output is based on all the Flow types added via https://github.com/facebook/react-native/issues/24875.
This file can be used by each ObjC NativeModule to be TurboModule compliant.
Reviewed By: rickhanlonii
Differential Revision: D15978911
fbshipit-source-id: 9e97495287bc406e0ed0ccf89cf370753b538772
Summary: This util is used for TurboModule codegen system - it's not used anywhere else for now.
Reviewed By: JoshuaGross
Differential Revision: D15971956
fbshipit-source-id: 3cb1c3df7fa96fd51d420abff1fbfd07b18fdae6
Summary:
We should remove all usages of React's legacy context API because it'll be removed from React at some point, it prevents some performance optimizations in updates and can cause conflicts between different context providers (like mixins).
This creates a new Context for `rootTag` (this granularity is intentional) so users that are consuming it via the legacy context API can start migrating away from it.
I didn't create a more generic context (like ReactRootContext, ReactApplicationContext) because having a more granular context makes it easier to track and remove it if we want to, and prevents re-rendering when users only care about certain values.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D14941918
fbshipit-source-id: 7ceea62727d10a591367b7ed7c447309b286758d
Summary:
`DatePickerIOS` and `DatePickerAndroid` have been merged as part of Lean Core. See [repo](https://github.com/react-native-community/react-native-datetimepicker)
## Changelog
[General] [Deprecate] - Warning for `DatePickerIOS` and `DatePickerAndroid`
Pull Request resolved: https://github.com/facebook/react-native/pull/25374
Test Plan: Warning prints when user imports `DatePickerIOS` or `DatePickerAndroid`
Differential Revision: D15983829
Pulled By: cpojer
fbshipit-source-id: dfa35e204bb133a1b8de67c25abaa4338b956901
Summary: The schema for these view commands is lifted wholesale from the schema for TurboModules: P67239314
Reviewed By: rickhanlonii
Differential Revision: D15943109
fbshipit-source-id: a0ccd4e47067b62970218df6a32527c15868c4a5
Summary: If you make a syntax error while there is a redbox while Fast Refresh is on, we should dismiss that redbox. Otherwise there is no way for you to tell why your code is not working.
Reviewed By: rickhanlonii
Differential Revision: D15970337
fbshipit-source-id: 1ca6c9a1b2269d198ae726d3b64e5c51506503db
Summary: This updates the renderer and Fresh packages to pull in the new error handling behavior. The new feature is that roots that errored on last save get remounted after an edit. This allows much faster iteration in the Fast Refresh mode as you don't need to do a full reload after typos.
Reviewed By: bvaughn
Differential Revision: D15967396
fbshipit-source-id: 96a82e6a4e00a8cb636d7bca037a1a43552a4cd2
Summary:
If the error doesn't come in direct response to a user action, I think a redbox is too severe. I think we don't want to associate turning on Fast Refresh with a higher frequency of redboxes. So this downgrades these messages to warnings.
If you manually try to turn it off and on again, we'll still show a redbox to remind why it's not working.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D15958952
fbshipit-source-id: bd144c98e87a9836871391ac583c268dca8009b3
Summary:
We have too many options in the Dev Menu, and they're really hard to pick from. They're also somewhat conflicting. This replaces two menu choices that have a similar purpose (faster iteration cycle) with one.
"Fast Refresh" tries to only update the affected modules, but falls back to doing a full reload if the update can't be handled by the React components.
If for some reason you prefer the "Reload-on-Save" behavior, please:
- Reach out to me so I can learn more about your use case.
- As a workaround, you can add `if (__DEV__) require.Refresh.forceFullRefresh = true` to your app's entry point to always do a full refresh.
Also note that I only removed the user-facing part of "Reload-on-Save". So if you have automation depending on it, that's gonna keep working.
I moved it above Systrace since it's a more generic feature.
As a total aside nit, I renamed "Enable Inspector" and "Disable Inspector" to "Show Inspector" and "Hide Inspector" because... that's what those options do, really.
Reviewed By: rickhanlonii
Differential Revision: D15958697
fbshipit-source-id: 20e856d56f661fe4d39b5ab47d8c44754bf70f67
Summary: The onRefresh event is a DirectEvent not a BubblingEvent
Reviewed By: PeteTheHeat
Differential Revision: D15969475
fbshipit-source-id: 049a6ffc74306246e8dbc3acdce5b0b26e849fc7
Summary:
Since we always create `module.hot` objects, the `module.hot` checks were unnecessary. They give a false impression that we're checking for a Hot Reloading mode. However, they're just Flow refinements and always exist in DEV. I made that explicit by throwing early.
Similarly, I removed a `module.hot` check inside `setupReactRefresh`, as it is always truish in DEV.
Finally, I'm adding a new mechanism as an escape hatch. It lets you do:
```
if (__DEV__) {
require.Refresh.forceFullRefresh = true;
}
```
in your entry point and opt into full refreshes on every edit. This sounds similar to "Reload-on-Save". That is because in the next diff, I plan to remove "Reload-on-Save" from user-visible options (but it'll stay for automated workflows).
So this workaround is intended for people who for one reason or another don't want to opt into Hot Reloading as an alternative. We'll need to talk to them and find out why.
Reviewed By: rickhanlonii
Differential Revision: D15958475
fbshipit-source-id: 674187ddf86a4e286dfae28f4182555a8b5d7396
Summary:
As we saw in D15947985, and later traced down to D5623623, the `hot` option isn't used by Metro anymore. The relevant transforms _always_ run in DEV regardless of the option.
Given that, it doesn't make sense that enabling or disabling Hot Reloading forces a full refresh. This significantly raises the usage barrier because **currently, you might have to wait ~20 seconds (on a large app) to just start using Hot Reloading when you're already in the middle of some screen.** So you just end up not using it.
This diff changes enabling/disabling Hot Reloading to be _instant_.
Here's how it works:
1. Now we always send the necessary info to the client via the new `HMRClient.setup()` function. It creates a Metro HMR client instance, but only actually sets up the socket if Hot Reloading is on.
2. The "Enable Hot Reloading" menu no longer forces a reload. Instead, it calls `HMRClient.enable()` which lazily sets up a socket (at most once).
3. The "Disable Hot Reloading" menu also doesn't trigger a refresh now. Instead, it calls `HMRClient.disable()`. We don't actually tear down the socket here because it's a pain to deal with race conditions and such. Instead, we keep the connection — but we _ignore the updates_ that come in while we're disabled.
4. As a result, it is possible to enable and disable it many times during a single session. (Updates while disabled would be ignored — which has a risk of making your running app inconsistent — but I'd argue it's expected and is worth it. You can always save a particular file to force it to update once the mode is on.)
5. In order to support "ignoring" updates, Metro's `HMRClient` (not to be confused with RN's module) now supports a `shouldApplyUpdates` field. The RN module uses it to disable handling updates when the mode is off.
6. In case there is an error that makes hot reloading unavailable (such as the server disconnecting), we surface the error only if the mode is on. If the mode is off, we stash the error message in the `_hmrUnavailableReason` variable, and display it next time you try to enable Hot Reloading.
Reviewed By: rickhanlonii
Differential Revision: D15958160
fbshipit-source-id: 8256fc4d5c2c3f653a78edf13b8515a5671953e4
Summary: This component is only used in native (there are no JS paths to it). Currently, the schema is being used to generate the native code for this component. Here, we add the codegen types so we still generate the native code when the schemas are removed, but the view config will never be used
Reviewed By: cpojer
Differential Revision: D15960990
fbshipit-source-id: 08fd0155f603e45785520c49a3ea86e30b276f9c
Summary: This was a mismatch with the schema
Reviewed By: cpojer
Differential Revision: D15960977
fbshipit-source-id: 08a56ac404eb5d45c6363e4574bd3d7bacf3ca08
Summary: Renames PullToRefresh to PullToRefreshView to correct a previous mistake so that this matches the Schema file
Reviewed By: cpojer
Differential Revision: D15960975
fbshipit-source-id: 575e526df2efdfa260f3cbbb4b0764998a91ade0
Summary: I think this was just an oversight when adding the flow types (notice that this flag isn't in the schema file, and the interface is required for android)
Reviewed By: TheSavior
Differential Revision: D15960965
fbshipit-source-id: 116b289261fbcaaaff53cd657a91f03dc036fb98
Summary:
The goal of this PR is to improve the pipeline currently used for displaying GIFs / animated images on iOS. It is achieved by not holding all of the decoded frames in memory at the same time, as well as happily releasing existing memory whenever possible. This code is a simplified version of what you would find in SDWebImage (it is nearly 1:1, with unsupported or uneeded things removed). By adopting this API, it also allows classes conforming to RCTImageURLLoader or RCTImageDataDecoder to return any decodable UIImages conforming to RCTAnimatedImage and have improvements to memory consumption. Because RCTAnimatedImage is just a subset of the SDAnimatedImage protocol, it also means that you can use SDWebImage easier with Image directly.
A nice to have would be progressive image loading, but is beyond scope for this PR. It would, however, touch most of these same parts.
## Changelog
[iOS] [Fixed] - Substantially lower chances of crashes from abundant GIF use
Pull Request resolved: https://github.com/facebook/react-native/pull/24822
Test Plan: TBD. (but i am running a version of this in my own app currently)
Reviewed By: shergin
Differential Revision: D15853479
Pulled By: sammy-SC
fbshipit-source-id: 969e0d458da9fa49453aee1dcdf51783c2a45067
Summary:
The current technique we use to draw text uses linear memory, which means that when text is too long the UIView layer is unable to draw it. This causes the issue described [here](https://github.com/facebook/react-native/issues/19453). On an iOS simulator the bug happens at around 500 lines which is quite annoying. It can also happen on a real device but requires a lot more text.
To be more specific the amount of text doesn't actually matter, it is the size of the UIView that we use to draw the text. When we use `[drawRect:]` the view creates a bitmap to send to the gpu to render, if that bitmap is too big it cannot render.
To fix this we can use `CATiledLayer` which will split drawing into smaller parts, that gets executed when the content is about to be visible. This drawing is also async which means the text can seem to appear during scroll. See https://developer.apple.com/documentation/quartzcore/calayer?language=objc.
`CATiledLayer` also adds some overhead that we don't want when rendering small amount of text. To fix this we can use either a regular `CALayer` or a `CATiledLayer` depending on the size of the view containing the text. I picked 1024 as the threshold which is about 1 screen and a half, and is still smaller than the height needed for the bug to occur when using a regular `CALayer` on a iOS simulator.
Also found this which addresses the problem in a similar manner and took some inspiration from the code linked there https://github.com/GitHawkApp/StyledTextKit/issues/14#issuecomment-395234885
Fixes https://github.com/facebook/react-native/issues/19453
## Changelog
[iOS] [Fixed] - Use CALayers to draw text, fixes rendering for long text
Pull Request resolved: https://github.com/facebook/react-native/pull/24387
Test Plan:
- Added the example I was using to verify the fix to RNTester.
- Made sure all other examples are still rendering properly.
- Tested text selection
Reviewed By: shergin
Differential Revision: D15918277
Pulled By: sammy-SC
fbshipit-source-id: c45409a8413e6e3ad272be39ba527a4e8d349e28
Summary:
## Context
Moving SegmentedControlIOS to use a generated view config.
---
It's worth mentioning that even though `RCTSegmentedControlNativeComponent` defines a different event type to that of `RCTView`. We currently do not have 100% type safety for the event types in Paper. In other words, when an event for `onChange` in this case comes from the native side, it could potentially be shaped differently than what was typed in the native component file. This will be addressed in `Fabric`.
```
// RCTSegmentedControlNativeComponent.js
export type Event = $ReadOnly<{|
value: Int32,
selectedSegmentIndex: Int32,
|}>;
...
export type NativeProps = $ReadOnly<{|
...
onChange?: ?(event: BubblingEvent<Event>) => mixed,
|}>
```
This means that in the view config diff, there will be a value of `none` for `bubblingEventTypes`
Reviewed By: rickhanlonii
Differential Revision: D15851692
fbshipit-source-id: 6653fe7a77e46afdd55808aa5a4df813b34d7f70
Summary:
`StatusBarIOS` has been merged with `StatusBar`. See [Implement a StatusBar frame API](https://github.com/facebook/react-native/pull/16478)
## Changelog
[General] [Deprecate] - Warning for `StatusBarIOS`
Pull Request resolved: https://github.com/facebook/react-native/pull/25350
Test Plan: Warning prints when user imports `StatusBarIOS`
Differential Revision: D15963347
Pulled By: cpojer
fbshipit-source-id: 456a7f3ccb245bd89ad322d5a2649e3bf844ba24
Summary:
When I installed React Native and loaded it up in the emulator, I wasn't really sure what the menu button was. I clicked around through the default emulator for advice but couldn't find it. So, instead this version now tells you directly what the key commands are.
Because it needs to show both<key>ctrl</key> and <key>cmd</key> (depending on dev's OS) I opted to include both and felt like it needed spaces around the `+`. So, I made that consistent everywhere.
## Test Plan
n/a
## Changelog
[Android] [Fixed] - Improves the initial copy for creating a new RN project on android
Pull Request resolved: https://github.com/facebook/react-native/pull/25353
Differential Revision: D15956358
Pulled By: mdvacca
fbshipit-source-id: aa320e30da53e6ba35f879f57740777bdee26618
Summary: This is utility for TurboModule codegen for the purpose of typesafety. It is not used anywhere else at the moment.
Reviewed By: cpojer
Differential Revision: D15929957
fbshipit-source-id: ecf68cc98b78bc5b9c2078492b853a677b625eea
Summary: FBLazyVector is a simple utility to help typesafety/codegen of TurboModule specs. This is not used widely elsewhere at the moment.
Reviewed By: hramos, cpojer
Differential Revision: D15929956
fbshipit-source-id: 17226351738335a74e7b931812a1ca901f47963f
Summary: The current grey one is very bland, hard to read (no contrast) and often looks like a bug. I've changed it to match the iOS Personal Hotspot colors which look more idiomatic.
Reviewed By: cpojer
Differential Revision: D15941200
fbshipit-source-id: d60a3744c73675b40f42c329c2a44e6b8b0a93dc
Summary:
Logging nasty objects can cause RN to lockup as we try to format it nicely. The formatting code has some safegaurds against excessive recursion and some cycles, but it's not failsafe.
This adds a limit on the total number of times format can be called before we start to bail out. In my testing, this limit keeps the format time under ~100ms for huge objects, and logcat and other log readers start truncating it anyway so there is rarely any lost information.
I also considered using wall time, but this seemed a little cleaner. Open to suggestions.
Reviewed By: yungsters
Differential Revision: D15710157
fbshipit-source-id: b50261093270d6fb67b3473432d384ec51b98fd5
Summary:
D10527979 made the "update" message sequence part of initial connection signals. But the HMR client uses this sequence as a signal to show "Hot Reloading..." bar. As a result, we were showing it on every initial load when Hot Reloading is on. This is very confusing.
As a simple fix, I now send an explicit message to mark the end of the first load. I could infer that by first update message but figured this is more explicit and less likely to break. Until we receive `connection-done`, we now don't attempt to show the "Hot Reloading..." bar.
Reviewed By: rubennorte
Differential Revision: D15936085
fbshipit-source-id: b18b6aceea6c47d919b4265e58b21fc44f77b0b3
Summary:
This removes React Transform HMR in favor of the new React Refresh implementation. It should only affect the "Enable Hot Reloading" mode. In further diffs I will remove "React Transform HMR" completely.
This is technically a breaking change for Metro so it'll need a version bump.
Reviewed By: rickhanlonii, rubennorte
Differential Revision: D15903585
fbshipit-source-id: 074380b00868cb31857f599a03799d3584c35d87
Summary:
Prior to this patch the websocket protocol was not being set when a connection
was opened, which could cause client libraries and apps to not work properly.
According to the [whatwg] spec the protocol must be set once the connection is
estabilished.
[whatwg]: https://html.spec.whatwg.org/multipage/web-sockets.html#feedback-from-the-protocol
## Changelog
[Javascript] [Fixed] - Properly set the this.protocol on WebSocket open
[Android] [Fixed] - Send the server chosen protocol to the WebSocket object
[iOS] [Fixed] - Send the server chosen protocol to the WebSocket object
Pull Request resolved: https://github.com/facebook/react-native/pull/25273
Test Plan:
In order to reproduce the issue you **need to install wampy@6.2.1**. Since **wampy@6.2.2** and newer contains a workaround for this react-native bug.
https://www.npmjs.com/package/wampy
```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow
*/
import React, { Component } from 'react';
import { Platform, StyleSheet, Text, View } from 'react-native';
import Wampy from "wampy";
const instructions = Platform.select({
ios: 'Press Cmd+R to reload,\n' + 'Cmd+D or shake for dev menu',
android:
'Double tap R on your keyboard to reload,\n' +
'Shake or press menu button for dev menu',
});
type Props = {};
export default class App extends Component<Props> {
state = {conState: 'Initializing...'};
componentDidMount() {
const url = "wss://demo.crossbar.io/ws";
const ws = new Wampy(url, {
realm: "crossbardemo",
ws: WebSocket,
debug: true,
onConnect: () => {
console.log("WAMP onConnect");
this.setState({conState: 'Connected'});
},
onClose: () => {
console.log("WAMP onClose");
this.setState({conState: 'Connection closed'});
},
onError: () => {
console.log("WAMP onError");
this.setState({conState: 'Connection Error'});
}
});
}
render() {
return (
<View style={styles.container}>
<Text style={styles.message}>{this.state.conState}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
backgroundColor: '#F5FCFF',
},
message: {
fontSize: 20,
color: 'black'
},
});
```
Using the code above one must see the message **WAMP onConnect** on Console and **Connected** in the middle of the screen
Closes https://github.com/facebook/react-native/issues/24796
Differential Revision: D15938870
Pulled By: cpojer
fbshipit-source-id: 10a0a9b40c2a69e484ead37149abc2b1158a4ffc
Summary:
Since React Native ART has been extracted to community module, we can deprecate it in Core. You can find the community module [here](https://github.com/react-native-community/art).
## Changelog
[General] [Deprecate] - Deprecate React Native ART
Pull Request resolved: https://github.com/facebook/react-native/pull/25321
Test Plan:
Deprecation warning prints when user imports ART from react-native core module.
cc. cpojer
Differential Revision: D15938910
Pulled By: cpojer
fbshipit-source-id: d360fab6582c0d6c9064005246a012d2d5391c5c
Summary:
This is a follow up PR to https://github.com/facebook/react-native/issues/24359. There's a good thread in the mentioned PR for more background for why I'm doing this change. Essentially `focusable` makes more sense since it is about whether a view can receive user-initiated focus from a pointer or keyboard.
Pull Request resolved: https://github.com/facebook/react-native/pull/25274
Differential Revision: D15873739
Pulled By: cpojer
fbshipit-source-id: 0f526bb99ecdc68131dfc10200a5d44c2ef75b33
Summary:
Reland https://github.com/facebook/react-native/issues/15611 and added the gcc warning that was different from fb internal config. The original PR missed the static keyword for the `RCTNormalizeAnimatedEventName` function which triggered the gcc warning internally but not with the OSS xcode config.
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/25317
Test Plan: Added a Slider (it uses RCTBubblingEventBlock for its onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15938856
Pulled By: cpojer
fbshipit-source-id: 7e7a3459e2a2e8b1254a2f1ec8153a159ea73eed
Summary:
This pulls in the latest package updates for Fresh. It doesn't have any user-observable behavior.
The renderer is rebuilt on top of the last cherry-picked sync. I cherry-picked https://github.com/facebook/react/pull/15928 on top of it.
Reviewed By: rickhanlonii
Differential Revision: D15901887
fbshipit-source-id: ccd974f79e4c0a2a8a8cab0d472deeaedf1e3ddd
Summary: We will need to use ES6 exports when we switch this to use the codegen'd view configs. I also need to have a named export from this file.
Reviewed By: rickhanlonii
Differential Revision: D15923789
fbshipit-source-id: 513e27834583b6d021ff06d5d7f116ccdcd27722
Summary:
View needed this wrapper to add a dev time warning about text children. Text children became supported and this warning was removed in https://github.com/facebook/react-native/pull/23195
This check is no longer necessary and we can reduce the overhead and improve the performance of View by removing this.
Reviewed By: rickhanlonii
Differential Revision: D15914658
fbshipit-source-id: 6456a9cb356245fa8104036b2948aa5c5bf39e0f
Summary:
view config RCTStickerViewNativeComponent
had to get one view config in before I left London lol
Reviewed By: rickhanlonii
Differential Revision: D15825774
fbshipit-source-id: 846d9ee1d15f6ec64d88a1af7b72fd863ae10afc
Summary: Trying to mitigate animation-related crashes in T43628589. Clues: all the crashes are off the main thread, and most operations in this class happen explicitly in blocks executed on the main thread. I think there's a category of race conditions caused by animations not being allocated yet when this code runs / being deallocated as it's running. We shouldn't need to add locks if everything just runs on the main thread.
Reviewed By: PeteTheHeat
Differential Revision: D15924310
fbshipit-source-id: d82f5434e53fd394c4a7548d52f59a0f63961779
Summary:
This diff removes an option from the codegen and replaces it with two new options
Removes:
- `isDeprecatedPaperComponentNameRCT`
Adds:
- `paperComponentName`: a better version of the removed option that allows more than just adding RCT
- `paperComponentNameDeprecated`: a new option that allows migrating native code to a new name
```
// Use for components with no current paper rename in progress
// Does not check for new name
paperComponentName?: string,
// Use for components currently being renamed in paper
// Will use new name if it is available and fallback to this name
paperComponentNameDeprecated?: string,
```
For example, Slider uses `paperComponentName: 'RCTSlider'` because it has a different name in fabric but is not currently being migrated to a new name. Because of other work in progress, we don't want to use UIManager check if we don't need to
Reviewed By: shergin
Differential Revision: D15857629
fbshipit-source-id: ca0d3b7dc4a75e00d136ae1f5c84f7423960399d
Summary:
When a synchronous call from JS to native code throws an error, it doesn't include a useful stack trace from the native side. To improve error attribution, this diff pops the frames in `MessageQueue.js` and `NativeModules.js` from the stack traces of such errors. This uses the `error.framesToPop` convention understood by RN's global error handler.
For now we limit this to errors converted from C++ exceptions in host functions, since those are not likely to ever contain further JavaScript frames at the point where we catch them; if they did, it would violate our assumption that the top two frames of the stack are in the JS bridge code.
Reviewed By: cwdick
Differential Revision: D15805054
fbshipit-source-id: 8c1dd7c81b00b6a88e31473271889af1f88f7263
Summary: Adds a test for synchronous methods (`type === 'sync'`) in NativeModules. This doesn't modify any behaviour.
Reviewed By: amnn
Differential Revision: D15804757
fbshipit-source-id: 4db76dbd0b0b111ed9311d4b7ec35a077c377f01
Summary: Adds a test for promise-returning methods (`type === 'promise'`) in `NativeModules`. This doesn't modify any behaviour.
Reviewed By: cwdick
Differential Revision: D15802452
fbshipit-source-id: 8dc1f862d33742ef4ba355ca36338e0dbabf8edb
Summary:
Types the last 3 members of the `ModuleConfig` tuple (functions, promise method IDs, and sync method IDs) as nullable and immutable arrays. This is in line with how they are used in the code; one debug-only call site had to be fixed to account for nullability.
Also updates the test data in `MessageQueueTestConfig` to explicitly conform to this type.
Reviewed By: amnn
Differential Revision: D15899159
fbshipit-source-id: b6955ba92efc73253de48e2ce7c3034fa91adce3
Summary:
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/15611
Test Plan: Added a Slider (it used RCTBubblingEventBlock for it's onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15896806
Pulled By: cpojer
fbshipit-source-id: c0ae463f4c3f890062238575e813ed7ab3b7a7e6
Summary: For better perf with TurboModule, cache the return value of NativePlatformConstants*.getConstants() in JS so that we avoid going back into native (from JS) for each call. This specific method is called very frequently throughout RN codebase.
Reviewed By: mdvacca
Differential Revision: D15893289
fbshipit-source-id: ce8016ed7d3efb420df93e27dbfa77d7d4f06cf8
Summary:
This is similar to https://github.com/facebook/react-native/pull/24995 but for iOS.
Motivation: when building a custom Text or TextInput (eg with rich text support), one needs custom text processing logic (turning the JS text value to a `NSAttributedString`).
RCTBaseTextShadowView contains `- (NSAttributedString *)attributedTextWithBaseTextAttributes:(nullable RCTTextAttributes *)baseTextAttributes;`
853c667eb5/Libraries/Text/BaseText/RCTBaseTextShadowView.m (L78)
This method, given `self.reactSubviews` creates and returns an instance of [NSMutableAttributedString](https://developer.apple.com/documentation/foundation/nsmutableattributedstring?language=objc). It's currently possible to override this method in subclasses, but the original implementation reads and writes two cache fields which are private. This PR just changes the access modifiers so that subclasses of `RCTBaseTextShadowView` can also access the caching fields.
## Changelog
Not needed I guess.
Pull Request resolved: https://github.com/facebook/react-native/pull/25283
Test Plan: This will work just the same - works locally, CI should pass.
Differential Revision: D15873741
Pulled By: cpojer
fbshipit-source-id: dd26a4241f2ac6c0870b6c302939e2f3b0ecc8ff
Summary: Requiring legacy native modules fails in bridgeless mode because they use the batched bridge, so we need to check for turbomodules first to avoid crashing. In D15703655 I reversed the order of this check for everyone, but this had some unintended side effects (everyone got turbomodules). This time I'm just using my flag to check for bridgeless mode so we can bail out of legacy native modules instead.
Reviewed By: fkgozali
Differential Revision: D15857106
fbshipit-source-id: 9d33161ae059e7a357f135c82b6865f4d2a57add
Summary:
This adds the Fresh Babel plugin and runtime to React Native dependencies. **They're not actually being used or enabled yet**. This is purely additive and just gets the deps setup out of the way for future diffs.
The `react-refresh` source of truth is in the React repo.
Reviewed By: cpojer
Differential Revision: D15828330
fbshipit-source-id: 67ec2dea8c896477ff8b434445f1730e388ea67a
Summary: This diff adds the generated view config for View (in DEV)
Reviewed By: ejanzer
Differential Revision: D15780039
fbshipit-source-id: 1ec8ed1b57fd2341552746051980129848cb8e85
Summary: This diff fixes an issue with generated view configs due to react-native-gesture-handler adding events to view which are not in the view config on javascript. These will need removed later when react-native-gesture-handler is updated for the new system
Reviewed By: fkgozali
Differential Revision: D15813596
fbshipit-source-id: 8914c093d9cb03e320406d154bb88abf557a951e
Summary: Developer tools have a lot of dependencies on the bridge, so for now I'm just disabling them in bridgeless mode entirely by guarding everything in `setUpDeveloperTools` with the `RN$Bridgeless` flag. Also consolidating some of the stuff Dan added to `InitializeCore` for hot reloading in here.
Reviewed By: zackargyle
Differential Revision: D15797924
fbshipit-source-id: 360ea81a2844e49f7281eed259fc16a541148ac2
Summary:
It turns out that it's expected in certain cases for `UIManager.getViewManagerConfig` to return null: https://fburl.com/4h4pqtd7
Instead of throwing when you try to call that function, let's log something and return null.
Reviewed By: fkgozali
Differential Revision: D15791367
fbshipit-source-id: 71cf14071d877070b4f8b2d72eaa2f10beac38db
Summary: For bridgeless RN we're not going to use the JSTimers module + Timing native module for timers (e.g. setTimeout, setImmediate, etc.). Instead we're going to install global functions from cpp for each of these, so we can just skip setUpTimers entirely in this case.
Reviewed By: fkgozali
Differential Revision: D15790638
fbshipit-source-id: 1626fe90a27cb8d385cbb700ad932969f708f0cb
Summary:
Not totally sure if this is the best way to handle this. In Venice if a native module is missing I try to log the name of the module, but I noticed that the error I was getting was getting this:
{F161460962}
Presumably this is because importing from NativeModules looks for `__esModule`, but NativeModules uses `module.export`. So it's trying to access that property on my cpp proxy object, which doesn't exist...? Changing TurboModuleProxy to use `require` seems to fix the problem.
Reviewed By: fkgozali
Differential Revision: D15787508
fbshipit-source-id: 4b9df4e3c179117999fe6de6363edbef427a8263
Summary:
Replacing UIManager.js with a shim that redirects to either PaperUIManager (containing old impl) or DummyUIManager, if `global.RN$Bridgeless` is set. The UIManager native module doesn't exist in bridgeless mode, which means requiring UIManager.js currently fatals. This is a bit hacky, but it's a lot easier than implementing a dummy native module to make it happy.
I did have to stub out all the properties in UIManagerJSInterface to appease flow, though...
Reviewed By: yungsters
Differential Revision: D15775582
fbshipit-source-id: 8e2628f75b2242971895583696122760acdad7af
Summary: Fishhook was used to try to hide the log messages from RCTReconnectingWebSocket but that doesn't really work anymore. Deleting it now to unblock people trying to build for iOS 13.
Reviewed By: cpojer
Differential Revision: D15779390
fbshipit-source-id: ef18575d5d92ac374e189b1267dee3a9befc3551
Summary: This is a re-land of 66e0258885 after fixing internal build failures.
Reviewed By: mdvacca
Differential Revision: D15764832
fbshipit-source-id: f4fb347a9c6c02fb146b24ba395436bd31a37deb
Summary: This diff turns on codegen for Slider and Switch
Reviewed By: TheSavior
Differential Revision: D15738544
fbshipit-source-id: a0dfb5b05fd62f28fc3865855986e49598dd5e19
Summary:
This diff adds a testing screen dev route to the facebook app for testing generated view configs
It's not pretty (i have 0 tetra experiance) but it gets the job done
There are three cases handled:
- No generated config �
- Invalid generated config (useful for dev) �
- Valid generated config �
On the description page we:
- Redbox it it's invalid (this could be used to redbox test all host components)
- Show diffs of the view config properties
- List all of the generated config properties
- List all of the native config properties
Using this tool, it's easy to see what the current config on native is, add correct flow types for the generated config, and validate the generated config
Coming later: adding all of the native configs to the list (will probably need filtering)
Reviewed By: cpojer
Differential Revision: D15683033
fbshipit-source-id: 5a566a56bef4f3f0bac3ea581c2e6acb2b9984e3
Summary: D15753278 brokes the build on the armv7 arch. Just backing out this diff and the build works again.
Reviewed By: rzito
Differential Revision: D15758272
fbshipit-source-id: 4e3d3f5322346d31d6160b66b8fef15963baec83
Summary:
This module is being removed from React Native via Lean Core. This diff moves all the related JS files to FB internal.
Note: I removed two references to previously removed modules from some files in this diff. I hope you don't mind.
Reviewed By: TheSavior
Differential Revision: D15714919
fbshipit-source-id: 88ea406396b31f5c255e06d9c92b67127c81db4a
Summary: This module is being removed from RN as part of the Lean Core effort.
Reviewed By: TheSavior
Differential Revision: D15714507
fbshipit-source-id: bb5dc2025a25ad450d6971e5948e7a2e678a9a25
Summary: An attempt to integrate the module flow types with internal codegen infra. Nothing of interest here, other than minor tweak on a spec (we don't support tupples...).
Reviewed By: mdvacca
Differential Revision: D15753278
fbshipit-source-id: b91d564fdbe8f72b90bea725779a9684993472b5
Summary: `verifyComponentAttributeEquivalence` checks the new JS view configs against what we get from native at runtime (in dev only). This breaks in bridgeless mode because there is no paper UIManager to ask for the viewconfigs from; this diff uses the flag from D15721940 to skip this check.
Reviewed By: fkgozali
Differential Revision: D15722127
fbshipit-source-id: d9227107e0ff7814c34beaae6461bb8232699c94
Summary:
In bridgeless mode we don't want to set up the batched bridge, which is set up as part of InitializeCore. Instead of deleting InitializeCore completely, let's just skip this step if we're in bridgeless mode, which we'll detect using a global variable set on the runtime from cpp (`RN$Bridgeless`).
This way you still get an error if the bridge is somehow not set up properly when you're not in bridgeless mode (it won't fail silently).
Reviewed By: fkgozali
Differential Revision: D15721940
fbshipit-source-id: 73896e25874dd000f37d1abc9cf6be549ab3434f
Summary: This diff removes the `React.js` forwarding module from RN open source which was only used for haste requires. I moved this file to FB internal and manually changed requires from `React` to `react`. However, I can't fully remove this forwarding module because we have files shared from www that expect to require React via the capitalized named.
Reviewed By: yungsters
Differential Revision: D15738887
fbshipit-source-id: b5b6c0be258582cfad92c13d174e5490c75152d9
Summary:
Reverse the order in which we look for modules in TurboModuleRegistry to check TurboModules first, and then fall back to legacy native modules. The main motivation for this is Venice, since requiring NativeModules.js fatals because there's no batched bridge. But we'll probably want to do this eventually anyway.
I ran a mobilelab for Marketplace home and am not seeing any significant difference in TTI.
Reviewed By: fkgozali
Differential Revision: D15703655
fbshipit-source-id: d65a4d7e09077474c30fb3938e38aee63bfa4eca
Summary:
Adds a generated view config for iOS Switch
Note: this required some refactoring because the SwitchNativeComponent file included both iOS and android componets, so I broke them out into:
- AndroidSwitchNativeComponent (not generated)
- SwitchNativeComponent (generated)
The schema that we're using is for the iOS version so that's the config that's generated here
Reviewed By: cpojer
Differential Revision: D15495402
fbshipit-source-id: 07b3bc9c780cbf8f6cbf66e976e15981cefcadfa
Summary:
This diff adds the generated view config for UnimplementedNativeView
Note: I believe this component was created in JS just for the codegen because it's unused anywhere
Reviewed By: cpojer
Differential Revision: D15494268
fbshipit-source-id: 8d17465fe59861a299b76565d6edbaf168f45906
Summary: After upgrading `react-native-gesture-handler` in D15701771, we can finally remove this :)
Reviewed By: rubennorte
Differential Revision: D15713072
fbshipit-source-id: 5039478f211a9bdb6ba0d17bed0841e188d00b46
Summary:
This diff updated the codegen flow types syntax replacing:
```
type Options = {
isDeprecatedPaperComponentNameRCT: true,
};
type ActivityIndicatorNativeType = CodegenNativeComponent<
'ActivityIndicatorView',
NativeProps,
Options,
>;
module.exports = ((requireNativeComponent(
'RCTActivityIndicatorView',
): any): ActivityIndicatorNativeType);
```
with:
```
export default codegenNativeComponent<NativeProps>('ActivityIndicatorView', {
isDeprecatedPaperComponentNameRCT: true,
});
```
This is from Tim's comment in the [View Config Codegen Quip](https://fb.quip.com/jR2aASHad4Se):
> What it CodegenNativeComponent were instead `NativeComponent.fromFlow<T>('…')` that returned `'...'`?
>And the Babel plugin swapped it for NativeComponent.fromSchema('...', {…}) which would both register and return '...'?
I went with `codegenNativeComponent` because it has nice parity with `requireNativeComponent`
I also didn't update the babel output here (we can update that whenever) because I think `registerGeneratedViewConfig` is more clear for what it's doing
Reviewed By: cpojer
Differential Revision: D15602077
fbshipit-source-id: 2d24dc32136ba6d31724f8c929b51417ba625a58
Summary:
This diff adds a babel plugin for the generated view configs which will inline them in the file instead of needing to check the view configs in (fb only)
The way it works is:
- babel reads the code
- looks for type alias `CodegenNativeComponent` in `*NativeComponet.js` files
- run the flow parser on the file source to create a schema
- run the schema into codegen to get the view config source code
- inject the generated source code back into the NativeComponent.js file
- remove the original export
- profit
After this diff we will remove the `js1 build viewconfigs` command and the checked-in NativeViewConfig.js files
Note: since this plugin is not published to open source, for now OSS will continue using the `requireNativeComponent` function
Reviewed By: cpojer
Differential Revision: D15516062
fbshipit-source-id: a8efb077773e04fd9753a7036682eeaae9175e09
Summary:
This diff updated the format of generated view configs so that they don't need to spread View props into every config, by adding a new registerGeneratedConfig function which will spread them instead
This is a bit of a cleanup of the generated output but is primarily so that the view config babel plugin will not need to rely on object spreading or object.assigns
Reviewed By: TheSavior, cpojer
Differential Revision: D15517199
fbshipit-source-id: 08e575578177bad12d40ee3dcad9381974b6466d
Summary: This is being removed from RN as part of Lean Core.
Reviewed By: rickhanlonii
Differential Revision: D15666249
fbshipit-source-id: 00612b999184f216cc3deb72c6b24af359060abe
Summary:
This is the same diff as D14786123 but with one of the buck targets fixed that only failed on continuous and didn't run during land time.
This moves Map/Set to fb internal. We do not need them in open source any more but we still need this in some apps at FB that use an old version of JSC.
Reviewed By: rickhanlonii
Differential Revision: D15713305
fbshipit-source-id: caec43c76a6255b2af1693c13d8dea31d7d674f5
Summary:
Hot reloading propagates upwards through the inverse dependency tree — from a file you edited, to the files that import it, and so on. However, we can't always reevaluate everything. Many core infra modules can't run twice, and also the more you run, the more the risk of encountering a module with init side effects. So our practical compromise is to stop the propagation when we reach a module whose exports look like React components. We say that such module "accepts" an update. This means that in practice, changes trigger module reevaluation up to the closest component modules from the edited file. (If you edited a component file, it re-executes alone — unless it exports a non-component.)
However, current implementation has a problem. Sometimes there is an inverse dependency path that has no "accepting" modules whatsoever. For example, maybe you're editing some core module, and its inverse dependency tree reaches goes into React Native itself. Or maybe it reaches the entry point with a bunch of side effects that can't be repeated, like registering the app root component.
In the past, such cases would lead to confusing errors like "Expected `FBPrelude.conclude()` to have been called" after hot reload. This was because we kept re-executing modules all the way upwards, even if there is nothing that can accept the update on the path. Eventually we'd reach top-level modules in the import graph that don't like to run twice.
This diff changes the logic so that we *don't attempt* to re-execute the module factories if we know that some inverse dependency path doesn't terminate in a component. In that case we know we simply *can't apply the hot update* because it doesn't stop at a point we can handle, like a React component.
Since the hot update fails in this case, I'm making it fall back to a regular reload. This is similar to how webpack handles a similar situation on the web. This means that hot updates normally don't refresh, but if we can't apply a hot update to this file, we do refresh automatically.
Reviewed By: cpojer
Differential Revision: D15631864
fbshipit-source-id: 52cd1b03739fd760f1b1b1ab8c7276a150cc3c4c
Summary:
Fixes#22752
On line 1021 you are passing base style to props:
`style: [baseStyle, this.props.style],`
Explicitly passing base style to ScrollView just overrides this line and doesn't let developers to customise style of any inheritors of ScrollView (not only FlatList) with custom RefreshControl.
So this line (1113) seems to be removed.
## Changelog
[GENERAL] [Fixed] - fix of Android's bug that doesn't let override ScrollView's Style with custom RefreshControl.
Pull Request resolved: https://github.com/facebook/react-native/pull/24411
Differential Revision: D15713061
Pulled By: cpojer
fbshipit-source-id: 461259800f867af15e53e0743a5057ea4528ae69
Summary:
`setTimeout` inside a headless JS task does not always works; the function does not get invoked until the user starts an `Activity`.
This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of `setTimeout` in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to `setTimeout` is not always called, the task will not run to completion.
This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a `{'timeout': number}` object, `AppRegistry.js` will not notify that the task has finished as per master, instead it will tell `HeadlessJsContext` to `startTask` again (cleaning up any posted `Runnable`s beforehand) via a `Handler` within the `HeadlessJsContext`.
Documentation also updated here: https://github.com/facebook/react-native-website/pull/771
### AppRegistry.js
If the task provider does not return any data, or if the data it returns does not contain `timeout` as a number, then it behaves as `master`; notifies that the task has finished. If the response does contain `{timeout: number}`, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as `master` again. If the retry was successfully queued, then there is nothing to do as we do not want the `Service` to stop itself.
### HeadlessJsTaskSupportModule.java
Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto `HeadlessJsTaskContext`. The only difference here is that we return a `Promise`, so that `AppRegistry`, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up.
### HeadlessJsTaskContext.java
Before retrying, we need to clean-up any timeout `Runnable`'s posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in `startTask` we copy the config before putting it in the `Map`, so that the initial attempt does leave the config's in the map as consumed. Then we post a `Runnable` to call `startTask` on the main thread's `Handler`. We use the same `taskId` because the `Service` is keeping track of active task IDs in order to calculate whether it needs to `stopSelf`. This negates the need to inform the `Service` of a new task id and us having to remove the old one.
## Changelog
[Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay
Pull Request resolved: https://github.com/facebook/react-native/pull/23231
Differential Revision: D15646870
fbshipit-source-id: 4440f4b4392f1fa5c69aab7908b51b7007ba2c40
Summary:
The old whatwg-fetch module doesn't actually export anything, so we would always hit the `else` condition.
The new whatwg-fetch (3.0.0, introduced in #24418) now exports an ES module. As a result, `whatwg` and `whatwg.fetch` are both truthy but the `module.exports` will end up empty. This breaks the RN fetch module.
This will switch the behavior back to the expected polyfill behavior (calling `require('whatwg-fetch')` and allowing it to polyfill fetch in global scope). The RN fetch module will re-export these globals.
Reviewed By: cpojer
Differential Revision: D15639851
fbshipit-source-id: ebd8bce85f7797d8539f53982e515ac47f6425e7
Summary:
Issue reported by Titozzz , `TextInput` would shrink when we have attributes like `lineHeight`.
Demonstration can see GIF like below:
https://giphy.com/gifs/KGNs1qIMHF3DIk1EPK
I think the reason is we apply an empty attributed string to `UITextField`, now if the length is 0, we just nil the `attributedText` instead.
## Changelog
[iOS] [Fixed] - Don't apply empty attributed string for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25143
Differential Revision: D15661751
Pulled By: sammy-SC
fbshipit-source-id: 9770484a1b68a6409e63ea25ac9a6fd0d3589b14
Summary:
Add example showing regression before this fix is applied.
https://github.com/facebook/react-native/pull/18187 Was found to introduce a regression in some internal facebook code-base end to end test which couldn't be shared. I was able to create a reproducible demo of a regression I found, and made a fix for it. Hopefully this will fix the internal test, such that the pr can stay merged.
## Changelog
[GENERAL] [Fixed] - Fix connection of animated nodes and scroll offset with useNativeDriver.
Pull Request resolved: https://github.com/facebook/react-native/pull/24177
Reviewed By: rickhanlonii
Differential Revision: D14845617
Pulled By: cpojer
fbshipit-source-id: 1f121dbe773b0cde2adf1ee5a8c3c0266034e50d
Summary:
Remote debugging stopped working (since 0.58, according to #23254). See https://github.com/facebook/react-native/issues/23254#issuecomment-474692753 for repro steps.
The root cause is incorrect checks for Chrome debugging environment in `UIManager.js`.
- In one place where sync function `lazilyLoadView` should be avoided, we effectively use `if (__DEV__ && !global.nativeCallSyncHook)` to check remote debugging, which misses ship flavor (i.e. `__DEV__` is false).
- In another place where we want to pre-populate view managers' constants to avoid calling sync function `getConstantsForViewManager`, `if (__DEV__)` is used, also missing ship flavor.
This PR fixes both checks, only using the absense of `global.nativeCallSyncHook` to determine remote debugging environments.
## Changelog
[JavaScript] [Fixed] - Correctly bypass sync calls in UIManager during remote debugging
Pull Request resolved: https://github.com/facebook/react-native/pull/25162
Differential Revision: D15692492
Pulled By: cpojer
fbshipit-source-id: 173b688f140916b767fcdbbaaf68a5c303adbcd1
Summary:
There exists race condition in `sendRequest:withDelegate:` method, it can do the session creation multiple times, because we don't lock that, which would leads `EXC_BAD_ACCESS` because use and deallocated session concurrently, we can refer to how to create a singleton safely.
Related https://github.com/facebook/react-native/issues/25152.
## Changelog
[iOS] [Fixed] - Fixes race condition of Network module
Pull Request resolved: https://github.com/facebook/react-native/pull/25156
Differential Revision: D15671734
Pulled By: sammy-SC
fbshipit-source-id: 5021e6cf33c2b55e3f7adf573ab5c8e6a8d82e23
Summary: This moves Map/Set to fb internal. We do not need them in open source any more but we still need this in some apps at FB that use an old version of JSC.
Reviewed By: TheSavior
Differential Revision: D14786123
fbshipit-source-id: 1c49b47d547ad30f2d93c00b44382cf410100b67
Summary: More verbose but descriptive error message when `TurboModule.getEnforcing` fails to find a native module.
Reviewed By: cpojer, gaearon
Differential Revision: D15619293
fbshipit-source-id: 0e8af4986d6ce9002966bb062766218ce9f89a13
Summary:
**This is a manual React sync to replace Haste names with paths so that the removal of Haste is not blocked on a normal React sync. This is a one-time special case; in the future, React will generate renderers that use paths instead of Haste.**
This commit uses the same base commit of React that's currently in RN (React ec6691a68716bc59291746fc62f374a56fb435c9) plus a commit in the React repo that removes Haste-style imports from the renderer (61f62246c8cfb76a4a19d1661eeaa5822ec37b36) and a commit to make the shims import from `implementations` (https://github.com/facebook/react/pull/15786).
I built React in the React repo with `yarn build` and copied over the `oss` directory into one called `implementations` and removed the `*.fb.js` files.
## Changelog
[General] [Changed] - Sync React with Haste-style imports rewritten to use path-based imports instead
Pull Request resolved: https://github.com/facebook/react-native/pull/25100
Reviewed By: yungsters
Differential Revision: D15575646
Pulled By: cpojer
fbshipit-source-id: adf25f9826b71729043b65ba1afd20d14d8c19c4
Summary: Before we flow-typed NativeI18nManager, we defaulted the implementation of I18nManager to something safe when it wasn't available. After the flow-type, it became a requirement that NativeI18nManager be present in the app. This is leading to crashes: T45287329. This diff re-enables the defaults for I18nManager.
Reviewed By: fkgozali
Differential Revision: D15617660
fbshipit-source-id: c3a1c737663a1a4ceae484d0ad6cbf2bd86ffe5f
Summary: This diff adds support for ColorArrayValue in the flow parser
Reviewed By: cpojer
Differential Revision: D15502923
fbshipit-source-id: 6a906b6d609168378fabeb49d0080de011a34d78
Summary: It used a wrong name, so this fixed the module lookup.
Reviewed By: yungsters
Differential Revision: D15595099
fbshipit-source-id: f5a711f595d9630541ae08339aa1532ed1d4d5f2
Summary:
Previously we tried to fix that with RCTUnsafeExecuteOnUIManagerQueueSync but that caused a deadlock (yeah, it's actually unsafe).
Besides that, I tried to solve that with introducing a mutex that covers access to `_operations` and `_preOperations` but failed miserably. It solved threading issue but that didn't fix data-races and inconsistency of the collections.
Reviewed By: sahrens
Differential Revision: D15587564
fbshipit-source-id: d1953036b09354d1663a9b191440f8b4a4e6be9d
Summary: When metro is not running, D15559151 caused infinite exceptions (fetch threw an error if it couldn't connect to localhost:8081) which affected UI. Swallow those errors and everything works well, with or without metro.
Reviewed By: yungsters
Differential Revision: D15588623
fbshipit-source-id: d170ea82478545836a7a22a228196c9778e93ef0
Summary: Some callsites access `UIManager` from `NativeModules.UIManager` instead of importing directly from `UIManager.js`. Post TurboModule spec flow typing, we don't install `getViewManagerConfig()` on the NativeUIManager object anymore, only on the JS wrapper. So callsites not importing from `UIManager.js` will break. Example: dbf746d66c/lib/components/decorateMapComponent.js (L32-L40)
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15588353
fbshipit-source-id: 2c2b497dae0660abf15acb2f944546fe03e9bb0a
Summary: This continues the migration off of haste for react-native-github by changing `react-native-implementation` not to use haste.
Reviewed By: JoshuaGross
Differential Revision: D15575896
fbshipit-source-id: 0de7314b7d038a6d603d09ca910f84d580c5cc33
Summary:
This commit more clearly defines the mocks RN sets up and uses paths instead of Haste names to define the mocks. The Jest setup script defined mocks for native modules (Obj-C, Java) and mocks for JS modules in the same data structure. This meant that some non-native modules (that is, JS modules) were in the `mockNativeModules` map -- this commit splits them out and mocks them in typical `jest.mock` fashion.
Additionally, the setup script used to mock the modules using the Haste names. As one of the steps toward migrating to standard path-based imports, the setup script now mocks JS modules using paths (native modules don't need a Haste name nor path since they are just entries in `NativeModules`). This gets us closer to being able to remove `hasteImpl`. (Tracking in https://github.com/facebook/react-native/issues/24772.)
Also, this commit removes mocks that are not referenced anywhere in the RN and React repositories (grepped for the names and found no entries outside of the Jest setup scripts).
## Changelog
[General] [Changed] - Explicitly separate mocked native modules from mocked JS modules
Pull Request resolved: https://github.com/facebook/react-native/pull/24809
Differential Revision: D15316882
Pulled By: cpojer
fbshipit-source-id: 039e4e320121bea9580196fe0a091b8b1e8b41bf
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
The previous comparison does not make sense (accessing props by index) - and always returns true. I'm going to assume there was a reason for implementing `shouldComponentUpdate` - although personally I'd just go for PureComponent (even if it may not be 100% accurate). Let me know if PureComponent sounds better.
## Changelog
not needed
Pull Request resolved: https://github.com/facebook/react-native/pull/25097
Differential Revision: D15575079
Pulled By: cpojer
fbshipit-source-id: 49aeb9d2997d3c613fe7a1af4534dff1607d53b4
Summary:
People ask "How do you use `console.log` with React Native?" and there is no good answer. This diff aims to stop people from asking this question.
See https://fb.workplace.com/groups/rn.core/permalink/2372327062999018/ for context.
This logging relies on network requests which can cause logs to show up out-of-order. To reduce the likelihood I queue every log message on the server for a maximum of 200ms. There could be other methods, like using websocket, but that seems more complex than is necessary at least in the beginning.
I considered various throttling strategies because this could be quite chatty and possibly problematic, however I think we can just ship this and iterate based on feedback. On my very underpowered laptop I logged a random number every 10 milliseconds and it didn't cause any issues or slowdown.
Reviewed By: gaearon
Differential Revision: D15559151
fbshipit-source-id: 552001622af0937ae3a37d2bd8c1b96e7ca52020
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Changed "Toggle Inspector" to "Show/Hide Inspector".
- Renamed "Live Reloading" to "Reload-on-Save".
- Hide disabled debug items when profiling is enabled.
- Changed "Start Systrace" to "Systrace Unavailable" when debugging.
- Renamed "Change packager location" to "Configure Bundler".
- Revised nomenclature in "Configure Bundler" menu to be clearer.
- Removed extraneous debug menu title.
- Consistently refer to HMR as "Hot Reloading".
Changelog:
[iOS] [Changed] - Cleaned up debug menu.
Reviewed By: axe-fb
Differential Revision: D15548628
fbshipit-source-id: 26b2ddca8280d1f6f8ff904439b403600e98a3b3
Summary: Some modules accessed PermissionsAndroid even in iOS, causing redbox. Let's relax the enforcement, then invariant() on the callsites instead.
Reviewed By: yungsters
Differential Revision: D15572716
fbshipit-source-id: 4a2edea608ab27727e88f0f246ecb9cdcf5a5329
Summary:
part of #24875. Because some of the methods are rewriteable, I dropped the `+` from the signature, this doesn't feel right to me, but I am not sure if the codegen requires that. If it does, it will probably be better to extend the spec and allow those specific methods to be overriden in a UIManager.js interface. Thoughts on that fkgozali or RSNara?
## Changelog
[General] [Added] - Add TM spec for UIManager
Pull Request resolved: https://github.com/facebook/react-native/pull/24902
Reviewed By: hramos
Differential Revision: D15551356
Pulled By: fkgozali
fbshipit-source-id: 076c4ce635aa7ea41e21cbd67c47ecd562fc320d
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
Summary: I simply removed them from RN but we should give an actionable error message for people who upgrade from older versions of RN and who may be using these old modules, at least in `__DEV__`.
Reviewed By: rickhanlonii
Differential Revision: D15554863
fbshipit-source-id: 1975d4773581258776d2586ae820677bb14488f6
Summary:
React Native Gesture Handler used to eagerly initialize all of its exports and therefore required a bunch of things from React Native eagerly. When we remove things from RN via the Lean Core project, this leads to failures.
I asked Krzysztof to make a patch release that lazily loads them instead: da658c2de2
Reviewed By: rickhanlonii
Differential Revision: D15554658
fbshipit-source-id: aa4b82e5a3c2c837d160da914f41756d26cd6c07
Summary:
Part of #24875, adds a spec for Networking. Since `sendRequest` methods are different for both platforms, I had to create 2 spec files as Flow would merge their definitions even when I added `Platform.OS` check
## Changelog
[General] [Added] - TM spec for Networking
Pull Request resolved: https://github.com/facebook/react-native/pull/24892
Reviewed By: RSNara
Differential Revision: D15543067
Pulled By: fkgozali
fbshipit-source-id: 2b91114dfa45e7899bbb139656a30a6fd52e31db
Summary:
part of #24875. I again, am not completely sure how the call site here works- appears settings can be directly accessed?
## Changelog
[General] [Added] - Add TM spec for Settings
Pull Request resolved: https://github.com/facebook/react-native/pull/24879
Reviewed By: RSNara
Differential Revision: D15543012
Pulled By: fkgozali
fbshipit-source-id: a1df3096a2fc5fe8e65d0ed2398912530bd3911a
Summary:
When code depends on a module from fbjs, its types come from the node_modules
directory. This is problematic when Flow is deployed, since we can't codemod the
parts that come from node_modules.
Reviewed By: dsainati1
Differential Revision: D15547035
fbshipit-source-id: 8794a32e0f5786bcdd80eab98344d4bc623fb674
Summary: Adding flow types for DeviceInfo module and migrating our codebase over to using `DeviceInfo.getConstants()`
Reviewed By: fkgozali
Differential Revision: D14645744
fbshipit-source-id: e30a060c6dc92938cd1420ba11a1d837c79d1e32
Summary: Reverting the generated view configs due to a potential issue
Reviewed By: mdvacca
Differential Revision: D15539319
fbshipit-source-id: bddf923dcfda18bd074196f06610fea8bb4561b4
Summary: This unbreaks an issue at FB.
Reviewed By: rickhanlonii
Differential Revision: D15536623
fbshipit-source-id: 2d59542330d2b951908adf8b6c5c41ca4232bb07
Summary: Rick manually created view config in JS for View; adding some missing attributes/events and using this instead of `requireNativeComponent`
Reviewed By: rickhanlonii
Differential Revision: D15488008
fbshipit-source-id: 48e925ec0ca2aeba9e6cc66edef0b70ee1c94d27
Summary: This removes the JS for ToolbarAndroid from RN and moves it to Ads manager, which has two remaining uses of it. In a follow-up, I will also move the native code.
Reviewed By: rickhanlonii
Differential Revision: D15469117
fbshipit-source-id: 68c3f89b85cc589a48f2dced183267daa791b53b
Summary: Fixes an issue that was including the view config native component verification function even when the native component wasn't included (e.g. on android)
Reviewed By: mdvacca
Differential Revision: D15513535
fbshipit-source-id: 9b615689c0d64757eeb3d66862e5b1902ea79b20
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Summary:
Solve #25016
Use `OK` as default text for the affirmative button if no text is specified. When setting an alert on android with button configuration, and no `text` field specified no button is shown on the alert. This makes it impossible to dismiss. An example of how this can happen is creating a simple button where a `onPress` callback is used but no text is specified:
```
Alert.alert(
'title',
'message',
[ { onPress: () => console.log('onPress') } ],
)
```
Does not change the current behavior of no text button configurations on iOS. On iOS at least one button is always shown, and buttons with no text can be displayed.
Behavior on setting multiple buttons is a little wonky, but this PR does not aim to solve it. I did test these cases and included some examples below.
## Changelog
[Android] [Fixed] - Use OK as default text on Android Alert if button configuration specified without text
Pull Request resolved: https://github.com/facebook/react-native/pull/25033
Differential Revision: D15502780
Pulled By: cpojer
fbshipit-source-id: 505a9940f4588f4c10e25b67bfed8b8a1e610c69
Summary:
Adds the generated view config for PullToRefresh
Note: we're not using this view config yet, the component is in the process of being renamed (see TODO)
Reviewed By: rubennorte
Differential Revision: D15485870
fbshipit-source-id: a163ac371181dcc990093e3cd995d7dd9058b26a
Summary:
This diff initializes the codegen flow parser using a proposal for some new syntaxes in flow file to handle missing information like:
- Float vs Int32
- Bubbling Events vs Direct Events
- Default props
- Codegen options
- Specifying the component name
For a deep dive on the proposal see: https://fb.quip.com/kPYJAjCHxlgO
Note: there are still some todos to follow up with:
- Array props
- Enum props
- Object event arguments
Note also: the parser code is a little rough, I didn't want spend too much time cleaning it up before we agreed on the format
[General][Added] Add codegen flow parser
Reviewed By: cpojer
Differential Revision: D15417733
fbshipit-source-id: dd80887c0b2ac46fdc3da203214775facd204e28
Summary: Moves relevant JS files to fb internal, removes stuff we don't need in the RN repo any more. Android and iOS will happen in a follow-up.
Reviewed By: rickhanlonii
Differential Revision: D15468419
fbshipit-source-id: 39fffc22f87534e557788e398bbae575043353b6
Summary:
As currently defined, accessibilityStates is an array of strings, which represents the state of an object. The array of strings notion doesn't well encapsulate how various states are related, nor enforce any level of correctness.
This PR converts accessibilityStates to an object with a specific definition. So, rather than:
<View
...
accessibilityStates={['unchecked']}>
We have:
<View
accessibilityStates={{'checked': false}}>
And specifically define the checked state to either take a boolean or the "mixed" string (to represent mixed checkboxes).
We feel this API is easier to understand an implement, and provides better semantic definition of the states themselves, and how states are related to one another.
## Changelog
[general] [change] - Convert accessibilityStates to an object instead of an array of strings.
Pull Request resolved: https://github.com/facebook/react-native/pull/24608
Differential Revision: D15467980
Pulled By: cpojer
fbshipit-source-id: f0414c0ef6add3f10f7f551d323d82d978754278
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 https://github.com/facebook/react-native/issues/24316 for more detail.
## Changelog
[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25001
Differential Revision: D15467829
Pulled By: cpojer
fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f
Summary: This diff fixes the flow errors that surfaced from flow-typing DialogManagerAndorid and deleting NativeDialogManagerAndroid. I also migrated all imports of NativeDialogManagerAndorid to import the module from `react-native-implementation.js`.
Reviewed By: fkgozali
Differential Revision: D15440162
fbshipit-source-id: 2fdfb68104bc8ffb93c0c77fe15aacadc182f62f
Ramanpreet Nara
Moti Zilberman
Emily Janzer
Dan Abramov
Samuel Susla
Dominique d'Argent
Christoph Nakazawa
Spencer Ahrens
Chris Blappert
Michał Osadnik
Abhishek Ghosh
Kevin Gozali
Kevin Gonzales
David Vacca
Blair Vanderhoof
Cory Reed
Bruno Lemos
Radosław Pietruszewski
Vojtech Novak
Rick Hanlon
Guilherme Iscaro
Pavlos Vinieratos
Luis Miguel Alvarado
Panagiotis Vekris
Tim Yung
Rubén Norte
Marco Zandonadi
Eli White
Eric Lewis
Janic Duplessis
Cameron Bourke
Orta Therox
Kacper Wiszczuk
Sam Mathias Weggersen
Luna Wei
Joshua Gross
Peter Argany
Anton Domashnev
Logan Daniels
Mikael Sand
Mehdi Mulani
Jordan Brown
Yannick Loriot
Пётр Потапов
Joshua Ong
Arthur Lee
zhongwuzw
Felix Oghina
Brian Zhao
Krzysztof Borowy
James Ide
Sam Goldman
Michael Mason
Valentin Shergin
mitulsavani
Oleg Lokhvitsky
Petr Nikolaev
Jarvis Luong
Dan Nguyen
Tom Sanderson
Jean Regisser
Johan-dutoit
Michał Pierzchała
Wojteg1337
michalchudziak
Abhinandan Ramaprasath
Youssouf El Azizi
Daiki Ihara
valerio.ponte
Malcolm Scruggs
Marc Mulcahy
Uilque Messias
