In D8072#239274, @ashoat wrote:

This diff makes sense, but from a code search it looks like it might impact ThreadSettingsLeaveThread and its use of otherUsersButNoOtherAdmins.

In ThreadSettingsLeaveThread, we want to prevent somebody from leaving a chat if they are the only admin. I think it's important to consider "parent admins" there... otherwise, I think I'll be prevented from leaving any chats in eg. Comm. Not 100% sure if this is true, but can you investigate?

New landing page looks awesome 🚀

Remove comment

Remove comment

want to do a second pass through

REmove runtime erroneously added to CommConstants constructor on native.

@ashoat thank you!

Replace TurboModule with HostObject

Replace TurboModule with HostObject

@inka heads-up, your upload doesn't appear to have attached

I patched this stack and I'm seeing some weird behaviour. Sometimes I cannot scroll further until I scroll back up and down again. Please investigate this

Two questions about handling fetching results form the backend.
(Sorry for not asking about this in the first review cycle)

But if the array is compile-time constant, maybe a good idea would be to add this to CommCoreModule because they're kind of business-logic constants and fit well if we could do something like commCoreModule.NATIVE_MESSAGE_TYPES. However, this pattern seems not to be supported by RN yet (without hacks) and you'd have to do commCoreModule.getConstants().NATIVE_MESSAGE_TYPES which is not very nice.

In D8069#239140, @marcin wrote:

If you think it is an overkill to introduce new JSI module for this purpose then I am likely to agree with you. I hesitated between:

1. new method in CommCoreModule
2. custom jsi::HostObject implemented in C++ and exported to global and manually types in flow.

Looks good to me too

In D8050#238830, @ashoat wrote:

Two concerns:

1. Unlike native, it doesn't appear that we are waiting on the preload for anything. On native, we show the local URI until the preload completes. On web, for non-encrypted media we delete the local URI when the preload completes... but we don't wait for the preload to start showing the new URI, do we? It seems like we're likely to have a "flicker" still after landing this diff.
2. It seems like there are two parts we could consider for a "preload": download and decrypt. To perfectly avoid a "flicker", it feels like we'd also probably want to wait for the decrypt before showing the remote URI (but this would require 1 to be done first).

Assuming you agree with my assessment, could you create a task (or multiple tasks) for these before landing?

Rebase before landing

Fix typos. Rebase before landing

I changed a decent amount of this code so requesting review again

address feedback