I think you could just return null instead of <View />?

Though it does look like there's another example of this in the codebase:

(cc @ashoat)

Could we early-exit here to reduce indentation?

Like

if (routeName !== MultimediaMessageTooltipModalRouteName) {
  return;
}
navigation.dispatch....

I'd add a newline after this to improve readability.

This is 82 characters wide, can we split to multiple lines

This is 162 characters wide, can we split to multiple lines

Spent 5ish min and couldn't figure out anything simpler. Could pull out and then include/exclude some top-level fields, but ran into some issues with the "insides" of the messageInfo field. CC @ashoat who might have some better ideas.

Given the way things are now, can we structure as if/else if/else?

Could we define this outside of the onPress?

Is there a variable from design system we can use here?

This is right – context here, and we already tried navigation.replace (doesn't work here since this isn't a stack navigation prop, it's an overlay navigation prop)

Can we avoid copy-pasting this? Maybe it should be factored out into a hook?

Yeah, unfortunately this is normal... you can add a // This conditional is for Flow comment or something for clarity

This is the wrong ParamList for this. It should go in OverlayParamList

Typo here (Tetx)

Can we try to avoid crashing if visibleOverlays is empty? It would be an unusual edge case, but I could imagine the modal getting dismissed right before the pin action is selected somehow

I noticed you're no longer checking the routeName. This is somewhat concerning... you could for instance imagine a scenario where somebody quickly presses Copy (which pulls up an ActionResultModal overlay) and then presses Pin (which would replace the ActionResultModal overlay, but keep the tooltip overlay)

I think we should make this look for the most recent entry in visibleOverlays that has a valid tooltip routeName, and then use its routeKey. If we can't find one, I think we should just do a navigation.navigate.

Regarding checking the routeName, rather than explicitly listing the three tooltip route names, I think it would be good to create an array of all three in native/navigation/route-names.js next to where the MessageTooltipRouteNames type is defined, and then import that here for the check.

If routeKey is undefined here, I think we should avoid calling StackActions.replace, and instead should call navigation.navigate. Looking at the ReactNav docs, if for some reason there are no active overlays when this is called, we risk a situation where we replace the bottom route, which contains the whole app navigation structure