This diff introduces a hook that constructs a resolved user search index. Similar to useThreadSearchIndex, we want to be able to map a user ID to both the raw username and their resolved ENS name (if exists). We do this by:
useUserSearchIndex(userInfos: $ReadOnlyArray<UserInfo>): SearchIndex {
1. get userInfos WITH ENS names
2. Construct a map between userInfo.id <-> userInfo
3. Create an empty search index
4. Iterate through each userInfo
5. For each userInfo, append identifying, searchable info related to that user (in this case, it would be their username and, if present, their ENS name)
If they have an ENS name, their username unresolved would be their wallet address.
6. Concat the array to be separated by a ' ', i.e. '0x378912479124719 ryan'
7. Add that to the search index associated with the user id
--> This makes it so when the search index tokenizes the input, both 0x378912479124719 and ryan will map back to the user id
8. Return search index
}This is a lot simpler than useThreadSearchIndex, so it didn't make much sense to reuse the same hook.
Following this, I was able to update all callsites to usePotentialMemberItems to no longer pass in a SearchIndex, and make a one line change to usePotentialMemberItems to call the hook to construct the search index.
There are some additional search experiences that need to be updated, but those will come in the next part of the stack tracked in ENG-5434
Depends on D10229