(Probably because it reduces unnecessary computation)

Refactored this function out of userInfoSelectorForPotentialMembers so I don't duplicate code when filtering userInfos from keyserver.

We need to store usernames alongside the userIDs (because we might not have some of these users in userStore so we can't access their usernames later).

Because of this, we need to stop keeping the state in navInfo.selectedUserList (we only store ids there). Now the navInfo is only used for the initialization, and later it's only updated to reflect the state in userInfoInputArray.

This useEffect combines the two previous ones.

Logic for getting userInfos from the keyserver. callSearchUsers doesn't return relationships, but we can assume that if we don't have someone in the userStore we don't have a relationship with them. Because of that we need to remove users that we already have in the userStore.

Instead of updating the navInfo we can just use setUserInfoInputArray. These changes will be dispatched in the useEffect in chat-message-list-container.react.js.

Good point. When we add a new user the newSelectedUserIDs changes which triggers this dispatch and updates the navInfo. Then the userEffect runs again because selectedUserIDs is updated but now it's equal to newSelectedUserIDs and the payload is empty.

Should just surround the dispatch with an if?

We want to remove users from serverSearchUserInfos that blocked the viewer but the useServerCall(searchUsers) doesn't return the relationship status.

We can assume that we have a relationship with someone only if we have them in the userStore. So we remove users that are in userInfos and that leaves us with only the users that we don't have a relationship with.

Users that were removed but didn't blocks us are included in the otherUserInfos. So when we merge these two values we should get a list of users that didn't block us from both userStore and keyserver.

Modifying searchIndex mutates it, so to keep it pure I had to clone it. I'm doing this because getPotentialMemberItems requires SearchIndex with all the potential users.

I've just looked at how this is solved in other places and there we just use the results from the useServerCall(searchUsers) directly. We can use a similar approach here, we would just have to modify getPotentialMemberItems to take an additional array of users that skip the SearchIndex.

This won't happen now but I think we should check if we aren't adding duplicates from the searchIndexes.

Per tomek's comment:

It might be a good idea to extract some of these to separate memos so that we don't recompute them on every effect call

This can be simplified.