Skip to content
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

[HOLD for payment 2024-04-05] [$500] Storybook - "Couldn't find a navigation object" error when trying to select a year #38331

Closed
1 of 6 tasks
lanitochka17 opened this issue Mar 14, 2024 · 21 comments
Assignees
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Weekly KSv2

Comments

@lanitochka17
Copy link

lanitochka17 commented Mar 14, 2024

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 #37820

Action Performed:

  1. Navigate to https://staging.new.expensify.com/docs/index.html
  2. Click on the "Form" component
  3. Click on the year selector
  4. Navigate to https://staging.new.expensify.com/docs/index.html
  5. Click on the "Form" component
  6. Click on the state selector

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?

  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6413512_1710421119535.bandicam_2024-03-14_13-58-02-469.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~01a13cfaecad01b349
  • Upwork Job ID: 1769863435571646464
  • Last Price Increase: 2024-03-18
  • Automatic offers:
    • dukenv0307 | Reviewer | 0
    • tienifr | Contributor | 0
@lanitochka17 lanitochka17 added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Mar 14, 2024
Copy link

melvin-bot bot commented Mar 14, 2024

Triggered auto assignment to @anmurali (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

@Krishna2323
Copy link
Contributor

Krishna2323 commented Mar 14, 2024

Proposal

Please re-state the problem that we are trying to solve in this issue.

Storybook - "Couldn't find a navigation object" error when trying to select a year

What is the root cause of that problem?

We need to wrap StatePicker & DatePicker with navigation with withNavigationFallback since they use ScreenWrapper & HeaderWithBackButton which uses useWaitForNavigation.

StatePicker,
DatePicker,

What changes do you think we should make in order to solve the problem?

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.

Result

storybook_fix.mp4

Alternative

Wrap StatePicker.tsx & DatePicker.tsx with withNavigationFallback and then export.
Or Wrap ScreenWrapper.tsx & HeaderWithBackButton.tsx with withNavigationFallback and then export.

@melvin-bot melvin-bot bot added the Overdue label Mar 18, 2024
@anmurali anmurali added the External Added to denote the issue can be worked on by a contributor label Mar 18, 2024
@melvin-bot melvin-bot bot changed the title Storybook - "Couldn't find a navigation object" error when trying to select a year [$500] Storybook - "Couldn't find a navigation object" error when trying to select a year Mar 18, 2024
Copy link

melvin-bot bot commented Mar 18, 2024

Job added to Upwork: https://www.upwork.com/jobs/~01a13cfaecad01b349

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Mar 18, 2024
Copy link

melvin-bot bot commented Mar 18, 2024

Triggered auto assignment to Contributor-plus team member for initial proposal review - @dukenv0307 (External)

@melvin-bot melvin-bot bot removed the Overdue label Mar 18, 2024
@anmurali anmurali added Help Wanted Apply this label when an issue is open to proposals by contributors and removed Help Wanted Apply this label when an issue is open to proposals by contributors labels Mar 18, 2024
@tychoprice
Copy link

Proposal

Please re-state the problem that we are trying to solve in this issue.

Remedy the "Couldn't find a navigation object" error when trying to select a year

What is the root cause of that problem?

Components like StatePicker and DatePicker require a navigation context; however, in Storybook, this navigation context is not naturally present.

What changes do you think we should make in order to solve the problem?

Provide navigation context, thus preventing the error when these components try to access navigation-related features.

@tienifr
Copy link
Contributor

tienifr commented Mar 19, 2024

Proposal

Please re-state the problem that we are trying to solve in this issue.

"Couldn't find a navigation object. Is your component inside NavigationContainer?" error when trying to select a year or state.

What is the root cause of that problem?

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.

What changes do you think we should make in order to solve the problem?

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:

  1. Remove the 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 unnecessarily

If 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.

  1. Wrap the ScreenWrapper in withNavigationFallback so it will work well in storybook

What alternative solutions did you explore? (Optional)

Alternate for 2:

  • Refactor to have a GenericScreenWrapper that has all code of ScreenWrapper except for the navigation and the listener.
  • If the props passed into 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.

@dukenv0307
Copy link
Contributor

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

Copy link

melvin-bot bot commented Mar 19, 2024

Triggered auto assignment to @thienlnam, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

@Krishna2323
Copy link
Contributor

@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.

@dukenv0307
Copy link
Contributor

@Krishna2323 waitForNavigateis only effective when accompanied by singleExecution.

Let's see the detail implementation of useWaitForNavigation hook

navigate();
return new Promise<void>((resolve) => {
resolvePromises.current.push(resolve);
});

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

@Krishna2323
Copy link
Contributor

Can you pls explain what do you mean by we don't use singleExecution anymore.

@dukenv0307
Copy link
Contributor

@Krishna2323 We defined it as the prop here. But we don't pass singleExecution in any places

@tienifr
Copy link
Contributor

tienifr commented Mar 19, 2024

@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.

@melvin-bot melvin-bot bot removed the Help Wanted Apply this label when an issue is open to proposals by contributors label Mar 19, 2024
Copy link

melvin-bot bot commented Mar 19, 2024

📣 @dukenv0307 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

Copy link

melvin-bot bot commented Mar 19, 2024

📣 @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 📖

@tienifr
Copy link
Contributor

tienifr commented Mar 20, 2024

PR ready for review #38659.

@melvin-bot melvin-bot bot added Weekly KSv2 Awaiting Payment Auto-added when associated PR is deployed to production and removed Weekly KSv2 labels Mar 29, 2024
@melvin-bot melvin-bot bot changed the title [$500] Storybook - "Couldn't find a navigation object" error when trying to select a year [HOLD for payment 2024-04-05] [$500] Storybook - "Couldn't find a navigation object" error when trying to select a year Mar 29, 2024
Copy link

melvin-bot bot commented Mar 29, 2024

Reviewing label has been removed, please complete the "BugZero Checklist".

@melvin-bot melvin-bot bot removed the Reviewing Has a PR in review label Mar 29, 2024
Copy link

melvin-bot bot commented Mar 29, 2024

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.57-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

If no regressions arise, payment will be issued on 2024-04-05. 🎊

For reference, here are some details about the assignees on this issue:

Copy link

melvin-bot bot commented Mar 29, 2024

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:

  • [@dukenv0307] The PR that introduced the bug has been identified. Link to the PR:
  • [@dukenv0307] 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:
  • [@dukenv0307] 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:
  • [@dukenv0307] Determine if we should create a regression test for this bug.
  • [@dukenv0307] 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.
  • [@anmurali] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

@dukenv0307
Copy link
Contributor

BugZero Checklist:

  • The PR that introduced the bug has been identified. Link to the PR:

N/A

  • 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

  • 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

  • Determine if we should create a regression test for this bug.

We don't need to create a regression test

  • 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

@melvin-bot melvin-bot bot added the Overdue label Apr 12, 2024
@anmurali
Copy link

@dukenv0307 and @tienifr have been paid.

@github-project-automation github-project-automation bot moved this from Polish to Done in [#whatsnext] #wave-collect Apr 17, 2024
@melvin-bot melvin-bot bot removed the Overdue label Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Weekly KSv2
Projects
No open projects
Archived in project
Development

No branches or pull requests

7 participants