-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
[Navigator] add optional callbacks to routing functions #1308
Conversation
This might be confusing because the callbacks will resolve before the animation completes in the case of Could you use the willFocus/didFocus API for this? |
is the reason that it resolves before the animation completes for push because |
Ok, I see what you mean. This API does sound useful, even though we haven't needed it internally yet. If you look at |
fantastic! i'll patch it up with the transitionTo callback. I have no idea how to write tests for this. suggestions? |
Right now we're totally lacking tests for navigator, partially because it can be tricky to mock out the animations. I'm going to add some tests in the next week or two, and I can also add a few tests for the callbacks. |
I think we want willLoseFocus and didLoseFocus lifecycle events, or something of that nature. Worth looking at UIViewController's transition API (it's complex...) and Android fragments to get a sense of what events a scene might want to receive and when those events should be fired. |
@ericvicenti made the @ide Those lifecycle hooks sound super useful. I'd be happy to help with those as well, though I don't have any experience with UIViewController or Android fragments, and I'm not super in tune with what the long term goals of this project are as they pertain to android. |
@facebook-github-bot import I'll test this manually for now and get it merged this week. Meanwhile, if you want to get going on the tests, I can point you in the right direction tomorrow. |
var destIndex = this._getDestIndexWithinBounds(n); | ||
var requestTransitionAndResetUpdatingRange = () => { | ||
this._enableScene(destIndex); | ||
this._transitionTo(destIndex); | ||
this._transitionTo(destIndex, cb); |
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.
cb
is the fourth argument in _transitionTo
, so I don't think this will 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.
good call. updated.
Sorry for the delay here. I've been talking with @ide and have had a change of heart: instead of having callbacks on all of these actions, we could add focus lifecycle events that get called on the scenes:
I think these lifecycle methods will be more versatile than callbacks on the actions. Thoughts? |
Here are the specifics as a strawman:
|
Add comma and space
Summary: **Context** On Core RN, Hermes for iOS can be enabled by setting a flag in the Podfile https://reactnative.dev/docs/hermes#ios | Since React Native 0.64, Hermes also runs on iOS. To enable Hermes for iOS, edit your ios/Podfile file and make the change illustrated below: ``` use_react_native!( :path => config[:reactNativePath], # to enable hermes on iOS, change `false` to `true` and then install pods # By default, Hermes is disabled on Old Architecture, and enabled on New Architecture. # You can enable/disable it manually by replacing `flags[:hermes_enabled]` with `true` or `false`. :hermes_enabled => true ) ``` In the RNTester Podfile, Hermes is enabled using envvar: https://github.com/facebook/react-native/blob/main/packages/rn-tester/Podfile#L27 ``` # Hermes is now enabled by default. # The following line will only disable Hermes if the USE_HERMES envvar is SET to a value other than 1 (e.g. USE_HERMES=0). hermes_enabled = !ENV.has_key?('USE_HERMES') || ENV['USE_HERMES'] == '1' ``` Build command: `USE_HERMES=1 bundle exec pod install` This will install the Hermes runtime Pod (not build it from scratch) & thus enable the `RCT_USE_HERMES` macro. https://www.internalfb.com/code/fbsource/[9f57823a75a40d3f8559c8f1b7ae0add8e95d6dc]/xplat/js/react-native-github/packages/rn-tester/RNTester/AppDelegate.mm?lines=10-16 --- The documentation for enabling Hermes on RN Desktop macOS are outdated: https://microsoft.github.io/react-native-windows/docs/hermes#hermes-on-macos > Install the npm package yarn add 'hermes-engine-darwin@^0.4.3' * `hermes-engine-darwin` is no longer required > Add (or uncomment) the following pod dependencies to your macOS target in your Podfile: pod 'React-Core/Hermes', :path => '../node_modules/react-native-macos/' pod 'hermes', :path => '../node_modules/hermes-engine-darwin' pod 'libevent', :podspec => '../node_modules/react-native-macos/third-party-podspecs/libevent.podspec' * Setting `USE_HERMES=1` during `pod install= replaces all of this > Copy Run pod install Be sure to set your target's deployment target to at least 10.14 before running pod install * `USE_HERMES=1 bundle exec pod install --verbose` --- On RN Desktop, the Hermes flag was [set to false](microsoft#780) due to M1 build reasons which have since been resolved. - microsoft#952 - microsoft#781 Curiously, the `RNTester-macOS` target AppDelegate was never updated to import & use Hermes when `RCT_USE_HERMES` was `true`. Only the `RNTester` for mobile had the correct Hermes usage. **RNTester-macOS:** https://github.com/microsoft/react-native-macos/blob/main/packages/rn-tester/RNTester-macOS/AppDelegate.mm **RNTester:** https://github.com/microsoft/react-native-macos/blob/main/packages/rn-tester/RNTester/AppDelegate.mm **Change** * Remove `pods(:hermes_enabled => true)` in favor of passing `USE_HERMES=1` to `pod install` (This is how it's done on RNTester iOS) * Copy Hermes support to `RNTester-macOS` AppDelegate Test Plan: **Install from scratch** Differential Revision: https://phabricator.intern.facebook.com/D38277077 Co-authored-by: Shawn Dempsey <shawndempsey@fb.com>
No description provided.