Page MenuHomePhabricator

[lib] Introduce allAtOnce param to useENSNames
ClosedPublic

Authored by ashoat on Oct 17 2023, 10:33 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 20, 8:16 PM
Unknown Object (File)
Thu, Nov 14, 9:08 AM
Unknown Object (File)
Wed, Nov 13, 8:55 PM
Unknown Object (File)
Sat, Nov 9, 10:20 PM
Unknown Object (File)
Fri, Nov 1, 9:54 AM
Unknown Object (File)
Fri, Nov 1, 9:52 AM
Unknown Object (File)
Fri, Nov 1, 9:51 AM
Unknown Object (File)
Fri, Nov 1, 9:33 AM
Subscribers

Details

Summary

In D8248, I updated the code for useThreadSearchIndex to circumvent useENSNames so that we could make a single React state update for all of the ENS names instead of having a separate React state update for each name as it trickled in.

While investigating ENG-5274 I realized we need a more generic mechanism for this.

Additionally, in that case there is some separation in the callstack between the call to useENSNames and the business logic that needs resolved ENS names. As such, I figured the best solution would be to introduce a parameter to useENSNames that would achieve what we want, and can be "drilled" through the entire callstack.

In the following diff, I'll introduce a new usage of this new parameter to resolve ENG-5274.

Test Plan
  1. I confirmed that I'm still able to search for an ENS name in the inbox search, and a matching chat is returned.
  2. I tested performance before and after this change using my production data to confirm I'm not introducing a regression.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable