It appears as if you're issuing queries to both places, but since usingCommServicesAccessToken is a constant, only one will be used.

Is there another way to structure things to avoid this? For instance, what if instead of these hooks, you had hooks that returned a function that would execute the search?

Alternately, what if the search query was executed by a different React component (that this component would render). Then you could pick which place was queried by conditionally rendering one of two React components.

This is a perfect use case for ternary syntax

Looks like this logic is the same that you are introducing in MessageListContainer. My comments above will probably make this code a bit more complicated, so I think it's worth considering if you could factor it all out to avoid repeating yourself

Is this the current best practice? It doesn't look like you'd be able to handle changes to the auth metadata with this approach. @varun can maybe give better feedback here.

I settled on possible abandoning https://phab.comm.dev/D11049 and https://phab.comm.dev/D11060 and editing the existing useSearchUsers function with a conditional for my identity search functionality.

I probably should have done this at the start because my useSearchIdentityUsers is almost identical to the keyserver search useSearchUsers function but I mistakenly wanted to leave useSearchUsers untouched.

I'll push the diff soon, but I'm unsure if actually having a conditional hook that returns one of two functions would be the better solution.

I believe this is fine to replace the existing function as all the locations of where we're using useSearchUsers would've eventually been replaced by useSearchIdentityUsers anyway

we should follow the pattern introduced in IdentityServiceContextProvider (native/identity-service/identity-service-context-provider.react.js).

eventually, we will need to get the userID from currentUserInfo (we should create a new task like https://linear.app/comm/issue/ENG-6649/use-userid-from-currentuserinfo-in-identityservicecontextprovider)

(cc @tomek @inka, please correct me if i'm wrong here)

Seems reasonable, if I'm interpreting you correctly

The current best practice is to get this data from IdentityClientContext by calling await getAuthMetadata() method that it exposes. We can't store this data in e.g. state, because it can change - instead, we should await this method every time we need the data.

With accessToken we can safely read it from Redux because we have a handler that listens for the changes and updates the store.