Address feedback on filteredMediaInfos

Rebase on D6485

Rebase on D6485

Rebase on D6485

Rebase on D6485

Rebase on D6485

Rebase on D6485

Update query following 1:1 with Ashoat and move type declarations into this diff. I no longer need to use constructMediaFromMediaMessageContentsAndUploadRows since it'll be cleaner constructing the Media objects in the same function, as opposed to constructing an additional array of MediaMessageServerDBContent. Also, I'm pretty sure the uploadMap is going to have trouble finding thumbnails since this query puts videos and thumbnails in one row together. So it just seems cleaner to handle it within fetchMediaForThread

So instead of spinning our own solution now, we could probably just store in redux-persist for now.

In D6876#204358, @ashoat wrote:

Had a thought here – we should update our sanitization code to sanitize these public keys, as they are user-identifiable. Can you create a task for that and link here before landing? (Or a diff)

@ginsu, strongly encourage you to be more critical of yourself before submitting code in the future. This pattern of submitting code you feel like might be "good enough" to sneak past review leads to wasted time for both you and your reviewers. You should hold yourself to a higher standard – it will help you learn better, and it will save you time.

This seems like it would've been a great time to introduce a shared library instead of copy-pasting. I understand there is a monthly goal at play here, but how long does it really take to set up a shared library? In JavaScript it can be done in ~15min, but I'm not as familiar with Rust

Why are we using Modal though? Should we just update MultimediaModal to look like those designs?

Accepting to unblock, but a little confused since I don't see the keyserver side

Nice, glad you're persisting this

Accepting to unblock, but not clear why we're sending primaryIdentityPublicKey up twice

EDIT – never mind, I see this is addressed later in the stack

Had a thought here – we should update our sanitization code to sanitize these public keys, as they are user-identifiable. Can you create a task for that and link here before landing? (Or a diff)

@inka was right, I forgot a return for the cleanup callback. Also removed one ? but the second one is still needed because there's a function call after condition so flow can't be sure if the variable wasn't modified.

Add newline and react memo.

Moved eslint annotation to a later diff.

Fix types, move errors codes, answers to questions in inline comments.

Moved the code for the device token reducer to lib in a previous diff. Moved the device token to BaseAppState and reduce it in the baseReducer.

As far as I understand CSS, looks good to me 😅

Sign stringified JSON with nested structure

Create nested notifications keys structure like on web.

Used function from the lib instead of rewriting it

Rebase - parent update

Removed deepclone, surrounded dispatch with if in case of empty payload

In D6823#203762, @ashoat wrote:

Okay, just make sure you did this part of the Test Plan so that all constants are included:

Using console.log ensure types are covering every fields present in those objects.

The scenario where multiple new messages are created at the same time with the same collapse key actually does not occur currently in the app. However, in one of the following diffs I will make SIDEBAR_SOURCE and CREATE_SIDEBAR share the same collapse key, and since they are created at the same time, it will be possible for a SIDEBAR_SOURCE to have an @-mention. If that occurs, the SIDEBAR_SOURCE will not be the first message, so we want to make sure we check all of the new messages with the same collapse key.

Here's what the message/payload looks like on the web side: