-
Notifications
You must be signed in to change notification settings - Fork 2.7k
RN 77 Upgrade #8018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feat/rn77-android-newarch
Are you sure you want to change the base?
RN 77 Upgrade #8018
Conversation
…dCommandCompletionWithPushedComponentId
…nt lifecycle methods for new architecture
# Conflicts: # package-lock.json # scripts/start.js
* Implemented turbo modules for android * Implemented missing method * Complete Android Turbo module implementation * Complete Android Turbo module implementation * Undo some unneeded fixes * Fixed build on ios
This reverts commit 497ebd6.
* WIP * Update package-lock.json * Fixed ios build * Fixed unit tests * Fixed ios build * Fixed ios build * Revert "Fixed ios build" This reverts commit 3dbd98a. * Fixed ios build * fix tests for ios * Fixed eslint * DO NOT RELEASE THIS COMMIT! * Revert "DO NOT RELEASE THIS COMMIT!" This reverts commit b0e840e. * Fixed build for ios 77
The problem was that when setting a titleView of a navigationItem the normal life cycle flow of a view will not be called so the RNNReactView componentWillAppear and DidAppear need to be implicitly called. This was somehow removed from the TopBarTitlePresenter.mm unit but is present on the current Master branch's file. This PR restores those two lines and also actives the Unit test for that module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR upgrades the React Native Navigation module in preparation for RN 77, introducing a new TurboModule and updating module registration, test timing, native build settings, and linting configurations.
- Add NavigationTurboModule implementation for TurboModules.
- Update NavigationPackage to register the TurboModule and adjust module info.
- Refactor end-to-end tests and adjust podspec and ESLint configurations.
Reviewed Changes
Copilot reviewed 359 out of 365 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
lib/android/app/src/main/java/com/reactnativenavigation/react/NavigationTurboModule.kt | New TurboModule implementation with lifecycle handling and navigation command support. |
lib/android/app/src/main/java/com/reactnativenavigation/react/NavigationPackage.kt | Updated registration to include the TurboModule and new module info provider. |
index.e2e.js | Minor import and LogBox setup adjustments. |
e2e/StaticLifecycleEvents.test.js | Removed an outdated expectation for static lifecycle events. |
e2e/Stack.test.js | Improved test stability with waitFor timeouts. |
e2e/Modals.test.js | Updated modal test assertions to use waitFor with timeouts. |
ReactNativeNavigation.podspec | Upgraded C++ standard and adjusted dependencies and compiler flags. |
.eslintrc.js | Updated ESLint extend configuration for React Native. |
Files not reviewed (6)
- autolink/postlink/snapshots/appDelegateLinker.test.js.snap: Language not supported
- lib/android/app/build.gradle: Language not supported
- lib/android/build.gradle: Language not supported
- lib/ios/AnimatedImageView.mm: Language not supported
- lib/ios/AnimatedReactView.mm: Language not supported
- lib/ios/AnimatedTextView.mm: Language not supported
Comments suppressed due to low confidence (1)
lib/android/app/src/main/java/com/reactnativenavigation/react/NavigationPackage.kt:30
- [nitpick] Consider using the fully qualified class name (e.g. NavigationTurboModule::class.java.name) for the className field in ReactModuleInfo for improved clarity and consistency.
className = NavigationTurboModule.NAME,
) { | ||
handle { | ||
val _children = ArrayList<ViewController<*>>() | ||
for (i in 0..<children.size()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The '0..<children.size()' syntax is not a standard Kotlin range operator; consider replacing it with '0 until children.size()' to ensure correct iteration.
for (i in 0..<children.size()) { | |
for (i in 0 until children.size()) { |
Copilot uses AI. Check for mistakes.
@@ -24,7 +45,6 @@ - (void)layoutSubviews { | |||
|
|||
- (void)reset { | |||
[super reset]; | |||
_fromTextContainer.size = _fromSize; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it not necessary to reset the _fromTextContainer size?
@@ -89,7 +90,7 @@ - (void)setRoot:(NSDictionary *)layout | |||
[_layoutManager addPendingViewController:vc]; | |||
|
|||
RNNNavigationOptions *optionsWithDefault = vc.resolveOptionsWithDefault; | |||
vc.waitForRender = [optionsWithDefault.animations.setRoot.waitForRender withDefault:NO]; | |||
vc.waitForRender = [optionsWithDefault.animations.setRoot.waitForRender withDefault: [RNNUtils getDefaultWaitForRender]]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In all the parts where the [... withDefault: NO] is replaced with [RNNUtils getDefaultWaitForRender], what is the reason for this?
@@ -77,10 +77,6 @@ - (void)render { | |||
[self renderReactViewIfNeeded]; | |||
} | |||
|
|||
- (void)destroyReactView { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain to me why there is no need to invalidate the reactView?
@@ -53,6 +53,11 @@ - (NSString *)alignment { | |||
return _alignment ? _alignment : @"center"; | |||
} | |||
|
|||
#ifdef RCT_NEW_ARCH_ENABLED | |||
- (void)surface:(RCTSurface *)surface didChangeIntrinsicSize:(CGSize)intrinsicSize { | |||
// TODO: FILL WITH DATA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part is still a TODO
@@ -2,6 +2,14 @@ | |||
|
|||
@implementation RNNUtils | |||
|
|||
+ (BOOL)getDefaultWaitForRender { | |||
#ifdef RCT_NEW_ARCH_ENABLED | |||
return YES; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to return YES for NEW_ARCH?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kochavi-daniel , I left some comments to get to know the code better and the reasoning behind it.
@@ -10,7 +10,6 @@ describe('static lifecycle events', () => { | |||
await elementById(TestIDs.SHOW_STATIC_EVENTS_SCREEN).tap(); | |||
await elementById(TestIDs.STATIC_EVENTS_OVERLAY_BTN).tap(); | |||
await expect(elementByLabel('Static Lifecycle Events Overlay')).toBeVisible(); | |||
await expect(elementByLabel('componentWillAppear | EventsOverlay | Component')).toBeVisible(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you remove it?
}) | ||
.then((popId) => new Promise<string>((resolve) => setTimeout(() => resolve(popId), 500))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we have a timeout here? Is it a problem with detox?
Navigation.dismissAllModals(); | ||
setRoot(); | ||
}); | ||
Navigation.dismissAllModals(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't feel right? Does this callback work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this class? Can we remove it?
@@ -54,7 +55,7 @@ - (BOOL)hasValue { | |||
} | |||
|
|||
- (BOOL)shouldWaitForRender { | |||
return [self.waitForRender withDefault:NO] || self.hasAnimation; | |||
return [self.waitForRender withDefault:[RNNUtils getDefaultWaitForRender]] || self.hasAnimation; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did it changed for no to yes?
self.widthConstraint.constant = intrinsicSize.width; | ||
self.heightConstraint.constant = intrinsicSize.height; | ||
[surface setSize:intrinsicSize]; | ||
//[rootView setNeedsUpdateConstraints]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need it? what it does?
|
||
+ (NSArray<id<RCTBridgeModule>> *)extraModulesForBridge:(RCTBridge *)bridge; | ||
|
||
+ (RCTBridge *)getBridge; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need it anymore
|
||
+ (void)bootstrapWithDelegate:(id<RCTBridgeDelegate>)bridgeDelegate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need something similar for host
No description provided.