I use optional chaining since if a link is not rendered in a spoiler, it will not have access to MarkdownSpoilerContext

The link colors look normal without this, but the problem I saw keeping this is that the color for MarkdownLink overrides the color for MarkdownSpoiler, so the link spoiler appears white and is visible through the spoiler

Using a Context here is helpful to limit further refactoring for any kind of pressables within a spoiler, such as when a user is mentioned. It's also useful since within the hierarchy

MarkdownParagraph
    MarkdownSpoiler
         MarkdownLink

there are Text components rendered in-between, making it difficult to just add another prop to pass down.

@atul @ashoat With the MarkdownContext, it's not "message-unique", so the same context is used for each of the messages (this is since we removed it from encompassing the text-messages, and moved it up to root.react.js. That's why we no longer keep track of spoilers/links with just a boolean, but instead a messageKey.

However, spoilerRevealed has the following structure (where parsedSpoilerIndex is the state.key passed in from rules.react.js:

[messageKey]: { 
    [parsedSpoilerIndex]: boolean
}

Because of this, the key for a spoiler may not be the same for the link contained within it. For example, in a message like:

Have you visited https://comm.app? You can go there from ||https://google.com||

The keys could be something like this:

https://comm.app --> 0 (since it's the first link)
||https://google.com|| --> 0 (since it's the first spoiler)
https://google.com --> 1 (since it's the second link)

Because of this, trying to access directly from spoilerRevealed within MarkdownLink doesn't seem too consistent, since in MarkdownSpoiler the spoiler would be at a key of 0 within the messageKey, but in MarkdownLink, we'd be accessing the link that is contained in the spoiler, but it has a key of 1, so it wouldn't find a match in the object.

As a result, I was looking for a solution that's more "message-unique", since we could then, for each spoiler, pass it's state down to it's children components, hence the new context. This can be extended to the @ feature that's currently being worked on since that could also be a pressable within a spoiler.

In retrospect, I agree with the approach being a bit fragile. Let me take a look at passing the messageKey and parsedSpoilerIndex in the context, or even better if I can just pass down the isRevealed state.

Defaulting to false here makes sense, since some MarkdownLink may not be a descendent of a MarkdownSpoiler. So in that case, linkWithinUnrevealedSpoiler = false, so we will have default link behavior onPress

Previously, flow typed isRevealed as boolean | string, but if we check the typeof messageKey === 'string', it evaluates to a boolean so it makes isRevealed consistently a boolean. I made this change part of this diff since it impacts how we use isRevealed here anyways

I'm not too sure - seems like the eslint/prettier forces this line, unless we probably reduce the length of the name. Explicitly typing the Context seems to be the convention in the codebase. Do you have any suggestion?

Good point, let me update the name. It'll make extending it to other pressables easier as well.

I didn't see any issues on either chats or calendars.

It is more than a convention: we have to assign a type to everything we export from a file, otherwise Flow will complain (this gives some context: https://medium.com/flow-type/types-first-the-only-supported-mode-in-flow-jan-2021-3c4cb14d7b6c).

Regarding the length, I can see that in other places we're also having the same issue, so it's fine to keep it as it is.