Update to react-native 0.79 - #6607
Conversation
0f0b912 to
e28145c
Compare
0fc2f71 to
ce5683b
Compare
23c079a to
84e7a74
Compare
|
|
||
| const conditionalProps = shouldUseFasterImage | ||
| ? { | ||
| key: `${typeof source === 'object' && source.uri ? source.uri : ''}` || undefined, |
There was a problem hiding this comment.
Key cannot be spread like this anymore in React 19
601bdb3 to
903386e
Compare
36efdac to
adb9503
Compare
| +++ b/node_modules/react-native-animateable-text/lib/typescript/src/index.d.ts | ||
| @@ -1,4 +1,4 @@ | ||
| -declare const AnimateableText: import("react").FunctionComponent<import("react-native-reanimated").AnimateProps<Omit<import("react-native").TextProps, "children"> & { | ||
| +declare const AnimateableText: import("react").FunctionComponent<import("react-native-reanimated").AnimateProps<import("react-native").TextProps & { |
There was a problem hiding this comment.
just curious - why do we need to stop removing children type?
There was a problem hiding this comment.
If I remember correctly this is due to a type change in React types that no longer automatically adds children. If we omit children here then the resulting type no longer had it.
There was a problem hiding this comment.
Possibly the React.FunctionComponent type
| {...props} | ||
| key={`${typeof source === 'object' && source.uri ? source.uri : ''}` || undefined} | ||
| onError={this.props.onError} | ||
| onLoad={undefined} |
There was a problem hiding this comment.
i suppose overwriting onLoad to undefined was intended 🤔 doubtful but we could leave it to err on the side of safety
There was a problem hiding this comment.
Yea also not sure, just kind of ported the existing code 1 for 1 just in case it is actually needed.
natew
left a comment
There was a problem hiding this comment.
Overall looks good, and glad actually there's not so many js-level changes needed here which is great.
My two questions are:
One, I noticed there's quite a few propTypes left still in .js files, do we need to remove these?
Smaller, but I noticed we have old React 18 types in the design system docs. cc @christianbaroni do we want to update that alongside this?
Minus those the code looks good, going to test it on-device now.
|
For prop types I think I saw there are codemods around to convert it to typescript types so I wanted to keep them around if we want to do that eventually. They are just no longer checked, but don’t cause any issues. |
|
Having trouble getting pods to install: And then: |
|
Ah yea this is just some weird Pods cache thing, not sure if we can detect/clear it automatically but fixed on my end by clearing it. |
8cc6d51 to
930754c
Compare
|
Conflicts fixed |
natew
left a comment
There was a problem hiding this comment.
Code lgtm, did a basic build and tested my wallet and a few areas.
ibrahimtaveras00
left a comment
There was a problem hiding this comment.
Found some UX issues and a crash
https://linear.app/rainbow/issue/APP-2759/qa-bug-epic-for-rn-upgrade
|
Here's a quick summary of the last changes:
|
| */ | ||
| export function getLuminanceWorklet(color: string): number { | ||
| 'worklet'; | ||
| const processedColor = processColor(color); |
There was a problem hiding this comment.
Do you prefer to keep the color validations? Only thing is would lead to double processing.
From my testing, passing an invalid color to convertToRGBA returns a black color
| } | ||
|
|
||
| export const ApplyShadow = React.forwardRef(({ backgroundColor, children: child, shadows }: ApplyShadowProps, ref: React.Ref<any>) => { | ||
| export const ApplyShadow = ({ backgroundColor, children: child, shadows }: ApplyShadowProps) => { |
There was a problem hiding this comment.
There was some new warnings (prob because of the react upgrade) related to forwardRef ref param not being used. For this component if we are in the case if (!shadows) return child; the ref is not used. I noticed we actually never pass ref to this component so I just removed the forward ref.
| ); | ||
|
|
||
| if (IS_TEST || (IS_ANDROID && !enableOnAndroid)) return children; | ||
| if (IS_TEST || (IS_ANDROID && !enableOnAndroid)) { |
There was a problem hiding this comment.
We need to make sure to apply containerStyle in this case. This wasn't a regression from this PR, but included the fix here since it is pretty simple.
| if (!child) return null; | ||
| return ( | ||
| <> | ||
| <Fragment key={index}> |
There was a problem hiding this comment.
Fix a missing key warning.
|
|
||
| const TruncatedENS = ({ ens, truncationLength, ...props }, ref) => { | ||
| const text = useMemo( | ||
| const text = React.useMemo( |
There was a problem hiding this comment.
Not sure if this code is used, but use useMemo was not imported
| }; | ||
|
|
||
| const FreezableWebView = memo(React.forwardRef(FreezableWebViewComponent)); | ||
| const FreezableWebView = memo(FreezableWebViewComponent); |
There was a problem hiding this comment.
This component didn't use ref
WoLewicki
left a comment
There was a problem hiding this comment.
Left some comments, looks good overall!
| with: | ||
| cache-read-only: false | ||
|
|
||
| - run: cd rainbow-scripts && git checkout @janic/rn79 |
There was a problem hiding this comment.
Do we want to leave it here or will it be removed before merge? Same for other occurences.
There was a problem hiding this comment.
No, we removed it right before merge, was only needed to get ci passing before we merge some prs in rainbow scripts
|
|
||
| ReactNativePerformance.onAppStarted() | ||
|
|
||
| #if RAINBOW_INTERNALS_ENABLED |
There was a problem hiding this comment.
Does this work correctly in Swift? I can see it was taken from Internals module previously.
There was a problem hiding this comment.
I think this is actually never worked? It was also previously a preprocessor macro, but we never define it, it is a const in objc.
| return success | ||
| } | ||
|
|
||
| func hideSplashScreenAnimated() { |
There was a problem hiding this comment.
Maybe we should just move it to RainbowSplashScreenManager ?
There was a problem hiding this comment.
Wanna open a PR for that one?
| "@types/prop-types": "15.7.14", | ||
| "@types/qs": "6.9.7", | ||
| "@types/react": "18.2.65", | ||
| "@types/react": "19.1.3", |
There was a problem hiding this comment.
Should we sync this types minor version with React's one? (so 19.0.x)
| #if !TARGET_OS_OSX | ||
| - _displayLink.preferredFramesPerSecond = 120; // will fallback to 60 fps for devices without Pro Motion display | ||
| + if (@available(iOS 15.0, *)) { | ||
| + _displayLink.preferredFrameRateRange = CAFrameRateRangeMake(80, 120, 80); |
There was a problem hiding this comment.
@christianbaroni has some context about this one, trying to find it again, but I cant
| ARCHS_FLAG="-PreactNativeArchitectures=$ARCH" | ||
| fi | ||
|
|
||
| export SENTRY_DISABLE_AUTO_UPLOAD=true |
There was a problem hiding this comment.
Was it meant to stay here?
There was a problem hiding this comment.
Yes, we don’t want to upload to sentry for e2e builds
There was a problem hiding this comment.
Not sure why I added it in this pr, but I think it makes sense
|
|
||
| const animatedTopColor = useDerivedValue(() => { | ||
| if (IS_TEST) return getColorValueForThemeWorklet(DEFAULT_BACKGROUND_COLOR, isDarkMode); | ||
| if (!_WORKLET || IS_TEST) return initialColors.top; |
There was a problem hiding this comment.
When can it happen that this is not run as worklet?
`@react-native/metro-config` is a build-time tool for configuring Metro, not a runtime dependency. It was originally added to `dependencies` during the RN 0.72 upgrade in #4955 (Feb 2023). When we upgraded to RN 0.79 in #6607 (Aug 2025), the correct `0.79.0` version was added to `devDependencies`, but the old `0.74.83` entry in `dependencies` was left behind. This change drops the stale entry. The `0.79.0` version in `devDependencies` is unchanged. No lockfile impact since yarn was already resolving via the devDeps entry. Ref FEPLAT-34.
After bumping `@react-native-firebase/*` from 20.1.0 to 23.8.8 in #7319 (Apr 2026), iOS users see both a system banner AND a notifee-displayed local notification when a push arrives while the app is foregrounded. Pre-bump behavior was the notifee notification only. The cause is upstream: invertase/react-native-firebase#8786 (merged Feb 2026, shipped in v23.8.5) reordered RNFB's iOS `willPresent` delegate so the original AppDelegate handler is called first. Previously, RNFB consumed the one-shot `completionHandler` with its own default options (empty, since we don't have a `firebase.json`) before forwarding to AppDelegate, making AppDelegate's `completionHandler([.sound, .badge, .list, .banner])` a no-op. With the new order, AppDelegate wins and iOS now honors the full `[.sound, .badge, .list, .banner]` set the handler has been quietly asking for since #6607 (Aug 2025). This change updates AppDelegate's `willPresent` to call `completionHandler([])`, which suppresses all iOS-side presentation for the FCM remote when foregrounded. Rainbow's user-visible foreground notification UI is rendered by notifee from the separate `onMessage` JS handler (`src/notifications/foregroundHandler.ts` → `notifee.displayNotification`). Letting iOS also present the FCM payload would duplicate Notification Center entries and add badge increments that pre-bump prod never had. Returning `[]` matches the pre-RNFB-23.8.5 default of `UNNotificationPresentationOptionNone`. Background and killed-app notifications are unaffected since this delegate only runs in the foreground case.


Fixes APP-####
What changed (plus any additional context for devs)
Here's a summary of the changes:
Screen recordings / screenshots
What to test
Everything 😅