linkModalActive and linkPressActive shouldn't have a key for id if a thread is opened for the first time and the message has not been clicked - this allows us in a condition where we have (null || null) ?? false to default to the boolean false. That's my understanding (feel free to correct!)

In D5541, this is eventually moved to InnerTextMessage - for this diff though, I think it makes more sense to keep it here in order to not "combine" the two diffs and to isolate this diff to one specific task.

These setters don't need to update the whole state, do they? Why not just have the function take two things: the key as well as the new value for that key. Then all of the callers of these setters won't need to get the current state of the map.

As an example, take useDisplayLinkPrompt. Instead of this:

const setLinkModalActive = markdownContext?.setLinkModalActive;
const linkModalActive = markdownContext?.linkModalActive;
const onDismiss = React.useCallback(() => {
  if (linkModalActive) {
    setLinkModalActive?.({ ...linkModalActive, [messageKey]: false });
  }
}, [setLinkModalActive, linkModalActive, messageKey]);

We could have this:

invariant(markdownContext, "markdownContext should exist");
const { setLinkModalActive } = markdownContext;
const onDismiss = React.useCallback(() => {
  setLinkModalActive(messageKey, false);
}, [setLinkModalActive, messageKey]);

This isn't high enough in the hierarchy. It needs to be an ancestor of ChatContextProvider, since that component renders a ChatItemHeightMeasurer which will render InnerTextMessage et. al. Let's move this to root.react.js

(Your functionality shouldn't have any bearing on the height of the chat item, but it's still better to make your context accessible even from there, so that the downstream code can properly assume that the context will always be available and doesn't have to do any conditional checks)

Makes sense, I've abandoned D5541 and will put the changes here in the next revision.

My reasoning for wanted the setters to specifically force a state update was for the need for linkIsBlockingPresses in TextMessage (https://github.com/CommE2E/comm/blob/rohan/native-spoilers/native/chat/text-message.react.js#L228) - the branch isn't fully up to date but that line is still present.

My thoughts were that since we are determining whether linkIsBlockingPresses should be true or false based on whether the respective messageKey is present and true in, for example, linkModalActive, once we modify linkModalActive (when the link is pressed), we should force an update so linkIsBlockingPresses can pull from the updated objects and pass as a prop to the TextMessage component.

Ah, that would be my misunderstanding of the ancestry present, I've taken a deeper look through react dev tools and this comment makes more sense - it also explains the need for the optional chaining / checking in D5539. I'll go ahead and make this change, and then in D5539 I should be able to address the feedback as well afterwards

Ah, in that case I agree - moving it upstream would probably make more sense so it's in one place. Just one clarifying thought after thinking about the design implementation a little bit, do we really need the ... operator in retrospect for links? I'm thinking we could just do the following since I'm starting to doubt if need to keep track of every single link in the thread.

setLinkModalActive?.({ [messageKey]: false });

Since in text-message.react.js we already default to false if messageKey is not present in the object:

const linkIsBlockingPresses =
      (linkModalActive[key] || linkPressActive[key]) ?? false;

Does this need to be optional?

Shouldn't have to, I'm going to fix it in the revision

I think we should also be able to remove the optional chaining for MessageContext as well now that it's encompassing InnerTextMessage, as I took a look in dev tools and the hierarchy seems to be: MarkdownLink --> Markdown --> InnerTextMessage --> ...

Yeah the optional chaining can be removed!

Line is too long

Default should be null or undefined so that the invariant on React.getContext(MessageContext) has some meaning. Otherwise you could get a "silent failure" here where some downstream code thinks everything is fine but actually messageKey is an empty string and we're in a broken state

Yeah exactly from my understanding of the hierarchy.