Refactor OpenReport API call for Report GetHistory#10164
Conversation
| unreadActionCount: 0, | ||
| } | ||
| }; | ||
| // only show loading state if the report has not been open yet |
There was a problem hiding this comment.
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.
tgolen
left a comment
There was a problem hiding this comment.
@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.
|
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 |
|
OK, thanks! Creating the PR in draft mode is a good practice where you can avoid that issue. 👍 |
# Conflicts: # src/pages/home/ReportScreen.js # src/pages/home/report/ReportActionsView.js
| */ | ||
| shouldShowLoader() { | ||
| return !getReportID(this.props.route) || (_.isEmpty(this.props.reportActions) && this.props.isLoadingInitialReportActions); | ||
| const isLoadingInitialReportActions = _.isEmpty(this.props.reportActions) && this.props.isLoadingReportActions; |
There was a problem hiding this comment.
@marc suggested this and I agreed, this makes it easier to understand the purpose of the check
There was a problem hiding this comment.
Can you please update the method description in the JSDocs to be more clear? It is answering "what", but not "why"
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
are you happy with that @tgolen or do you want me to rename the var?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I added a shorter version of Marcs answer, that I feel makes more sense to read, let me know if that works.
|
Code is looking good. So, we just need QA tests added now? |
# Conflicts: # src/pages/home/ReportScreen.js
# Conflicts: # src/pages/home/ReportScreen.js
| 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); |
There was a problem hiding this comment.
Now that this is all this method does, could you please just remove the method fetchInitialActions() and call fetchActions() directly?
There was a problem hiding this comment.
Just a note that it's going to be removed entirely in the next round of PRs.
There was a problem hiding this comment.
I can still replace it though, it's not that much work I think
| */ | ||
| function readOldestAction(reportID, oldestActionSequenceNumber) { | ||
| API.read('ReadOldestAction', | ||
| API.write('ReadOldestAction', |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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").
There was a problem hiding this comment.
(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"
There was a problem hiding this comment.
😅 I think this is still a read, and I just changed the wrong method, I meant to change OpenReport to Write
| withDrawerState, | ||
| withLocalize, | ||
| withNetwork(), | ||
| withOnyx({ |
There was a problem hiding this comment.
How does the component get this.props.report now without using withOnyx()?
There was a problem hiding this comment.
from the parent component here:
App/src/pages/home/ReportScreen.js
Lines 242 to 245 in 972b835
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
just made the change and tested it after, seems to work great, let me know if you are happy with that @tgolen
|
@sketchydroide I think this still needs to be on HOLD as the Web-E PR has been merged but not yet deployed. |
| function openReport(reportID) { | ||
| const sequenceNumber = getMaxSequenceNumber(reportID); | ||
| API.write('OpenReport', | ||
| API.read('OpenReport', |
There was a problem hiding this comment.
Please make this a write()
marcaaron
left a comment
There was a problem hiding this comment.
LGTM! Thanks for the changes. We still need to wait for this Web-Expensify PR to go to production before merging.
|
Web-E PR is now on production. |
tgolen
left a comment
There was a problem hiding this comment.
Looks great now! Just this one last small change I noticed
Co-authored-by: Tim Golen <tgolen@gmail.com>
|
the tests seems to be failing but it does not seem related to the last commit |
|
merging main seems o have fixed it |
|
@Beamanator is OOO, but his comments were addresed, so I think we are good |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
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)
PR Review Checklist
Contributor (PR Author) Checklist
### Fixed Issuessection aboveTestssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*filesSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */displayNamepropertythisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)Avataris modified, I verified thatAvataris working as expected in all cases)PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed
### Fixed Issuessection aboveTestssectionQA stepssectiontoggleReportand notonIconClick).src/languages/*filesSTYLE.md) were followedAvatar, I verified the components usingAvatarhave been tested & I retested again)/** comment above it */displayNamepropertythisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)Avataris modified, I verified thatAvataris working as expected in all cases)QA Steps
Screenshots
Web
Mobile Web
Desktop
iOS
Android