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

Create HOC for get report data or navigate to home #12089

Merged
merged 3 commits into from
Oct 28, 2022

Conversation

mollfpr
Copy link
Contributor

@mollfpr mollfpr commented Oct 24, 2022

Details

The issue occurred when the report from Onyx return undefined on ReportDetailsPage, ReportParticipantsPageandReportSettingsPage.

Fixed Issues

$ #11982
$ #11982 (comment)

Tests

  1. Navigate to a room, open the details page or participants page, or settings page
  2. Copy the URL
  3. Open another account that doesn't have access to that room
  4. Go to the URL from step 2
  5. Verified that the page (details, participants, or settings page) modal dismisses and shows the current account chat
  • Verify that no errors appear in the JS console

QA Steps

  1. Navigate to a room, open the details page or participants page, or settings page
  2. Copy the URL
  3. Open another account that doesn't have access to that room
  4. Go to the URL from step 2
  5. Verified that the page (details, participants, or settings page) modal dismisses and shows the current account chat
  • Verify that no errors appear in the JS console

PR Review Checklist

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist

The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots

Web

Fix.Report.Undefined.Crash.Web.mov

Mobile Web - Chrome

Fix.Report.Undefined.Crash.mWeb-Chrome.mov

Mobile Web - Safari

Fix.Report.Undefined.Crash.mWeb-Safari.mov

Desktop

Fix.Report.Undefined.Crash.Desktop.mov

iOS

Fix.Report.Undefined.Crash.iOS.mov

Android

Fix.Report.Undefined.Crash.Android.mov

@mollfpr mollfpr requested a review from a team as a code owner October 24, 2022 15:26
@melvin-bot melvin-bot bot requested review from Beamanator and mananjadhav and removed request for a team October 24, 2022 15:26
@mananjadhav
Copy link
Collaborator

mananjadhav commented Oct 25, 2022

@mollfpr I am getting a console error when the I hit the URL. Can you please check this?

image

--

Please note I'll be available for limited hours this week, and expect delayed responses.

@mollfpr
Copy link
Contributor Author

mollfpr commented Oct 26, 2022

@mananjadhav I just update the HOC component to use the class component and move the navigation redirect to componentDidMount. I also add a fix after redirection if the report.participants not yet loaded and throwing error page.

@mananjadhav
Copy link
Collaborator

Thanks for the changes @mollfpr I am going to review and test this by tomorrow.

Copy link
Collaborator

@mananjadhav mananjadhav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes @mollfpr. This PR is looking good, and tests well.

@Beamanator All yours.

🎀 👀 🎀 
C+ reviewed

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots

Web

web-room-crash.mov

web-invalid-room-crash

Mobile Web - Chrome

mweb-chrome-room-crash.mov

Mobile Web - Safari

mweb-safari-room-crash.mov
mweb-safari-invalid-room.mov

Desktop

desktop-room-crash.mov

iOS

ios-room-crash.mov

Android

android-room-crash.mov

@Beamanator
Copy link
Contributor

Beamanator commented Oct 28, 2022

FYI @mananjadhav it looks like your checklist is a bit outdated, I see these changed lines:

// Required in the checklist:
- [ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the `Waiting for Copy` label for a copy review on the original GH to get the correct copy.

// In your checklist:
- [ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.

Copy link
Contributor

@Beamanator Beamanator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@Beamanator
Copy link
Contributor

Code looks good to me! @mananjadhav can you try fixing your PR review checklist then we'll see if the final test passes? 👍

@mananjadhav
Copy link
Collaborator

@Beamanator Thanks for pointing that out. I've updated the checklist and all checks are passing now.

@Beamanator Beamanator merged commit 7f70c1d into Expensify:main Oct 28, 2022
@melvin-bot melvin-bot bot added the Emergency label Oct 28, 2022
@melvin-bot
Copy link

melvin-bot bot commented Oct 28, 2022

@Beamanator looks like this was merged without the checklist test passing. Please add a note explaining why this was done and remove the Emergency label if this is not an emergency.

@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @Beamanator in version: 1.2.22-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 failure ❌
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

OSBotify commented Nov 2, 2022

🚀 Deployed to production by @Julesssss in version: 1.2.22-3 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

report: {},
};

class WithReportOrNavigateHome extends Component {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch, did we really need an HOC for this? Very confused about what purpose this even serves. @Beamanator would you mind summarizing why we need this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is your question "Why a HOC for this functionality" or "What is the point of the code in this HOC"? Will happily respond to either one tomorrow (end of my day & brain is foggy from timezone shifting)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes to both.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"What is the point of the code in this HOC" should be pretty straightforward: If the user is on a page that needs report data (from Onyx), we check if this.props.report is empty or not. If it's empty, we dismiss the open modal (this is what we were calling "navigate home" though that's not really accurate since we don't have a "home" screen...). If it's not empty, we show that page.

"Why a HOC for this functionality": We wanted to use this functionality across multiple pages, so thought it was clean to put it in an HOC. This lets us not have to subscribe to ${ONYXKEYS.COLLECTION.REPORT}${route.params.reportID}, on multiple pages, and instead we just wrap the page with this new HOC. We could do the same thing with a new action or lib that we call whenever these pages are mounted, but in my brain an HOC seemed more useful.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks and sorry for my initial reaction. I think we got the main solution for this wrong which is the important thing. I tend to only pull out the HOC when we the code reuse is expected to be very high for a solution. But if you thought we might re-use this then the HOC is certainly one way to do that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we got the main solution for this wrong which is the important thing

I think you're referring to the fact that we aren't actually sure if we want to navigate at this point, right? Like we probably want to see if the user has access to that report or not before navigating away? (this is what our other discussion is about in a different thread, I believe)

I tend to only pull out the HOC when we the code reuse is expected to be very high for a solution. But if you thought we might re-use this then the HOC is certainly one way to do that.

Yeah exactly that was my thought process too, BUT maybe you would have waited till we have a few more use cases for this kind of code before making it a HOC - I'll happily defer to you on this, though I guess the "next steps" probably depend on what the "correct solution" is (again referring to our other discussion - showing a "you don't have accesss" page or navigating somewhere)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we aren't actually sure if we want to navigate at this point, right

Yes. I think there are different possible states of report access and different app states depending on if those reports were previously accessible or not.

Using the existence of the report in storage doesn't tell us whether you have "access" or not especially when you are offline...

Offline and never attempted to fetch a report: No way to really tell if the user has access or not but that's fine the same error message works in this case.
Offline and previous attempt returned 404: Tell them they can't access it i.e. "Hmm... it's not here"
Online and attempt returns 404: Tell them they can't access it i.e. "Hmm... it's not here"

I don't think there is any situation where we'd want to redirect without any explanation (but this deserves a wider discussion to get more input than just me 😅).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants