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

Refactor OpenReport API call for Report GetHistory #10164

Merged
merged 33 commits into from
Aug 18, 2022

Conversation

sketchydroide
Copy link
Contributor

@sketchydroide sketchydroide commented Aug 1, 2022

CC @marcaaron @Beamanator

Fixed Issues

https://github.com/Expensify/Expensify/issues/212870

Tests

This needs to be tested along with the Web PR https://github.com/Expensify/Web-Expensify/pull/34429 (now merged)

  1. Make sure to have a chat with a few messages, I would say around the 100, that you already have opened before.
  2. Open the app and head to the chat in question
  3. Verify that it loads the report and shows the messages. Verify as well that no loader is shown

  1. Make sure to have a third chat with a less than 50 messages, I would say around the 30, that you already have opened before.
  2. Open the app and head to the chat in question
  3. Verify that it loads the report and shows the messages. Verify as well that no loader is shown

  1. Make sure to have a second chat with around the same amount of messages, that you already have NOT opened before.
  2. Open the app and head to the chat in question
  3. Verify a loader is shown
  4. Verify that after the report is loaded the report appears and shows the messages.

  • Verify that no errors appear in the JS console

PR Review Checklist

Contributor (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 tagging the marketing team 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 */
    • Any functional components have the displayName property
    • 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 Contributor+ 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 verified tests pass on all platforms & I tested again 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 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 tagging the marketing team 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 */
    • Any functional components have the displayName property
    • 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.

QA Steps

  • Verify that no errors appear in the JS console

Screenshots

Web

Mobile Web

Desktop

iOS

Android

@sketchydroide sketchydroide requested a review from a team as a code owner August 1, 2022 15:53
@sketchydroide sketchydroide self-assigned this Aug 1, 2022
@melvin-bot melvin-bot bot requested review from tgolen and removed request for a team August 1, 2022 15:53
unreadActionCount: 0,
}
};
// only show loading state if the report has not been open yet
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems like something the view should handle. We can still set the loading state. The view will decide to use it or not based on whether it has initial report actions to display.

src/pages/home/report/ReportActionsView.js Outdated Show resolved Hide resolved
src/pages/home/report/ReportActionsView.js Show resolved Hide resolved
Copy link
Contributor

@tgolen tgolen left a comment

Choose a reason for hiding this comment

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

@sketchydroide Would you mind adding a better title and description to this PR? I am looking at it with very little context from the original issue and I'm confused about what exactly this PR is meant to be doing. The issue is long, it mentions several different pieces, so I'm missing the context of the changes. It also needs QA tests to be added.

@sketchydroide sketchydroide changed the title Report GetHistory OpenReport [WIP] Report GetHistory OpenReport Aug 1, 2022
@sketchydroide
Copy link
Contributor Author

Sorry @tgolen this is still WIP, I always forget that this Repo adds a reviewer as soon as I create it

I will add all the things, also I'll improve the title

@sketchydroide sketchydroide changed the title [WIP] Report GetHistory OpenReport [WIP] Refactor OpenReport API call for Report GetHistory Aug 1, 2022
@tgolen
Copy link
Contributor

tgolen commented Aug 1, 2022

OK, thanks! Creating the PR in draft mode is a good practice where you can avoid that issue. 👍

@sketchydroide sketchydroide marked this pull request as draft August 2, 2022 12:43
@@ -163,7 +163,8 @@ class ReportScreen extends React.Component {
* @returns {Boolean}
*/
shouldShowLoader() {
return !getReportID(this.props.route) || (_.isEmpty(this.props.reportActions) && this.props.isLoadingInitialReportActions);
const isLoadingInitialReportActions = _.isEmpty(this.props.reportActions) && this.props.isLoadingReportActions;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@marc suggested this and I agreed, this makes it easier to understand the purpose of the check

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please update the method description in the JSDocs to be more clear? It is answering "what", but not "why"

Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this really be more like isLoadingReportActions? It doesn't look like it has anything to do with "initial" actions or not. I'm not even sure what "initial" implies.

Copy link
Contributor

Choose a reason for hiding this comment

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

"initial" means you have no reportActions at all to display vs. having some reportActions to display, but still in the process of loading the next set of actions ones. There are two different animations displayed based on which situation we have.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

are you happy with that @tgolen or do you want me to rename the var?

Copy link
Contributor

Choose a reason for hiding this comment

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

I really like Marc's explanation. Could you add that as a code comment to help explain it to others who will see this? If the comment is added, then I think the name is OK then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a shorter version of Marcs answer, that I feel makes more sense to read, let me know if that works.

@marcaaron
Copy link
Contributor

Code is looking good. So, we just need QA tests added now?

# Conflicts:
#	src/pages/home/ReportScreen.js
@sketchydroide sketchydroide marked this pull request as ready for review August 9, 2022 11:42
# Conflicts:
#	src/pages/home/ReportScreen.js
@sketchydroide sketchydroide changed the title [WIP] Refactor OpenReport API call for Report GetHistory Refactor OpenReport API call for Report GetHistory Aug 9, 2022
Onyx.set(`${ONYXKEYS.COLLECTION.IS_LOADING_INITIAL_REPORT_ACTIONS}${reportID}`, true);
fetchActions(reportID)
.finally(() => Onyx.set(`${ONYXKEYS.COLLECTION.IS_LOADING_INITIAL_REPORT_ACTIONS}${reportID}`, false));
fetchActions(reportID);
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that this is all this method does, could you please just remove the method fetchInitialActions() and call fetchActions() directly?

Copy link
Contributor

Choose a reason for hiding this comment

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

Just a note that it's going to be removed entirely in the next round of PRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can still replace it though, it's not that much work I think

@@ -1016,26 +1026,32 @@ function openReport(reportID) {
* @param {Number} oldestActionSequenceNumber
*/
function readOldestAction(reportID, oldestActionSequenceNumber) {
API.read('ReadOldestAction',
API.write('ReadOldestAction',
Copy link
Contributor

Choose a reason for hiding this comment

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

NAB hahaha... we're writeing an action called Read? That doesn't make a whole lot of sense. The API command should probably be something more like MarkOldestActionAsRead

Copy link
Contributor

Choose a reason for hiding this comment

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

If this is a NAB - I prefer the current name and think it's OK. The alternative suggestion confuses me a bit because I am imagining the user manually marking something (and this is something that happens as a side-effect of the user reading something with their eyes and not "reading data from the server").

Copy link
Contributor

Choose a reason for hiding this comment

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

(and this is something that happens as a side-effect of the user reading something with their eyes and not "reading data from the server").

+1 - Since the action is the "reading" I think it's fine, but maybe we could go with ViewOldestAction so we don't use the term "read"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

😅 I think this is still a read, and I just changed the wrong method, I meant to change OpenReport to Write

@@ -453,13 +421,4 @@ export default compose(
withDrawerState,
withLocalize,
withNetwork(),
withOnyx({
Copy link
Contributor

Choose a reason for hiding this comment

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

How does the component get this.props.report now without using withOnyx()?

Copy link
Contributor

Choose a reason for hiding this comment

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

from the parent component here:

<ReportActionsView
reportID={reportID}
reportActions={this.props.reportActions}
report={this.props.report}

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, Thanks! I don't think we should pass both the reportID and report. Those are redundant. Let's just pass report and get the reportID off that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can do that, but reportID at the moment is required not sure if we should make the report required as well, not sure if we should have a default value for reportID

Copy link
Contributor

Choose a reason for hiding this comment

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

This sounds like an easy change and a good thing to look into. I also think it would be OK to do in a follow up and not add additional refactoring scope to these changes. I don't immediately see a clear reason for passing the reportID and report as separate props, but I haven't looked into it deeply enough to say there isn't one.

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 should make report the required prop then, but as always, make sure you take a look at the code and understand it first before making a change like that.

I won't fight tooth-and-nail about it being done in this PR, but I also think this is a refactor PR and I am not too concerned about scope for something small like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

just made the change and tested it after, seems to work great, let me know if you are happy with that @tgolen

@marcaaron
Copy link
Contributor

@sketchydroide I think this still needs to be on HOLD as the Web-E PR has been merged but not yet deployed.

@marcaaron marcaaron changed the title Refactor OpenReport API call for Report GetHistory [HOLD Web-E Production Deploy 34429] Refactor OpenReport API call for Report GetHistory Aug 15, 2022
@@ -1049,21 +1049,35 @@ function deleteReportComment(reportID, reportAction) {
* @param {Number} reportID
*/
function openReport(reportID) {
const sequenceNumber = getMaxSequenceNumber(reportID);
API.write('OpenReport',
API.read('OpenReport',
Copy link
Contributor

Choose a reason for hiding this comment

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

Please make this a write()

marcaaron
marcaaron previously approved these changes Aug 16, 2022
Copy link
Contributor

@marcaaron marcaaron left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks for the changes. We still need to wait for this Web-Expensify PR to go to production before merging.

@marcaaron marcaaron changed the title [HOLD Web-E Production Deploy 34429] Refactor OpenReport API call for Report GetHistory Refactor OpenReport API call for Report GetHistory Aug 16, 2022
@marcaaron marcaaron requested a review from tgolen August 16, 2022 20:12
@marcaaron
Copy link
Contributor

Web-E PR is now on production.

Copy link
Contributor

@tgolen tgolen left a comment

Choose a reason for hiding this comment

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

Looks great now! Just this one last small change I noticed

src/pages/home/report/ReportActionsView.js Outdated Show resolved Hide resolved
Co-authored-by: Tim Golen <tgolen@gmail.com>
@marcaaron marcaaron requested a review from tgolen August 17, 2022 17:28
@sketchydroide
Copy link
Contributor Author

the tests seems to be failing but it does not seem related to the last commit

@sketchydroide
Copy link
Contributor Author

merging main seems o have fixed it

@sketchydroide
Copy link
Contributor Author

@Beamanator is OOO, but his comments were addresed, so I think we are good

@tgolen tgolen merged commit a4c70a6 into main Aug 18, 2022
@tgolen tgolen deleted the afonseca_get_history_open_report branch August 18, 2022 15:29
@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 @tgolen in version: 1.1.89-0 🚀

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

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