-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
cleanup: split filtering & ordering in OptionsListUtils #53371
cleanup: split filtering & ordering in OptionsListUtils #53371
Conversation
The current problem is with the max reports number. I currently only splice in the order function. but in the filter function we filter the personal details based on the recent reports. if the recent reports aren't limited in the filter function then then we will have fewer personal details (as more reports have been loaded). however i can't limit the recent reports in filter yet as they aren't ordered yet… we might need to split up getOptions for reports and pD actually
…g in the right moment
cc @ahmedGaber93 since you reviewed all PRs of this cleanup so far 🫶 |
@neil-marcellini Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! It mostly looks good to me. I recognize that it's pretty hard to test such a large refactor like this, but I will add a C+ to stick to our process and have another set of eyes.
I have some questions about the unit tests.
Reviewing and testing today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great refactoring, just small notes
src/libs/OptionsListUtils.ts
Outdated
if (option.private_isArchived) { | ||
return CONST.DATE.UNIX_EPOCH; | ||
} | ||
return option?.lastVisibleActionCreated ?? ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fallback ?? ''
didn't exist before the refactoring, I think this may affect on the ordering because orderBy() places undefined
values at the end of the sorted array, and empty value ''
at the top, you can try it here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed this one! also realized i was missing one other parameter to the ordering which i added now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually i probably have to rewrite this a bit. I think in the original implementation there was kind of a bug. Will explain in detail once fixed …
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so we don't need the additional private_isArchived
, we don't need the additional isSelfDM
check.
The code i have written makes sure to check all of these properties only once (before we were using those options in the multiple order functions, which makes it harder to understand whats happening).
The ?? ''
is actually correct, i added a code comment to better explain it
Reviewer Checklist
Screenshots/VideosAndroid: Nativeaa.mp4Android: mWeb Chromewwaa.mp4iOS: Nativeiiiii.mp4iOS: mWeb Safariwwiii.mp4MacOS: Chrome / Safariphone.number.user.to.invite.mp4phone.number.mp4start.chat.mp4number.mp4user.to.join.mp4you.mp4multi.search.text.mp4search.tab.mp420241205210114123.mp4MacOS: Desktop20241210161849467.mp4 |
00e284f
to
c60f18d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates, all my requested changes from last time were addressed. It all looks good to me except for one test. Let's also please add more test steps with more detail, trying to cover most of the areas that were changed. If we do that it's less likely we'll have to revert this due to regressions on staging.
Another option is to ask Applause to run the regression tests on this branch, I think we do that sometimes for large changes. I'm not sure it's appropriate for this one, but we can ask if you want to try that. |
I tested it as much as I could. Search result look the same on dev and staging except the last case ✅ search tabsearch.tab.mp4✅ search from header icon20241205210114123.mp4✅ multi search termsmulti.search.text.mp4✅ self DMyou.mp4✅ user to join - emailuser.to.join.mp4✅ user to join - phonephone.number.user.to.invite.mp4✅ start chatstart.chat.mp4 |
@ahmedGaber93 Thanks for the thorough testing! Can you please test this case again? |
@neil-marcellini yeah i would sleep better if this PR would get a Applause regression test 😅 maybe we can ask them to only test search features / features that are related to where we show result lists? |
Hmm! Ordering still not the same. |
const orderedOptions = OptionsListUtils.orderOptions(optionList, undefined, { | ||
sortByReportTypeInSearch: isPaidGroupPolicy, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think config
will be ignored when we're passing searchValue
as undefined
because orderReportOptions(options: ReportUtils.OptionData[])
doesn't have a config
parameter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ordering looks the same with me in this case only when remove sortComparatorReportOptionByDate
here, but I don't know if we should remove it or no and also don't test this change effect on the other cases
Update: I test it on other places, and it causes a lot of mismatching ordering, so it is not the correct way. But it may help to investigate this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, okay, will double check with multiple accounts - good observation with the config not being used, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a function overloading for orderOptions to make sure you can only call it with options when you've provided a search value
c16d172
to
ee50f31
Compare
@ahmedGaber93 Okay I think I fixed the ordering now. I did this by separating the order statements, this is how it was working before (ie. the first order function was called in I will revisit the ordering function after the cleanup PR is merged. I think sorting twice is quite inefficient and especially lodash orderBy is known to be slow (but will profile soon and provide before and after values!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested well! All yours @neil-marcellini.
🎯 @ahmedGaber93, thanks for reviewing and testing this PR! 🎉 An E/App issue has been created to issue payment here: #53857. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, looks like it's time to merge. Hopefully QA will catch any issues we missed and if they create a blocker issue we'll revert this and fix the specific problem.
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
Explanation of Change
This PR is a refactoring that clearly splits the responsibilities into:
Before ordering and filtering was happening inter-connectedly, which makes it hard to change anything about that code.
Over at this PR i am working on improving the performance of the filtering:
and i need the filtering and ordering to be two clearly separate operations (so we can easily just swap out the filtering for a faster implementation).
Notes about the changes:
excludeUnknownUsers
was a option that had no code path that was ever used, so I was able to remove itsortPersonalDetailsByAlphaAsc
was defaulttrue
and there was no code path that was setting this tofalse
so I removed that as welllastVisibleActionCreated
. It was currently not present on the option and so i added it tocreateOption
getOptions
togetValidOptions
to emphasis the functions responsibility to return us only the options that are valid for showing in the UIfilterAndOrderOptions
(before it wasfilterOptions
). The new separate functions are:orderReportOptions
orderPersonalDetailsOptions
orderOptions
, combines the two above functionsfilterReports
filterPersonalDetails
filterCurrentUserOption
filterUserToInvite
filterOptions
combines the four aboveThere is also a performance advantage to this I want to point out:
Before we were applying some ordering to all options before filtering them. Now, we filter the options first and then apply the ordering to the remaining search result, which can be way more efficient.
Fixed Issues
$ #51954
PROPOSAL: #51954 (comment)
Tests
Offline tests
QA Steps
Same as testing
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop