So from the touch event, React Native provides a few useful properties that would be good for determining where the event occurred relative to the viewport. There were two main options here:

locationX and locationY - these coordinates tell you, relative to the top left corner of the touchable space, where the touch event happened.

pageX and pageY - these coordinates will tell us, relative to the viewport, where the touch event happened (so relative to the top left of the screen).

Here's a demo where I log pageX, pageY and you can see how the Y coordinate jumps when the image is at the bottom of the screen as opposed to closer to the top.

Meanwhile, when logging locationX, locationY, you can see how the coordinates are contained within each TouchableOpacity, and won't really be useful in determining for the animation where the touch event occurred.

You're right, I took a look originally and mistakingly saw corners calculated in InnerMultimediaMessage and assumed it was used as a prop, so I looked at how the corners were calculated and emulated the behavior. Taking another look at it, it seems like it is mainly used to determine the style for the media grid when images/videos are sent in chat (so what media should have rounded corners as opposed to normal edges). It's passed down as a property from here, but I don't see it used anywhere down the component tree.

I think the best thing to do would be to refactor MediaInfo to simply not require corners, remove it from being passed in as a prop in inner-multimedia-message, and after that update this diff to remove the corners object.

I suggest this as an alternative to introducing a new type simply without corners because I don't really see a place where the corners prop is used / extracted. It'll also be a lot cleaner than replacing every instance of MediaInfo with a new type. I tried this locally and running flow gave me no errors and media worked as expected in both chat and the thread gallery.

Open to creating a new type and replacing instances of MediaInfo if you think this won't be a good idea though

I think these are the wrong coordinates – you're capturing the coordinates at which the touch event happened, but initialCoordinates is supposed to represent where the image was on the screen when the touch event happened

You'll need to do the onLayout / .measure approach we discussed in our 1:1

Good catch!! I was able to remove corners from MediaInfo entirely without triggering any Flow errors, so I agree this is safe.

Alright, sounds good. Since I can't call useRef inside useCallback(), I think I may have to extract the component rendering into a separate component, like GalleryItem, and there I can attach a ref and onLayout to each individual item.

I'm under the impression that measuring the entire FlatList won't get me what I need since I'm more interested in the position of the actual item inside the list, not the FlatList container, and the item's position changes as we scroll.

corners will be removed in D6659 since we're passing in a mediaInfo into Multimedia there

I need to figure this out before landing, but I didn't want to block code review for addressing feedback

Curious if there is a better type for this, typeof unboundStyles won't work since I'm passing in memoizedStyles here as opposed to the unbound styles. I feel like the easy solution is to accept a type Object (any), but I know we generally want to avoid that

Fair point. Since we need a unique key for the navigation, would it be safe to say that generating a key as:

multimedia|${threadID}|${mediaInfo.id}

works instead? Each Media item should have a unique ID that wouldn't change when a new media is uploaded, and so that should (?) make the key unique per media item and avoid the situation you proposed

Yeah that sounds perfect!

Prettier seems to force this here to a new line when the pre commit hooks run. Tried fixing it locally and it got corrected back to this