Expensify / App

Welcome to New Expensify: a complete re-imagination of financial collaboration, centered around chat. Help us build the next generation of Expensify by sharing feedback and contributing to the code.
https://new.expensify.com
MIT License
3.43k stars 2.8k forks source link

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

Closed lanitochka17 closed 5 months ago

lanitochka17 commented 6 months ago

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:

  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?

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
  • 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
melvin-bot[bot] commented 6 months ago

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

Krishna2323 commented 6 months ago

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. https://github.com/Expensify/App/blob/d4eaf4e2deabb6c07736b1eaefaa203cc9cf5850/src/stories/Form.stories.tsx#L53-L54

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

https://github.com/Expensify/App/assets/85894871/201c137d-d286-43c3-8de0-45e7afb44500

Alternative

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

melvin-bot[bot] commented 6 months ago

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

melvin-bot[bot] commented 6 months ago

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

tychoprice commented 6 months ago

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 commented 6 months ago

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:

We should also double check other pages to see if there's any similar problem, and fix similarly.

dukenv0307 commented 6 months ago

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

melvin-bot[bot] commented 6 months ago

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

Krishna2323 commented 6 months ago

@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 commented 6 months ago

@Krishna2323 waitForNavigateis only effective when accompanied by singleExecution.

Let's see the detail implementation of useWaitForNavigation hook

https://github.com/Expensify/App/blob/22bd9eb633f0d378158bc3b8674682fbc39a56ea/src/hooks/useWaitForNavigation.ts#L28-L31

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 commented 6 months ago

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

dukenv0307 commented 6 months ago

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

tienifr commented 6 months ago

@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[bot] commented 6 months ago

πŸ“£ @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

melvin-bot[bot] commented 6 months ago

πŸ“£ @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 commented 6 months ago

PR ready for review https://github.com/Expensify/App/pull/38659.

melvin-bot[bot] commented 6 months ago

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

melvin-bot[bot] commented 6 months ago

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:

melvin-bot[bot] commented 6 months ago

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 commented 6 months ago

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

anmurali commented 5 months ago

@dukenv0307 and @tienifr have been paid.