Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Some manual fixes, in particular to React Native code, which is used and can be synced to other repos (e.g. WWW).
With these changes, error diff in Xplat is down to ~1990 errors
Note that after I roll out `exact_empty_objects`, I'll codemod all the `{...null}` (the only way to get an exact empty object currently) back to `{}`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D36142838
fbshipit-source-id: 054caf370db230f42a4c5f5706c88979ef246537
Summary:
Apple suggested to this new API on iOS 10+.
> // Any new bitmap drawing code is encouraged to use UIGraphicsImageRenderer in lieu of this API.
WWDC18 Reference: https://developer.apple.com/videos/play/wwdc2018/219/
> Use UIGraphicsImageRenderer to create and draw to an image buffer
Supports Wide Color, unlike UIGraphicsBeginImageContext()
Combine with UIImageView for efficient offscreen rendering
Per https://nshipster.com/image-resizing/#performance-benchmarks, the new API runs even faster than the C version, probably due to more smart context reuses/management.
Changelog:
[iOS][Changed] - Adopt UIGraphicsImageRenderer API
Reviewed By: philIip
Differential Revision: D35699584
fbshipit-source-id: 7a1e2109d5e121fb396c1014f4ed0a892211b0cc
Summary:
Allow modifying iOS image cache limits. Currently the image cache imposes some strict limits:
[NSCache.totalCostLimit](https://developer.apple.com/documentation/foundation/nscache/1407672-totalcostlimit?language=objc) of 20MB.
Single Image Size Limit of 2MB (bitmap size).
This may not be enough for applications that make heavy use of images. With this commit it is possible to fine tune them to the applications need.
This can be set for example in the App Delegate with:
```objc
RCTSetImageCacheLimits(4*1024*1024, 200*1024*1024);
```
This would increase the single image size limit to 4 MB and the total cost limit to 200 MB.
## Changelog
[iOS] [Added] - Allow modifying iOS image cache limits
Pull Request resolved: https://github.com/facebook/react-native/pull/33554
Test Plan: There is no easy way to test this except adding the above snippet and checking via break points that the new limits are used.
Reviewed By: cipolleschi
Differential Revision: D35485914
Pulled By: cortinico
fbshipit-source-id: 646cf7cab5ea5258d0d0d0bce6383317e27e4445
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](7a0398c331) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from 1804951595.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
The static ViewConfig codegen generates the static ViewConfig inside the JavaScript module [under an exported constant](a0a2958cda/packages/react-native-codegen/src/generators/components/GenerateViewConfigJs.js (L127-L129)):
```
export const __INTERNAL_VIEW_CONFIG = VIEW_CONFIG;
export default NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
```
This exported constant allows us to build a test page that requires all components, and compares their static ViewConfigs with their native ViewConfig.
This diff makes components with hand-written static ViewConfigs also export this __INTERNAL_VIEW_CONFIG const.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34541868
fbshipit-source-id: f55dd3f1b161038baaf84cbbf75c1f4041c34647
Summary:
## Problem
the partialLoadHandler is nil on line 338 of RCTImageLoader, therefore, if there is a cached image, it would crash on line 495.
## Change
Check if partialLoadHandler is nil on line 495 to prevent the crash
Changelog: [iOS][Changed] - fix the crash caused by nil partialLoadHandler
Reviewed By: appden
Differential Revision: D34544090
fbshipit-source-id: f9965700e529c5add1e25867a3772c053447d99a
Summary:
## Problem
Previously the RN Image render the cached images asynchronously (line 555 and 594 prior to the change), which caused the images to render at least a frame later than the adjacent components.
## Change
In this change, we call partialLoadHandler with the cached image synchronously on the main thread.
Changelog: [iOS][Changed] - Synchronously render cached images
Reviewed By: p-sun
Differential Revision: D34487673
fbshipit-source-id: 0600c2fa5f7a1eca71b8582bbe968694cf211468
Summary:
# Problem
I removed the {eventName}: true entries from ViewConfigs validAttributes in D33303950 (ca5aaa7663). These entries were iOS-only. I removed them to achieve platform-consistency in native ViewConfigs.
This change broke the onLayout event for all React Native components. So, I reverted D33303950 (ca5aaa7663) for native ViewConfigs server-side. But I never got around to reverting D33303950 (ca5aaa7663) for static ViewConfigs.
# Changes
This diff reverts D33303950 (ca5aaa7663) for Static ViewConfigs, with server-side gating.
Now, these {eventName}: true ViewConfig validAttribute will be inserted into all view configs (static and native) **by default**.
Calling RCTDisableViewConfigEventValidAttributes(YES) on iOS will remove {eventName}: true ViewConfig ValidAttributes entries from Static ViewConfigs. (Previously, this method only removed the entries from native ViewConfigs).
https://www.internalfb.com/code/fbsource/[6615b0675bdf]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/Exported/FBReactModule.mm?lines=344
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33933403
fbshipit-source-id: 17823ed99f97d7851f04e5cdab9c95667df13253
Summary:
Removes the `propTypes` member from the `Image`, `Text`, and `TextInput` components.
They have been deprecated since React Native v0.66.
Changelog:
[General][Removed] - Removed `Image.propTypes`, `Text.propTypes`, and `TextInput.propTypes`.
Reviewed By: kacieb
Differential Revision: D33750298
fbshipit-source-id: 085f83ad838196bdd531b097b8ce5957270c3ad1
Summary:
as title
in practice, this doesn't make any difference, but this is to follow the apple recommendation and for us to have a more consistent codebase.
https://developer.apple.com/library/content/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
>The NS_ENUM macro helps define both the name and type of the enumeration, in this case named UITableViewCellStyle of type NSInteger. The type for enumerations should be NSInteger.
>Like enumerations, the NS_OPTIONS macro defines both a name and a type. However, the type for options should usually be NSUInteger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32641990
fbshipit-source-id: 56e4cd44cdefe54f61c90844665a685ee2d6ffad
Summary:
Links under `reactnative.dev` that ended with `.html` lead to Page not found.
Fixed the url so that users get sent to the appropriate url.
## 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] [Fixed] - Fixed dead links in the comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/32619
Test Plan: - Changed links are accessible
Reviewed By: lunaleaps
Differential Revision: D32528978
Pulled By: cortinico
fbshipit-source-id: e039d18188371cf5240b37049e431329e28b1b8b
Summary:
This diff makes the manual changes necessary to fix many of the errors in the stacked diff codemod.
See https://fb.workplace.com/groups/flowlang/posts/917522612186736 for details on this effort.
Reviewed By: bradzacher
Differential Revision: D31615035
fbshipit-source-id: 179b2df516833d59873b9003350f81eb4a6b4e9d
Summary:
Eliminates all of the console logs that appear when successfully running Jest tests for React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D32304619
fbshipit-source-id: 8bc8ef9337ae6af588238cec7cfb874ac6067340
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Deprecates `prop-types` from React Native.
Existing use cases will be presented with a warning to migrate to the newly published `deprecated-react-native-prop-types` module.
In a subsequent release, these will be removed from React Native.
Changelog:
[General][Changed] - Accessing `Image.propTypes`, `Text.propTypes`, `TextInput.propTypes`, `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, or `ViewPropTypes` now emits a deprecation warning.
Reviewed By: kacieb
Differential Revision: D29019309
fbshipit-source-id: 21e518e588fa05c498cc75ba81f69cfa8a9d0613
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
Fix Image defaultSource not showing on iOS.
This bug was introduced somewhere between RN 0.63 and 0.65. On iOS, defaultSource does not show while the image is being downloaded, only if it fails or there's no internet.
## 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
-->
[iOS] [Fixed] - Fix Image defaultSource not showing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32172
Test Plan: Ran both debug and release builds on an iPhone 12 pro (iOS 14.6)
Reviewed By: sammy-SC
Differential Revision: D30822805
Pulled By: lunaleaps
fbshipit-source-id: c4ef18723a8311ef3be1d7ae25ff3c205e8fff62
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
This diff refactors the Image component in order to log the component hierarchy stacktraces for images rendering non-fb sources
Changelog: [Internal] internal
Reviewed By: fkgozali
Differential Revision: D30504483
fbshipit-source-id: 1e41a67d5b9643730360bce7e787ee3427d931e8
Summary:
Currently ImageBackGround component has optional style props, but if you don't pass it as prop, it still "thinks" you pass style and crushes.
In this pr, I made width and height inside component to be optional so it won't crush.
## Changelog
[General] [Fix] - Changed ImageBackground's style so it won't crush.
[Screen Shot 2021-08-20 at 15 05 45](https://user-images.githubusercontent.com/62840630/130230568-be02b1a2-52ec-4f9d-b3d3-212552d3882b.png)
As you can see in this component, I tried to use ImageBackground without any style props, and my app crushes. Then I added style with empty object and the app didn't crush anymore, as you can see here:
![Screen Shot 2021-08-20 at 15 09 23](https://user-images.githubusercontent.com/62840630/130230932-a576c397-a910-4e40-a202-56482d83dd9c.png).
In conclusion, if we make width and height styles optionals inside ImageBackground component, it won't crush anymore.
Thoughts:
Maybe consider to make style props for this component none-optional because it isn't make any sense that image won't have any style at all.
Thanks ahead, that was my first pr, Eden Binyamin.
Pull Request resolved: https://github.com/facebook/react-native/pull/32055
Reviewed By: charlesbdudley
Differential Revision: D30452297
Pulled By: sshic
fbshipit-source-id: b7071aa457dba443ed2f627c2458ea84fd24b36d
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Changes the `ImageURISource` Flow type into an interface.
- This enables both objects and class instances to be subtypes of `ImageURISource`.
- This makes it invalid to spread `ImageURISource` as a type, so `interface X extends ImageURISource` can instead be used.
- This makes it invalid to spread `ImageURISource` as a value, so `getImageSourceProperties(x)` can instead be used.
- This makes it invalid to use `$Exact` with `ImageURISource`.
Changelog:
[General][Changed] - `ImageURISource` Flow type is now an interface instead of an object.
Reviewed By: timrc
Differential Revision: D29323508
fbshipit-source-id: 647c2f9b0bfead6d7e56bdb7108e623cbf8b6c89
Summary:
This diff refactors the Image component in order to log the component hierarchy stacktraces for images rendering non-fb sources
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D29266451
fbshipit-source-id: 826230b1a18a5809b340ef0767d80a281e20477a
Summary:
This diff adds logging to uncover what are the ReactNative screens that are rendering images using NON-Facebook domains
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D29179990
fbshipit-source-id: 85f6380848d1ac1461419bc29c4666be389fb87a
Summary:
Changes `ImageURISource` back to an object type.
It was changed to an interface by D27193522 (05418f8fcc), but that is not the right direction for this type.
Changelog:
[Internal] - There was no changelog entry for this initially, so the revert can also be omitted.
Reviewed By: lunaleaps
Differential Revision: D29205798
fbshipit-source-id: 727ef70bbf47d14b163ecf5d6f31184da51c894a
Summary:
Moves `ImagePropTypes` out of `Image.android.js` in preparation for some cleanup.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017076
fbshipit-source-id: e7d3d6533f69dc2c54e7c25e215648d7c7ff1840
Summary:
As title
Changelog:
[General][Changed] Update Image.[android|ios].js to use import from instead of require
Reviewed By: TheSavior, yungsters
Differential Revision: D29003824
fbshipit-source-id: 0f98c730b1bd9cb581d2fcf6f4c0e911bb8c24b5
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
## Context
A React Native application can configure its RCTImageLoader by initializing it with two different sets of objects:
- id<RCTImageURLLoader>
- id<RCTImageDataDecoder>
Therefore, RCTImageLoader supports this initializer:
```
- (instancetype)initWithRedirectDelegate:(id<RCTImageRedirectProtocol>)redirectDelegate
loadersProvider:(NSArray<id<RCTImageURLLoader>> * (^)(void))getLoaders
decodersProvider:(NSArray<id<RCTImageDataDecoder>> * (^)(void))getHandlers
```
Right now, both the id<RCTImageURLLoader>s and id<RCTImageDataDecoder>s are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTImageLoader](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1462-1469) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the loaders/decoders: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTImageLoader gives its loadersProvider and decodersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows these two blocks to load the RCTImageURLLoaders and RCTImageDataDecoder from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTImageURLLoader's loader/decoder provider blocks RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28012999
fbshipit-source-id: 09c787923b57bbf72aff95b504f88ee1f2f44283
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type
Reviewed By: yungsters
Differential Revision: D27992320
fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
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
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729