-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Fix LHN display issue for money request via scan #25906
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
Changes from all commits
8eb68aa
958b1ca
c735418
07e3ad8
cc6965e
84ce15f
1c6bb4d
69b1700
455d19e
df24a10
2e8059f
ac7d58a
4a4fbcd
a772a35
bca8116
f018b21
1392317
59630d6
73bdde1
03e4b3f
2b99c3c
b3f15ba
41e35b6
d9e57a7
cb294a2
5568850
5546081
ebad276
f652ef5
4811977
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,6 +12,9 @@ import withCurrentReportID, {withCurrentReportIDPropTypes, withCurrentReportIDDe | |
| import OptionRowLHN, {propTypes as basePropTypes, defaultProps as baseDefaultProps} from './OptionRowLHN'; | ||
| import * as Report from '../../libs/actions/Report'; | ||
| import * as UserUtils from '../../libs/UserUtils'; | ||
| import * as ReportActionsUtils from '../../libs/ReportActionsUtils'; | ||
| import * as TransactionUtils from '../../libs/TransactionUtils'; | ||
|
|
||
| import participantPropTypes from '../participantPropTypes'; | ||
| import CONST from '../../CONST'; | ||
| import reportActionPropTypes from '../../pages/home/report/reportActionPropTypes'; | ||
|
|
@@ -75,6 +78,7 @@ function OptionRowLHNData({ | |
| preferredLocale, | ||
| comment, | ||
| policies, | ||
| receiptTransactions, | ||
| parentReportActions, | ||
| ...propsToForward | ||
| }) { | ||
|
|
@@ -88,6 +92,14 @@ function OptionRowLHNData({ | |
| const parentReportAction = parentReportActions[fullReport.parentReportActionID]; | ||
|
|
||
| const optionItemRef = useRef(); | ||
|
|
||
| const linkedTransaction = useMemo(() => { | ||
| const sortedReportActions = ReportActionsUtils.getSortedReportActionsForDisplay(reportActions); | ||
| const lastReportAction = _.first(sortedReportActions); | ||
| return TransactionUtils.getLinkedTransaction(lastReportAction); | ||
| // eslint-disable-next-line react-hooks/exhaustive-deps | ||
| }, [fullReport.reportID, receiptTransactions, reportActions]); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So that when the status of transaction updates (from scanning to scanned), the LHN is updated too
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did you mean to ask this in this context? #25906 (comment)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it depends on the size of the object you are deep comparing and the component that has to be re-rendered. If the deep comparison object is small, like in this case, I think it's a negligible performance issue.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry yes. Let's take this there! |
||
|
|
||
| const optionItem = useMemo(() => { | ||
| // Note: ideally we'd have this as a dependent selector in onyx! | ||
| const item = SidebarUtils.getOptionData(fullReport, reportActions, personalDetails, preferredLocale, policy); | ||
|
|
@@ -98,7 +110,7 @@ function OptionRowLHNData({ | |
| return item; | ||
| // Listen parentReportAction to update title of thread report when parentReportAction changed | ||
| // eslint-disable-next-line react-hooks/exhaustive-deps | ||
| }, [fullReport, reportActions, personalDetails, preferredLocale, policy, parentReportAction]); | ||
| }, [fullReport, linkedTransaction, reportActions, personalDetails, preferredLocale, policy, parentReportAction]); | ||
|
|
||
| useEffect(() => { | ||
| if (!optionItem || optionItem.hasDraftComment || !comment || comment.length <= 0 || isFocused) { | ||
|
|
@@ -186,6 +198,11 @@ export default React.memo( | |
| key: ({fullReport}) => `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${fullReport.parentReportID}`, | ||
| canEvict: false, | ||
| }, | ||
| // Ideally, we aim to access only the last transaction for the current report by listening to changes in reportActions. | ||
| // In some scenarios, a transaction might be created after reportActions have been modified. | ||
| // This can lead to situations where `lastTransaction` doesn't update and retains the previous value. | ||
| // However, performance overhead of this is minimized by using memos inside the component. | ||
| receiptTransactions: {key: ONYXKEYS.COLLECTION.TRANSACTION}, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure that it was fully realized, but this means that every option in the LHN is connected to the entire transaction collection. That means that when any transaction is updated, every single option in the LHN is re-rendered. That seems like it's bad for performance.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. bump @ygshbht and @luacmartins
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @tgolen Yes, that results in additional renders. However, I don't perceive it as a significant performance issue as transaction updates are infrequent and memoization is implemented within the component. But indeed, there's room for improvement. What specific optimizations do you propose?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, I don't really fully understand that comment. Some of the questions I have are:
It seems like if the root problem for that was fixed, then there wouldn't be a need for this workaround.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
OK, so it's getting the transactionID like this
I don't think that matters. As long as you have the I imagine the code should look more like this:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @tgolen What you say makes sense. But I'm not sure how Onyx works in detail. From what i remember this approach didn't work for me. If it does for you, the change can be implemented. If you test, please also check if the LHN is updated when the status of transaction is completed (i.e to scanned or scan failed). If i recall correclty, many times, the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There isn't anything magical about how Onyx works (I know because I wrote a lot of it and there are many many engineers better than me out there). So, I think it's just running with something like what I've posted and debugging it until it works. Or also, maybe you uncover some bugs, which is great too! We all learn through this. That's better than leaving a workaround like this in the code which could have a big performance impact. When it's all said and done though, it sounds like we're having a discussion about completely refactoring this component to not have any
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are right. Honestly, I'm very curious to know what the actual issue is here. My apologies if it appears to be a workaround. I did not see it as such; it was merely the best I could do and provided the explanation for the same |
||
| }), | ||
| )(OptionRowLHNData), | ||
| ); | ||


Uh oh!
There was an error while loading. Please reload this page.