Summary:
Adding support for DatePickerStyles on iOS13.4+
Changelog:
[iOS][Added] - Expose UIDatePickerStyles as a prop for DatePickerIOS
Reviewed By: PeteTheHeat
Differential Revision: D27948608
fbshipit-source-id: fcc16c630148818d9db0c9eef8363f8592b13791
Summary:
Changelog: [internal]
`ssri` usages came from `webpack` so we ran
`yarn upgrade "webpack"`.
Reviewed By: dulinriley
Differential Revision: D27922406
fbshipit-source-id: cddca21a8035d3bd303f8cea82afe2264b35eed1
Summary:
Noticed while working in MobileHome with android device, when interacting with the Tasks change progress/priority components (MobileHomeTasksDetailsSelectorToken), which provides `borderRadius` style and `backgroundColor: ifSelected ? value : null`, and when `backgroundColor` is `null`, the line changed in this diff crashes (throwing the `NoSuchKeyException` at `ReadableNativeMap:110` [because of isNull check on `ReadableNativeMap:107`])
Changelog:
[Android][Fixed] - Fixed crash when using style borderRadius: any with backgroundColor: null
Reviewed By: JoshuaGross
Differential Revision: D27932828
fbshipit-source-id: 801b04c856ee9dc5a36bbf3e6e3d81de9b1e81a1
Summary:
This diff replaces all usages of int by int32_t. This is to ensure we always use a fixed size for int that matches what's expected on Java.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27915608
fbshipit-source-id: 634c45796dda1d4434c3ad6ff3e199931c22940b
Summary:
This diff flips the order of the tuple returned by useTransition.
See here for more info: https://github.com/facebook/react/pull/20976
Changelog: internal
Reviewed By: gaearon
Differential Revision: D27928490
fbshipit-source-id: a1896f92ef24382012fa3be1ef043752e62b21e7
Summary:
Changelog:
[Internal] - RNTester FlatList and SectionList examples to add prop for scrolling to end of list.
Reviewed By: kacieb
Differential Revision: D27816830
fbshipit-source-id: 6b4bd4cb9a651f4a4e9045d600cc219a6ba2e39b
Summary:
We have had problems with `.gitattributes`, `.bat` and `.pbxproj` (Xcode) files for a while. The two main concerns were:
- Xcode project files not diffing correctly.
- Windows files having messed up line endings.
This PR fixes both issues, hopefully forever.
After seeing the diffs from v0.63 -> v0.64 and the changes in https://github.com/facebook/react-native/pull/29792, I, again, felt that this is going to cause problems, so I looked into both issues.
I started with `git check-attr -a Artsy.xcodeproj/project.pbxproj` after removing the `.gitattributes` file that contained `*.pbxproj -text` and there are no "guessed" attributes that would break things, and diffing and checking in worked well with the current git version. I agree this is not needed, so I left it out.
I looked into what it was doing before, and it was telling git (for the xcode project file) to "unset text", which means (according to https://git-scm.com/docs/gitattributes#_text) that it should not try to do any line ending changes when checking in that file. At some point git must have done this, and that's why it was needed, but no more, so it's safe and good to get rid of this, as it helps with nothing anymore.
Now for the bat files. We don't need any extra instructions for `gradle` and `*.sh` files as they are guessed correctly, so these are also safe to keep removed (https://github.com/facebook/react-native/pull/29792/files#diff-618cd5b83d62060ba3d027e314a21ceaf75d36067ff820db126642944145393eL5).
But we do need the `*.bat` instruction. I noticed that when working on macOS there were two problems that made things funky.
- One, is that the editor (usually vscode but not the important) would convert line endings to lf when editing a bat file.
- Two, is that git thought the files are lf line endings.
To fix the first one, I added a rule in `.editorconfig` (that's whats important, when any editor just supports editorconfig, but all my editors do). I can't believe how we missed that for sooooo long {emoji:1f605}!
To fix the second, I added the `.gitattributes` instruction **and** `renormalize`d the files (https://git-scm.com/docs/git-add#Documentation/git-add.txt---renormalize and https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings). I think the problem all along was that even though the files had crlf, git still thought they were using lf.
After the editorconfig change and the renormalization, everything behaves correctly and as expected. Changing bat files on macOS and Windows is fine now, producing only the smallest change needed, no random line ending diffs. Also here is a screenshot of one of the files actually crlf. It's these tiny things at the end of each line {emoji:1f453}.
<img width="612" alt="Screenshot 2021-03-10 at 12 20 28" src="https://user-images.githubusercontent.com/100233/110630943-ef536280-819d-11eb-9212-dbd70f038a44.png">
I have tested this on macOS and Windows, doing changes in both bat and xcode files, and verified that diffing and checking in files works well.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Added an `.editorconfig` file to help with default line endings for Windows files.
[Internal] [Fixed] - Added a rule in `.editorconfig` and `.gitattributes` to help with default line endings for Windows files.
Pull Request resolved: https://github.com/facebook/react-native/pull/31128
Test Plan: Feel free to go on a macOS or Windows machine (or both) and, using any editor that supports editorconfig, do any change in a `.bat` file. Then look at your git diff in terminal or gui or whatever you use, and then look at the sky and smile. It's fixed. The diff is just your change. Everything is as it should {emoji:1f49c}.
Reviewed By: nadiia
Differential Revision: D27914636
Pulled By: hramos
fbshipit-source-id: fc4e53a4fa42cb13e29686669e8de1679c2242e7
Summary:
Adds surface id for string logs of the IntBufferBatchMountItem to help debug updates with multiple surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27884232
fbshipit-source-id: c5ec65585830f7aa5b902603bcd1e91b61cfe4c1
Summary:
There was a subtle bug in MapBufferBuilder::ensureDynamicDataSpace where in some situations allowed MapBufferBuilder to use unowned memory.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904642
fbshipit-source-id: de447633349094b0e8c5cb5e377dd31f5bfd1471
Summary:
Refactor MapBufferBuilder to use int to store size of Mapbuffer data
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904646
fbshipit-source-id: 6b8b96fdd30184b6d35c1d612743eae653854d6d
Summary:
DynamicData can contain a big amount of data, refactoring type to use int instead of short
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904643
fbshipit-source-id: 157064b280e27a9c7c4a4f55af310392b178feda
Summary:
Dynamicdata can contain long datastructures, increasing type of MapBufferBuilder.dynamicDataSize to int
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904647
fbshipit-source-id: ccbccf9328a6aa301aa3f9bf5c1b3c20f56e2a19
Summary:
found a bug in MapBuffer.getString() method, this diff is fixing it
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904644
fbshipit-source-id: 746812235539ff75c5ce53c6f872ede9779fa1fa
Summary:
Add extra asserts and early deallocation in ReadableMapBuffer::importByteBufferAllocateDirect
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904645
fbshipit-source-id: 075a007c4ec5e005b839add054bd68c233b65801
Summary:
This diff fixes the importByteBufferAllocateDirect method.
This was tested enabling importByteBufferAllocateDirect in ReadableMapBuffer.java
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27867055
fbshipit-source-id: 9ef5e93ff6c7903782598dde1c499daa82cd467b
Summary:
Add TODOs and Tasks into TODOs
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27865470
fbshipit-source-id: fcc7f86b0e6b290bf9f691a2dafea18d8addf782
Summary:
This diff adds an assert in the constructor of MapBuffer to ensure that we always access valid memory
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27864310
fbshipit-source-id: bd3870b6df1dbc5181fc5d852eb0ccbc32a8a951
Summary:
EZ refactor of MapBuffer::getCount and removal of TODO
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27864307
fbshipit-source-id: 14138090b3f2b45de8e0a3941abec990edb427ed
Summary:
This diff adds an assertion when trying to build a MapBuffer with invalid data
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27864309
fbshipit-source-id: 6601388e56be18ded0675f92cce009a577828c16
Summary:
Changelog: [internal]
Explicitly return undefined for `$$typeof` inside RuntimeSchedulerBinding.
React calls `$$typeof` on RuntimeScheduler. To make sure assert only triggers if unsupported value is requested, it needs to be explicitly handled
Reviewed By: mdvacca
Differential Revision: D27854472
fbshipit-source-id: 515c68d92b291cc274f5370c45e49302534e6f9c
Summary:
Changelog: [internal]
Scheduler's callback have option to add more work inside callback. This work stays on top of the priority queue and gives React ability to flush all work synchronously if need.
This diff adds use of `shouldYield_` to the workLoop. For now, it always evaluates to false. In the future when we allow access to the scheduler to native, it will allow yielding.
Relevant code in JavaScript:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L190
Reviewed By: mdvacca
Differential Revision: D27823528
fbshipit-source-id: 016101e41eb7c41c2ac5abb55f803814867b8517
Summary:
changelog: [internal]
Callback function in React is expecting a boolean parameter indicating whether the callback timed out. React team is removing it, that's why we only pass in hardcoded false.
Reviewed By: mdvacca
Differential Revision: D27794562
fbshipit-source-id: b96a7b31560524b8f38ad3bb0dbdb3b3b32ac97b
Summary:
Updates the Metro packages used in RN to v0.66.0, excluding the Metro server, which isn't a direct dependency.
Changelog:
[Internal]
Metro changelog:
https://github.com/facebook/metro/releases/tag/v0.66.0
Reviewed By: motiz88
Differential Revision: D27879399
fbshipit-source-id: e4014772d1fed2c93b32993fa2519f4e179a25a5
Summary:
Check the existence of `addListener` and `removeListeners` in the native module passed to `NativeEventEmitter` to determine if it can be used.
Changelog: [General][Changed] Show warning when native module without `addListener` or `removeListeners` is passed to `NativeEventEmitter`
Reviewed By: yungsters
Differential Revision: D27851425
fbshipit-source-id: c0ad3ba65a9239f5bf84548dab36e8dfbc51058a
Summary:
To prepare for the new architecture, introduce the following enforcement:
* Defining `RCT_NEW_ARCHITECTURE` in the build flag automatically enables violation reporting
* At runtime, call RCTEnableNewArchitectureViolationReporting() to enable/disable reporting - it takes effect with the future violations
* When violation reporting is enabled:
* RCTWarnNotAllowedForNewArchitecture(): log warning about a violation, but doesn't assert
* RCTEnforceNotAllowedForNewArchitecture(): assert when a violation happen
Also in this commit:
* Add warning when RCTRegisterModule() is called as a side effect of RCT_EXPORT_MODULE(). Many modules still need this, so we can't enforce it yet.
* Add enforcement when the bridge is initialize, because the new architecture cannot have the bridge.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D27847359
fbshipit-source-id: a8c4a8151cec3915ec707ce6b78f860af4bb0708
Summary:
The fbcode version of Skylight needs this and it is already compiling fine
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D27765879
fbshipit-source-id: 18aca2756f39326fb90397a10a67583db84076fd
Summary:
The `SPEC CHECKSUM` for `FBReactNativeSpec` in `packages/rn-tester/Podfile.lock` and in standalone apps's `ios/Podfile.lock` varies between development machines. This is caused by local paths in the output of `pod ipc spec FBReactNativeSpec.podspec`, such as `output_files` and `prepare_command`. This causes the Podfile.lock to constantly change when pod install is run on different developers' machines.
The codegen script and CocoaPods configuration have been updated to use relative paths.
Closes https://github.com/facebook/react-native/issues/31193
Changelog: [Internal] [Codegen] Avoid encoding local path in Podfile.lock
Reviewed By: fkgozali
Differential Revision: D27754337
fbshipit-source-id: 2f5607d4e1ce21489f28f394cb852c36cace6798
Summary:
Disable `accessibilityState` when the `TouchableWithoutFeedback` is `disabled`. This fixes https://github.com/facebook/react-native/issues/30953
## Changelog
[General] [Changed] - Disable `accessibilityState` when the `TouchableWithoutFeedback` is `disabled`.
Pull Request resolved: https://github.com/facebook/react-native/pull/31297
Test Plan: Tested the `TouchableWithoutFeedback` component on an Android device
Reviewed By: nadiia
Differential Revision: D27770689
Pulled By: kacieb
fbshipit-source-id: a317246021354ed288b093f8a5e6fbba43d3a04e
Summary:
The Inspector uses fbjni/JThread.h on Android platforms to get a Java
thread (with a class loader). Use a smaller scope dependency to bring
in fewer things.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D27799508
fbshipit-source-id: 3e1e00cf65596d12c9128fe636ed970238f4aba2
Summary:
Changelog: [internal]
This brings native scheduler close to React's scheduler. React's scheduler executes all tasks in the queue within a single dispatch (they use setTimeout(0) for dispatch) and makes sure to not schedule two dispatches.
Relevant JS code:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L359
Reviewed By: JoshuaGross
Differential Revision: D27793200
fbshipit-source-id: 4af13d95cfe4d33d0945f25929ccbea5f9ce5710
Summary:
Reverts D27764688 (5a2693d78f) due to a bug with "Invalid hook call." being erroneously reported. We will upgrade again after that bug is resolved.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D27813660
fbshipit-source-id: 84a12f19cf1bb7e8aebef0da3ff6f7022c391d3e
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c