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
Summary:
Flow is changing the behavior of object types to no longer be valid supertypes of classes. This replaces object types when they appear as supertypes of classes to be interfaces to avoid errors when this change rolls out.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D27193522
fbshipit-source-id: c3e3fca8a4cacd90770a95b773ff2c659774b9a6
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
Changelog:
[Internal][Fixed] - Add a default value for the cache breaker value
Reviewed By: fkgozali
Differential Revision: D25907137
fbshipit-source-id: 243346cbc67d1a85519bb469f4d68d61676ba547
Summary:
Changelog:
[Internal][Added] - Create a general utils for assets and add a cache breaker utility to set/get a urlparam for remote assets.
Reviewed By: motiz88
Differential Revision: D25521331
fbshipit-source-id: 042e52a27e826bc9993e80bc68cc6fc68abaf224
Summary:
Changelog: [internal]
Return original image instead of calling `abort()` when malloc fails.
Should we show a redbox? I don't think so, the redbox wouldn't be actionable for product engineer.
Reviewed By: PeteTheHeat
Differential Revision: D25678532
fbshipit-source-id: dd44d5e87198a0f76767ea40fe111ed347a7669a
Summary:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
Summary:
All NativeModules that use `[RCTBridge moduleForName:]` to access other NativeModules are now instead using the Venice-compatible RCTModuleRegistry to access other NativeModules.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25508910
fbshipit-source-id: 85fc390063af264f2f2843e5640fa7336a784ab4
Summary:
Spotted a few errors in Codemod that migrated bridge.networking calls to [_moduleRegistry moduleForName:"Networking"] calls. This diff fixes those mistakes.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499699
fbshipit-source-id: 29f296fc1011cf65d30e083e0ef001e3185edbfb
Summary:
All NativeModules that access the _bridge from self to require the Networking NativeModule now instead get the Networking NativeModule from the _moduleRegistry.
NOTE: xbgs .networking reveal any other usages. So, there won't be a manual migration diff associated with this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499412
fbshipit-source-id: 7b0e33135c6c91ffc1e041ad3ab95f1346a8bc22
Summary:
All NativeModules that access the _bridge from self to require the ImageStoreManager now instead get the ImageStoreManager from the `_moduleRegistry`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25498774
fbshipit-source-id: 1d97888ed2ef8d295aa35cf08cb9e9f3bc33ed05
Summary:
While investigating a bridgeless networking issue, I noticed something very peculiar. **Two** networking turbo modules are built and used in bridgeless mode. Upon debugging, I realized that each of them have a different `TurboModuleHolder`. The reason is the following:
1. In JS, the module's name is [Networking](https://fburl.com/diffusion/f2xu4wie)
2. In ObjC, we call the module "RCTNetworking" (examples in this diff)
3. Both scenarios end up creating the correct Turbo Module: [RCTNetworking](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Network/RCTNetworking.mm?link_ref=search), but the `TurboModuleHolder` doesn't know that "RCTNetworking" and "Networking" are the same. Any other modules accessed this way will have the same issue.
An alternative solution would be to tell `TurboModuleHolder` to strip the `RCT` suffix, which would solve the problem globally. RSNara thoughts?
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25477044
fbshipit-source-id: 02219de578ef4d19e579110e4242883a30cefcd6
Summary:
this diff fixes the next error:
```
'RCTImageView' has a view config that does not match native. 'validAttributes' is missing: internal_analyticTag
in RCTImageView (at Image.ios.js:149)
in ImageAnalyticsTagContext.Consumer (at Image.ios.js:146)
in Image (at TintedIcon.js:55)
in TintedIcon (at TetraIcon.js:98)
in TetraIcon (at FDSCheckbox.js:67)
in FDSCheckbox (at TetraListCell.js:820)
in TetraAddOnSecondary (at TetraListCell.js:576)
in TetraPressable (at TetraListCell.js:603)
in TetraListCell (created by TetraListCell)
in TetraListCell (at RNInternalSettingsUnit.js:35)
in TetraList (at RNInternalSettingsUnit.js:32)
in RNInternalSettingsUnit (at RNInternalSettingsDeveloperModeUnit.new.js:73)
in RNInternalSettingsDeveloperModeUnit (at RNInternalSettingsSurface.js:79)
in RNInternalSettingsSurface (at withDefaultErrorBoundary.js:30)
in DefaultError(React.lazy(RNInternalSettingsSurfaceForFacebook)) (at renderApplication.js:47)
```
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D25313414
fbshipit-source-id: ab951d25ac6a80809a2977c80ff059f667cc5595