In D9257#272801, @kamil wrote:

Not a fan of keeping the solution with mutating input, but accepting this since fixing this is not a part of this work. Maybe we can at least create a task to improve this?

Add early return and use more functional approach

Can you expand the test plan a little bit by e.g. checking that a modal doesn't show for logged-out users?

Looks great, but there are a couple of issues.

Is it valid to require policy acceptance only when a user is logged in? When a user isn't logged in, we don't allow them to do much, but I'm wondering, if from the legal perspective, we should require them to agree to something.

In D8900#271640, @ashoat wrote:

Is the performance concern pointed out by @tomek going to lead to additional React render cycles? If yes, we should prioritize addressing it. cc @atul

In D9211#271306, @atul wrote:

In D9211#271261, @tomek wrote:

Have you tested if memoizing the list is beneficial? FlatList is already memoized internally (PureComponent) so wrapping it with memo shouldn't improve anything, but maybe I'm missing something.

Yeah, previously flatList would re-render when fixedSearch changed because it was in the chatThreadList dep list. Separating flatList out into its own useMemo seems to prevent that.

Have you tested if memoizing the list is beneficial? FlatList is already memoized internally (PureComponent) so wrapping it with memo shouldn't improve anything, but maybe I'm missing something.

In D9120#269321, @inka wrote:

Is it possible that a user with this id will not be in our store?

We probably should memoize the rules

This looks strange. We were rendering ChatContextProvider quite high in the tree, a couple of levels above navigation. Now, in order to make it accessible in other places, we're placing it within navigation. So it seems we're reducing the number of places where it is accessible. Am I missing something?

It might make sense to introduce a new hook that:

1. Get the candidates using useThreadChatMentionCandidates
2. Computes the rules using getDefaultTextMessageRules
3. Memoizes them using memo

In D9091#268772, @marcin wrote:

One last question: Is it guaranteed that we call the notif's completionHandler only after the deletion tasks are finished?

It is not guaranteed and it is impossible to guarentee that since contentHandler is called quickly in the NSE while blob deletion takes place on the background thread in the main app so the system decides when it is best to call it. Additionally main app might not be running when NSE processes notification. However why would such guarantee be necessary in the first place? Blob download and persistence is synchronous and writing blob metadata to the storage which main app reads during deletion takes place afterwards. So the deletion process won't start until notification payload is persisted on the device so when user opens the app the message will be loaded and immediately visible in the app regardless on when delete requests are issued.

One last question: Is it guaranteed that we call the notif's completionHandler only after the deletion tasks are finished?

While introducing a lot of memoization, we should also check how it affects memory usage

Overall, it makes sense, but I have a couple of questions.

Not sure how these will be used, but I'm wondering what is the benefit of having a selector returning

type ServersCallState = {
  +cookies: { +[keyserverID: string]: ?string },
  +urlPrefixes: { +[keyserverID: string]: string },
  +sessionIDs: { +[keyserverID: string]: ?string },
  +connectionStatuses: { +[keyserverID: string]: ConnectionStatus },
  +lastCommunicatedPlatformDetails: {
    +[keyserverID: string]: ?PlatformDetails,
  },
  +currentUserInfo: ?CurrentUserInfo,
};

over a simpler selector that could return

{ +[keyserverID: string]: KeyserverInfo }

where

type KeyserverInfo = {
  +cookie?: ?string,
  +sessionID?: ?string,
  +updatesCurrentAsOf: number, 
  +urlPrefix: string,
  +connection: ConnectionInfo,
};

From the caller's point of view, the difference doesn't seem to be significant, e.g.

result.cookies[serverID]

vs

result[serverID].cookie

But I'm probably missing something.

Looks good!