Refactor searchMatchUtils out from optionsListUtils#86982
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 06b029bcd0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
sharabai
force-pushed
the
fix/newChatPage/dataPreparation/extractSearchMatchUtil
branch
from
06b029b to
9f3a79c
Compare
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
|
@codex review |
|
Codex Review: Didn't find any major issues. 🎉 ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
@dukenv0307 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] |
|
@sharabai Code looks good. Can we refactor this place as well? |
|
And we'll implement the pagination on the next PR right? |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / SafariScreen.Recording.2026-04-08.at.16.13.01.mov |
@dukenv0307 |
Great eye for detail! It's good to test if such improvements could be applied elsewhere. I've looked into this and it would not work. Also, the Anyway, it was worth investigating. |
NikkiWines
left a comment
NikkiWines
left a comment
There was a problem hiding this comment.
nice, thanks for cleaning this up a bit! Couple small things
| * | ||
| * Expects `searchTerm` to already be lowercased and trimmed. | ||
| */ | ||
| function isPersonalDetailMatchingSearchTerm( |
There was a problem hiding this comment.
| function isPersonalDetailMatchingSearchTerm( | |
| function doesPersonalDetailMatchSearchTerm( |
| import type {SearchOptionData} from './types'; | ||
|
|
||
| type SearchMatchConfig = { | ||
| /** Use toLocaleLowerCase() instead of toLowerCase(). Default: false */ |
There was a problem hiding this comment.
| /** Use toLocaleLowerCase() instead of toLowerCase(). Default: false */ | |
| /** Whether to use toLocaleLowerCase() instead of toLowerCase(), defaults to false */ |
There was a problem hiding this comment.
Also why would we want to use one vs. the other here?
There was a problem hiding this comment.
Also why would we want to use one vs. the other here?
@NikkiWines, I do agree that it'd be great to have some clarity on why things are the way they are, and some parts of our App use toLocaleLowerCase and other toLowerCase.
The refactor I did does not introduce new utils and does not tell you how to use them. All I did was take out existing code that was repeated multiple times with very small differences and refactored it out in favor of DRY approach. I do not have the underlying knowledge for why the authors decided to use one over the other.
Having said that, I do think it's a good question and should be looked at more closely, but it should be handled outside of this PR because this is not the place that introduces those usages.
I did some digging into the codebase and came to a few realizations and a few questions.
First of all, toLocaleLowerCase usage is extremely rare compared to toLowerCase, it's used only about 20 times in our whole codebase.
Secondly, when we're using toLocaleLowerCase for Display/UI text, it makes sense.
But with search matching utils, that's where it raises some questions for me.
I looked up the original PR that introduced toLocaleLowerCase in OptionsListUtils/index.ts.
Looking at it some more I found this moment when deburr was also added to handle diacritics.
It looks to me like the current approach (deburr + toLocaleLowerCase) would not work in some edge cases.
For examples, let's say the user (who is in Turkey) enters Istanbul into the search bar, it gets processed by processSearchString, which uses toLowerCase. Then in the getValidOptions searchText = deburr(searchText.toLocaleLowerCase()); is used and then down the line we would compare those two.
That's the place where it probably wouldn't work, because evaluating "ISTANBUL".toLocaleLowerCase('tr').includes("ISTANBUL".toLowerCase()) returns false.
@sosek108 could you help us out here? was there a specific reason toLocaleLowercase was introduced?
There was a problem hiding this comment.
That was a long time ago so I'm not sure whether this toLocaleLowerCase was actually introduced by me or is visible there because I refactored OptionsListUtils. I did split OptionsListUtils.ts into two files.
I do remember that while I was refactoring search components we had problems with ordering of names containing special characters. This is why we would use toLocaleLowerCase and deburr.
sharabai
force-pushed
the
fix/newChatPage/dataPreparation/extractSearchMatchUtil
branch
from
c9c484b to
668df40
Compare
sharabai
force-pushed
the
fix/newChatPage/dataPreparation/extractSearchMatchUtil
branch
from
668df40 to
e975331
Compare
NikkiWines
left a comment
NikkiWines
left a comment
There was a problem hiding this comment.
lgtm, thank you for adding tests 🙌
|
🚧 @NikkiWines has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/NikkiWines in version: 9.3.60-0 🚀
Bundle Size Analysis (Sentry): |
|
No help site changes are required for this PR. This is a purely internal code refactoring — it extracts search-matching utility functions into a new |
|
🚀 Deployed to production by https://github.com/mountiny in version: 9.3.60-22 🚀
|
6 participants
Explanation of Change
Motivation
While looking at how
NewChatPageprepares its data, two things stood out:A repeated pattern across 4+ files:
getPersonalDetailSearchTerms(item, id).join(' ').toLowerCase().includes(term)-- identical logic copy-pasted with no shared abstraction.NewChatPagecallingformatSectionsFromSearchTermwith 7 parameters (includingprivateIsArchivedMap,allPolicies,allPersonalDetails,reportAttributesDerived) that are completely unused in the code path NewChatPage actually hits. This adds unnecessary Onyx subscriptions and widens the dependency surface for React Compiler memoization.What changed
Created
src/libs/OptionsListUtils/searchMatchUtils.tswithisPersonalDetailMatchingSearchTerm-- a single function that encapsulates the "does this option match a search term" check, with an optional config for locale-aware lowercasing and text transformation.Moved
getPersonalDetailSearchTermsandgetCurrentUserSearchTermsinto the new file (re-exported fromindex.tsfor backward compatibility).Replaced
formatSectionsFromSearchTerminNewChatPagewith a 4-line inline filter. This removed theusePrivateIsArchivedMap()hook, theallPoliciesOnyx subscription, and theallPersonalDetailscontext read from the component body -- all of which were only needed for that one call.Replaced the inline pattern in
MoneyRequestParticipantsSelectorandMoneyRequestAttendeeSelector.Gains
NewChatPagecomponent: removedusePrivateIsArchivedMap()(subscribes toCOLLECTION.REPORT_NAME_VALUE_PAIRS),allPolicies(COLLECTION.POLICY), andallPersonalDetails(PERSONAL_DETAILS_LIST) from the component body. Fewer subscriptions = fewer re-renders = less cache invalidation.NewChatPage's section building.SearchMatchConfigparameter supportsuseLocaleLowerCaseandtransformSearchTextfor call sites that need diacritic-insensitive matching or appended text.Fixed Issues
$ #86089
Tests
Offline tests
QA Steps
Same as tests
Offline tests
QA Steps
Same as tests
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
working.list.mp4