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

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] 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

[melvin-bot]

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

[Krishna2323]

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.

App/src/stories/Form.stories.tsx

Lines 53 to 54 in d4eaf4e

	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]

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

[melvin-bot]

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

[tychoprice]

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]

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.

2. 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]

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]

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

[Krishna2323]

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

@Krishna2323 waitForNavigateis only effective when accompanied by singleExecution.

Let's see the detail implementation of useWaitForNavigation hook

App/src/hooks/useWaitForNavigation.ts

Lines 28 to 31 in 22bd9eb

	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]

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

[dukenv0307]

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

[tienifr]

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

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

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

PR ready for review #38659.

[melvin-bot]

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

[melvin-bot]

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:

• Fix: No navigation object in state picker story #38659

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

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

• @tienifr requires payment automatic offer (Contributor)
• @dukenv0307 requires payment automatic offer (Reviewer)

[melvin-bot]

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]

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

[anmurali]

@dukenv0307 and @tienifr have been paid.