Looks like a straightforward find+replace. Thanks for laying out the outline of the stack in the summary, made it easier to make sense of each diff

Seems reasonable

Double Extra Large??

We need to factor those parts out, so I created FullScreenViewModal which will be a generic component that can be used in both cases for image multimedia messages and user avatars.

In D9358#275095, @ginsu wrote:

Don't love the indirection, but seems like a reasonable approach

Wdym by indirection here? Happy to make any updates to make it less indirect

cc @atul

Looks good, let's memoize ImageModal before landing

Don't love the indirection, but seems like a reasonable approach

https://linear.app/comm/issue/ENG-5157/investigate-xcode-15-foundation-import-issue

Expo has high expectations for issue reports... basically they want a minimally viable reproducible example for each report.

Whether or not this stack gets landed, was super helpful to understand how each solution alone/in combination with others would affect size of ThreadStore

might make further sense to pull out to separate test data file?

Thanks for addressing feedback!

rebase and land

resolve flow issues, no easy way to use performance.now() without typing it myself, so using Date.now() for timebeing which is probably more than accurate enough

In D9307#273591, @ashoat wrote:

Does monitoring perf have any negative perf impacts?

looks like it can be even simpler...

different approach that doesn't override $HOME/.my.cnf, continues to work:

remove extraneous condition

fix

Similar to .*/node_modules/resolve/test/resolver/malformed_package_json/package\.json$ which is in the RN .flowconfig this package.json isn't actually a package.json, but rather an intentionally malformed json file used as part of some internal tests. We can just ignore it for now to appease flow.

Looks good!

Let's memoize that style object (array)

Deferring to @ashoat/@tomek since I'm not familiar w/ this area of the codebase and it seems important to get right.

Thanks for thoroughly explaining reasoning in comment

Personally would prefer to inline these conditions but it doesn't matter a ton

Seems reasonable

Glad it wasn't too much overhead to use the async versions of the brotli functions

Just skimmed through, trusting CI here

This can be abandoned now?

Looks good, thanks for addressing feedback

Nice, much easier to understand at a glance

Looks good, only thing I'd change before landing is trying to avoid the one-off spacer.

Let's use existing relationshipBlockedInEitherDirection

In D9294#273227, @atul wrote:

2. Further, instead of "rolling our own" compressMessage, could we use the WebSocket per message-deflate extension? (https://datatracker.ietf.org/doc/html/rfc7692). Seems like it can seamlessly be integrated w/ ws: https://github.com/websockets/ws#websocket-compression. This leverages the Node/zlib library mentioned above out of the box.

Can we leverage Brotli compression/decompression functionality that's built into Node/Zlib instead of introducing a new dependency?

Example of using built-in Node functionality

Accepting to unblock, however, would be good to get thoughts on the following:

rebase and land

So I actually tried to include this in D9227: https://phab.comm.dev/D9227?vs=on&id=31269#toc, but there was some additional stuff that got included when I ran patch package (figured that was safer than just renaming file)