Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35226
Changelog: [Internal]
This adds scaffolding for the C++ side of NativePerformanceObserver module.
Thanks to christophpurrer for helping set this up, as this is the first one of this kind inside core/OSS.
Reviewed By: rubennorte
Differential Revision: D41028555
fbshipit-source-id: 4acf0e71a254a42044cbbe5f94f40938342c6aa2
Summary:
[Changelog][Internal]
This adds module specs for the native part of PerformanceObserver, as well as the interaction logic vs the NativePerformanceObserver API.
See https://fb.quip.com/MdqgAk1Eb2dV for more detail.
Reviewed By: rubennorte
Differential Revision: D40897006
fbshipit-source-id: 77475f21dad9ee9dbe15df5a989eb08d314e6db2
Summary:
[Changelog][Internal]
This is to prevent an accidental use of PerformanceObserver while it's still a work in progress.
PerformanceObserver is also moved into a dedicated folder, `Libraries/WebPerformance`.
Reviewed By: rubennorte
Differential Revision: D40978749
fbshipit-source-id: 09645a95bed72902870ebc00c1b4a3d81ab4c829
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35138
Changelog:
[General][Added] - Add a C++ only TurboModule example (for Android/iOS/macOS/Windows)
react-native@0.69 introduced a new bridging layer to ease integration for pure C++ TurboModules using C++ std:: types directly instead of the lower level jsi:: types:
https://github.com/facebook/react-native/tree/v0.69.0/ReactCommon/react/bridging
This bridging layer can be used in JSI functions or more conveniently in C++ TurboModules.
Here is a example of an C++ only TurboModule which will work on Android and iOS and macOS/Windows (using microsoft/react-native-macos|windows) only using flow/TypeScript and standard C++ types.
C++ only TurboModules are very handy as they do not require to work with JSI APIs - instead std:: or custom C++ can by used.
Reviewed By: javache
Differential Revision: D39011736
fbshipit-source-id: 84c833d8540671fde8505f1aeb0265074b248730
Summary:
This PR updates he cache strategy for the `checkout_with_cache command`.
The previous strategy was using three keys in descending priority order to restore from the cache:
* `<< parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}-{{ .Revision }}`
* `<< parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}`
*`<< parameters.checkout_base_cache_key >>-{{ arch }}`
When it saves, it always saves using the first key.
The restore works as it follows:
1. It tries to restore the cache using the first key
2. If it fails, it checks whether there is a cache hit for a key that matches the second key as a pattern
3. If it fails, it checks whether there is a cache hit for a key that matches the third pattern
4. Otherwise, it is a cache miss.
This does not work well. Imagine that you submit some code in commit `xxxx` for branch `abc`.
The CI run the first time, it misses all the three keys and checks out the code normally.
Then, it stores the checked out code in the `checkout_key-abc-xxxx` key.
Then, you submit a commit `yyyy` in the same branch.
The CI starts, it tries with the key `checkout_key-abc-yyyy` but it misses
It tries with the key `checkout_key-abc` and it finds the cache for `checkout_key-abc-xxxx` and it restores it, forgetting about your changes.
While doing the release, we created a tag in a commit X. Then we manually had to remove it, but the CI had a cached version of .git with the tag for
the `0.71-stable` branch. And the release failed because the tag was already existing.
### Why this should work
With this solution, we are going to cache using the commit. If there is no cache for a specific commit, it will be a miss. It won't try to be smart and
retrieve the code from previous caches.
This should prevent stale caches and if we manually remove a tag, and then we do a new commit, it should work.
This is a good trade-off that allows to pay the checkout cost only for the first batch of jobs of the pipeline.
**NOTE:** This still won't work if we don't do a new commit.
## Changelog
[General] [Fixed] - Change Cache strategy to avoid cache bumps in Release
Pull Request resolved: https://github.com/facebook/react-native/pull/35259
Test Plan: 1. CircleCI must be green
Reviewed By: jacdebug
Differential Revision: D41120895
Pulled By: cipolleschi
fbshipit-source-id: 2b45da01803197dbe4a25a313a9dfc53a976d096
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
# Conflicts:
# scripts/cocoapods/__tests__/codegen_utils-test.rb
Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
Summary:
The project.android block is unnecessary and contains a wrong path. Let's use the default path which is `./android`.
## Changelog
[Internal] - Remove project.android block from rn-tester's CLI config
Pull Request resolved: https://github.com/facebook/react-native/pull/35197
Test Plan: Tested locally + will wait for a CI run
Reviewed By: robhogan
Differential Revision: D41013193
Pulled By: cortinico
fbshipit-source-id: 5c76c9b571b23ad71a23a8f3f05a9acb4d6e20b9
Summary:
We accidentally added `-DCMAKE_BUILD_TYPE=Debug` for Hermes which is causing
a really slow engine execution. This fixes it and keep the -DCMAKE_BUILD_TYPE
aligned with the one used on Android.
Changelog:
[iOS] [Fixed] - Correctly set -DCMAKE_BUILD_TYPE for Hermes on iOS
Reviewed By: hramos, cipolleschi
Differential Revision: D40980934
fbshipit-source-id: 30f0455990a911b51eb109bebca8272507302650
Summary:
Support various annotations types in QuickPerformanceLogger markEvent for Android.
Changelog:
[Internal][Changed] - Added support for various markEvent annotation types
Reviewed By: dmitry-voronkevich
Differential Revision: D40852658
fbshipit-source-id: fc4053555f65958653be30a58742c83040a19df1
Summary:
This change moves the default new application template in OSS from Flow to TypeScript. This better aligns with the communities usage, and aligns to the great work that has been happening for TS codegen and built-in types. This used [`react-native-community/react-native-template-typescript`](https://github.com/react-native-community/react-native-template-typescript) as a main reference, maintained by radko93. A few things are different:
1. Updated `types/*` devDependencies to match bumped libraries (e.g. Jest 26 to 20).
2. Removed `types/react-native`
3. Removed explicit `moduleFileExtensions` to Jest config in package.json (TS and TSX and added by default in current versions)
4. Removed overrides to eslint config to disable `no-shadow` and `no-undef`, since this was fixed in the underlying eslint config with https://github.com/facebook/react-native/pull/32644 and https://github.com/facebook/react-native/pull/32655
5. Re-translated `App.js` to be a direct translation (e.g. still a raw function instead of React.FC which is sometimes discouraged)
6. Aligns completely to `tsconfig/react-native` maintained configuration (We no longer have the opinionated override of `skipLibCheck`). The important settings are that `strict` is enabled for, but `allowJS` is also enabled to let users import JS modules without anything unexpected. `esModuleInterop` is enabled, which is needed for consistency with Babel import transformations used by Metro. Consistent with our [current documentation](https://reactnative.dev/docs/typescript) built against the community template, `tsc` will typecheck your code without emitting(building) anything.
[Documentation](https://reactnative.dev/docs/typescript) will need to be updated as a followup.
Changelog:
[General][Changed] - Use TypeScript by default for new applications
Pull Request resolved: https://github.com/facebook/react-native/pull/35165
Test Plan: Added usage of `tsc` and `jest` when validating a newly built app. Passes in CircleCI `test_js` job. This also meant removing some cases of copying packages into the users app to pull in the root Metro config (we seem to be able to use the template Metro config consistent with what real apps would get).
Reviewed By: cortinico
Differential Revision: D40911951
Pulled By: NickGerleman
fbshipit-source-id: 15994534235695e91cf994ad06ba2183dfc89a50
Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35166
The Hermes source code is not included in the RN npm package. This piece of code is a remnant from an early experimentation into integrating Hermes more tightly with React Native. We ended up using a combination of the scripts in `scripts/hermes` to fetch the source code from GitHub and relying on prebuilts for stable releases.
Added `strict()` flag to ensure the script fails immediately if an unrecognized flag is passed.
Avoid logging temp publishing folder value to console when `--help` is used.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D40918939
fbshipit-source-id: 2e62ab16467c4c67f03efdf5211a156cb70e0b11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35123
**Context**
On RN Desktop, images can be copy/pasted into text inputs.
When copy/pasting local files w/ semi-colons in the filename (`/downloads/devices:pre-call-IMG_346C38284B2B-1.jpeg`), RN would throw this error.
{F785684529}
The error was due to no having the correct asset loader due to the local file path being parsed incorrectly.
To parse the url, we convert the string URI to a `NSURL` using a custom convertor fn.
The conversion was matching any `:` and assuming it was a network url scheme:
https://www.internalfb.com/code/archon_react_native_macos/[fde4113acd89fb13ee11636c48b59eac49c21bae]/React/Base/RCTConvert.m?lines=97-111
When an image path with `:` in the name was passed to this, it was assuming it was a valid network url and not file path.
Because this is a local filepath, the image path needs to be a filesystem url. Since this was parsed as network url, it did not have the `file://` prefix and would not pass this check, causing the loader to throw.l
https://www.internalfb.com/code/fbsource/%5B60d9d5e67383%5D/xplat/js/react-native-github/Libraries/Image/RCTImageLoader.mm?lines=220-230
## Changelog
[iOS] [Added] - Add support for parsing files w/ `:` in filename
Reviewed By: christophpurrer, philIip
Differential Revision: D40729963
fbshipit-source-id: 2f3adcabc8f0f1f22cbfca69c3484e72b1d93d25
Summary:
Just bumping RNGP to make the new sources avialable to the template.
Changelog:
[Internal] [Changed] - Bump RNGP to 0.71.8
Reviewed By: robhogan
Differential Revision: D40948246
fbshipit-source-id: c6a193fcdc0675be9ef7f1320d63e884b8b65daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35181
As the title says, this unblocks `test_buck` by removign the lambdas used inside test.
Changelog:
[Internal] [Changed] - Fix test_buck by not using lambdas inside ReactImagePropertyTest
Reviewed By: cipolleschi
Differential Revision: D40958412
fbshipit-source-id: 60b8609a25985230dfd6c4dcdf983dc2a8cfaf64
Christoph Purrer
Ruslan Lesiutin
Pieter De Baets
Ruslan Shestopalyuk
Oleksandr Melnykov
Riccardo Cipolleschi
Nick Gerleman
Distiller
Lorenzo Sciandra
Nicola Corti
Distiller
Distiller
Distiller
Nicola Corti
Dmitry Rykun
Distiller
Sergei Karpukhin
Nick Gerleman
Lulu Wu
Héctor Ramos
Shawn Dempsey