Closed lanitochka17 closed 5 months ago
Triggered auto assignment to @anmurali (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Storybook - "Couldn't find a navigation object" error when trying to select a year
We need to wrap StatePicker
& DatePicker
with navigation with withNavigationFallback
since they use ScreenWrapper
& HeaderWithBackButton
which uses useWaitForNavigation
.
https://github.com/Expensify/App/blob/d4eaf4e2deabb6c07736b1eaefaa203cc9cf5850/src/stories/Form.stories.tsx#L53-L54
Wrap StatePicker
& DatePicker
with withNavigationFallback
.
There might be more components which uses navigation and is used in storrybook, we might want to check for that as well.
https://github.com/Expensify/App/assets/85894871/201c137d-d286-43c3-8de0-45e7afb44500
Wrap StatePicker.tsx
& DatePicker.tsx
with withNavigationFallback
and then export.
Or Wrap ScreenWrapper.tsx
& HeaderWithBackButton.tsx
with withNavigationFallback
and then export.
Job added to Upwork: https://www.upwork.com/jobs/~01a13cfaecad01b349
Triggered auto assignment to Contributor-plus team member for initial proposal review - @dukenv0307 (External
)
Remedy the "Couldn't find a navigation object" error when trying to select a year
Components like StatePicker and DatePicker require a navigation context; however, in Storybook, this navigation context is not naturally present.
Provide navigation context, thus preventing the error when these components try to access navigation-related features.
"Couldn't find a navigation object. Is your component inside NavigationContainer?" error when trying to select a year or state.
In CalendarPicker
and StatePicker
, we're using ScreenWrapper
and HeaderWithBackButton
, which internally uses useNavigation
, leading to error thrown when in Storybook, we don't have a navigation context.
Except for the ScreenWrapper
usage, we're not really using navigation for anything in HeaderWithBackButton
component, it's just redundant hooks and declarations.
We need to:
useWaitForNavigation
's usage (and potentially singleExecution
usage as well) in HeaderWithBackButton
here, earlier it was added to avoid triggering navigation twice in WorkspaceInitialPage
(see here), but the WorkspaceInitialPage
has been refactored and no longer have such buttons, so singleExecution
is not passed in HeaderWithBackButton
anywhere in the app, so it's safe to be removed. This will also help speed up the user interaction when pressing the Get assistance
button, because now it will no longer wait for navigation unnecessarilyIf we want to keep this logic, then we should pass waitForNavigate
from outside into HeaderWithBackButton
, and keep HeaderWithBackButton
a dumb component that's unaware of the navigation state.
ScreenWrapper
in withNavigationFallback
so it will work well in storybookAlternate for 2:
GenericScreenWrapper
that has all code of ScreenWrapper
except for the navigation and the listener.ScreenWrapper
indicates the requirement of the navigation (like onEntryTransitionEnd
, its children is a function
, or a boolean prop), we'll return the full ScreenWrapper with navigation events. Otherwise we'll return the GenericScreenWrapper
without navigation/navigation listeners.We should also double check other pages to see if there's any similar problem, and fix similarly.
Let's go with @tienifr's proposal. I love the way he removes useWaitForNavigation
and singleExecution
in HeaderWithBackButton since we don't need them anymore.
πππ C+ reviewed
Triggered auto assignment to @thienlnam, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@dukenv0307, are you sure that the navigation added in HeaderWithBackButton
was only for WorkspaceInitialPage
, HeaderWithBackButton
is used in almost every place and I don't think its safe to remove useWaitForNavigation
and singleExecution
.
@Krishna2323 waitForNavigate
is only effective when accompanied by singleExecution
.
Let's see the detail implementation of useWaitForNavigation
hook
We just exectute navigate
immediately, then return a promise that resolves when navigation finishes. That means
onPress={waitForNavigate(navigate)}
is the same as onPress={navigate}
. The reason we use waitForNavigate within singleExecution is to indicate that the action is executing
But for now, we don't use singleExecution
anymore -> we can safely remove waitForNavigate
Pls let me know if you still have some confused points
Can you pls explain what do you mean by we don't use singleExecution anymore
.
@Krishna2323 We defined it as the prop here. But we don't pass singleExecution
in any places
@Krishna2323 We defined it as the prop here. But we don't pass singleExecution in any places
FYI I've explained the history of that prop pretty clearly in the proposal, singleExecution
is being used in other places, but not in HeaderWithBackButton
, besides, it's delaying the Get assistance
button click unnecessarily
I don't think its safe to remove useWaitForNavigation and singleExecution.
Feel free to highlight if you find any actual downside of removing it.
π£ @dukenv0307 π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @tienifr π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
PR ready for review https://github.com/Expensify/App/pull/38659.
Reviewing
label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 1.4.57-5 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2024-04-05. :confetti_ball:
For reference, here are some details about the assignees on this issue:
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
BugZero Checklist:
- [x] The PR that introduced the bug has been identified. Link to the PR:
N/A
- [x] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
N/A
- [x] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
N/A
- [x] Determine if we should create a regression test for this bug.
We don't need to create a regression test
- [x] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
No
@dukenv0307 and @tienifr have been paid.
If you havenβt already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 1.4.52.0 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: N/A Issue reported by: Applause - Internal Team
Issue found when executing PR https://github.com/Expensify/App/pull/37820
Action Performed:
Expected Result:
I should be able to select a year and state
Actual Result:
"Couldn't find a navigation object. Is your component inside NavigationContainer?" error when trying to select a year or state.
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/78819774/2a260382-aa99-4803-a12e-fa61113902a7
View all open jobs on GitHub
Upwork Automation - Do Not Edit