Page MenuHomePhabricator

[lib] Convert getPotentialMemberItems into a hook
ClosedPublic

Authored by rohan on Dec 7 2023, 11:22 AM.
Tags
None
Referenced Files
F3323270: D10229.id34555.diff
Wed, Nov 20, 3:28 AM
Unknown Object (File)
Tue, Nov 12, 3:35 PM
Unknown Object (File)
Tue, Nov 5, 10:47 PM
Unknown Object (File)
Wed, Oct 23, 12:55 AM
Unknown Object (File)
Oct 14 2024, 3:28 AM
Unknown Object (File)
Oct 14 2024, 3:28 AM
Unknown Object (File)
Oct 14 2024, 3:28 AM
Unknown Object (File)
Oct 14 2024, 3:28 AM
Subscribers

Details

Summary

This should be a no-op change in terms of the results that getPotentialMemberItems used to return. I'm simply converting it into a hook so I can call a hook that will construct a search index in the next diff, necessary to make it possible to prefix-search for users by their ENS names.

Addresses ENG-5402

Test Plan

Did some manual testing to confirm that there was no change in the search results returned (both by console.log'ing before and after, as well as searching for users on the app)

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

rohan requested review of this revision.Dec 7 2023, 12:01 PM

About to go to lunch and will give a more quality review later, but just saw the blockedRelationshipsStatuses set and I think there maybe some code that you can reuse.

lib/shared/search-utils.js
46–50

IIRC I think there may be a preexisting blockedRelationshipsStatuses set in lib already. I remember having to use something similar for user profiles.

lib/shared/search-utils.js
46–50

Oh good call. I couldn't see a set, but I did find relationshipBlockedInEitherDirection which includes all 3

userRelationshipStatus.BLOCKED_BY_VIEWER,
userRelationshipStatus.BLOCKED_VIEWER,
userRelationshipStatus.BOTH_BLOCKED

so I can use that probably

Use relationshipBlockedInEitherDirection instead of redefining a blocked set

ginsu requested changes to this revision.Dec 7 2023, 3:01 PM
ginsu added inline comments.
lib/shared/search-utils.js
49–50 ↗(On Diff #34394)

It looks like in every case we are getting searchIndex from a useSelector hook in every case and userInfo from a useSelector in most cases (I wonder if in ChatThreadComposer) if it's also using a useSelector in parent component and getting passed down as a prop.

Regardless at the very least we should factor out searchIndex as a param and just call it directly in here

66–84 ↗(On Diff #34394)

Wouldn't hurt to also memoize these guys too (containgThreadID is probably fine to not memoize since that is a string)

86–92 ↗(On Diff #34394)

We should memoize this and the related logic below

133 ↗(On Diff #34394)

We should memoize this guy too

This revision now requires changes to proceed.Dec 7 2023, 3:01 PM
rohan marked 4 inline comments as done.

Address feedback

lib/shared/search-utils.js
49–50 ↗(On Diff #34394)

I end up removing the provided searchIndex param in the next diff (D10231) since it will no longer be needed, so if it makes sense to you I'll leave it as is in this diff to prevent adding code that's going to get deleted anyways!

Let me know if you disagree though

lib/shared/search-utils.js
102 ↗(On Diff #34402)

sorry I missed this in my first review cycle, but we should factor this out into its own useCallback

49–50 ↗(On Diff #34394)

Okay that makes sense, thanks for letting me know!

ginsu requested changes to this revision.Dec 11 2023, 11:47 AM

putting this back in your queue

This revision now requires changes to proceed.Dec 11 2023, 11:47 AM

Spoke with @ginsu and addressed feedback following that

thanks for addressing my feedback @rohan

This revision is now accepted and ready to land.Dec 13 2023, 9:21 PM