MDX v2 doesn't like it so it's better to remove it.

< is not necessary here, both MDX v1 and v2 will autolink (cf playgrounds, with GFM plugin enabled for v2).

Review links:

• Before: https://reactnative.dev/contributing/how-to-open-a-pull-request#2-get-the-source-code
• After: https://deploy-preview-3807--react-native.netlify.app/contributing/how-to-open-a-pull-request#2-get-the-source-code

Both render the same:

Code blocks created through indentation does not work anymore in MDX v2 and cause compilation errors because of the {

Review links:

• Before: https://reactnative.dev/blog/2018/08/13/react-native-accessibility-updates#how-to-upgrade
• After: https://deploy-preview-3807--react-native.netlify.app/blog/2018/08/13/react-native-accessibility-updates#how-to-upgrade

Both render the same:

should we add the tsx type after the ```?

The syntax is not TS here, and the Docusaurus site has prism.defaultLanguage: 'jsx', so this does not seem required. I can add the language metastring here, but the current code is equivalent to what it used to be.

Do you want me to add tsx for futureproofness? It wouldn't do any harm.

@cipolleschi I applied ```tsx to those blocks for expliciteness/futureproofness/consistency, as almost all of your other code blocks declare a language.

BTW @Simek unrelated but the fact that prism.defaultLanguage: 'jsx' is applied by default means that Prism is going to try to highlight with JSX all the code blocks that have no language, for example:

-keep class com.facebook.hermes.unicode.** { *; }
-keep class com.facebook.jni.** { *; }

.
├── button.js
└── img
    ├── check.png
    ├── check@2x.png
    └── check@3x.png

"I am bold and red"
0-9: bold
9-17: bold, red

Maybe we need a Docusaurus option like ```undefined to unapply the default? 🤔
In practice it probably does not cause trouble but could some day.

is this change ok? We can find another alternative like

"Road to `<YOUR_MINOR_VERSION>`"

Review links:

• Before: https://reactnative.dev/contributing/release-branch-cut-and-rc0#9-create-a-tracking-discussion-post
• After: https://deploy-preview-3807--react-native.netlify.app/contributing/release-branch-cut-and-rc0#9-create-a-tracking-discussion-post

Now renders as:

Will using square brackets instead of lt/gt characters fix the issue? (Create a "Road to [YOUR_MINOR_VERSION]" discussion post in the...)

Yes! Pushing a fix

is this change ok? We can find another alternative like

'closed this in `<COMMIT_HASH>`'

Review links:

• Before: https://reactnative.dev/contributing/release-faq#how-do-i-know-if-my-fixfeature-is-in-a-certain-release
• After: https://deploy-preview-3807--react-native.netlify.app/contributing/release-faq#how-do-i-know-if-my-fixfeature-is-in-a-certain-release

yeah, I prefer this other as "closed this in" is not code.

I applied @Simek suggestion for consistency:

Can we keep it or do you prefer an inline code block?

Here I'd rather use a code block. console.log is a piece of code, so it makes sense to have the code.
Also, is a little weird that we have an HTML code for the open parenthesis and the actual closed parenthesis at the end.

I'd keep that separate as all the other types (like bool) are not in code blocks.

should we add the tsx type after the ```?

yeah, I prefer this other as "closed this in" is not code.

@cipolleschi @Simek @cortinico

This new inline code syntax

`md ({nativeEvent: [PressEvent](pressevent)})`

Turns on a basic support for Markdown links inside

Can you validate this idea?

IMHO this is an UX improvement, considering it's code it should be an inline code block. The non-usage of links before was probably a technical limitation that this new solution enables.

But this requires to teach technical writers to use the `md prefix to turn it on. Considering the current implementation, I prefer to keep it opt-in instead of applied everywhere by default.

Review links:

• Before: https://reactnative.dev/docs/next/button#requiredonpress
• After: https://deploy-preview-3807--react-native.netlify.app/docs/next/button#requiredonpress

I like it. I don't think that it will be an issue: if a technical writer wants to achieve the same result in these pages, it will likely go here and see how that was achieved and then it will copy the syntax!

@cipolleschi @Simek @cortinico

This is the code that enables the ability to use Markdown links inside inline code blocks, leading to this outcome:

This code is included in the client bundles, and I didn't want to include a heavy Markdown parser just for that use case. For that reason I choose to implement partial support (just markdown links), use regexp (less robust) and keep this feature opt-in.

@cipolleschi , in reply to your comment

On this page, if we start using inline code blocks, then it's not always clear how to keep it consistent without modifying a bit the content:

• Should the link wrap the inline code block? (only possible in some cases)
• Should the link be inside the inline code block? (needed if there's more than 1 link, cf Array.prototype.{xLink,yLink})

To understand better the visual consistency problem:

Before: https://reactnative.dev/docs/next/javascript-environment#polyfills

After: https://deploy-preview-3807--react-native.netlify.app/docs/next/javascript-environment#polyfills

As you can see, it does not visually render exactly the same depending on the order in which you apply the link/inline-code-block, and with current content shape, it's not really possible consistently one pattern or the other (or you would have to use code blocks for things that are not actually code: CommonJS require, XMLHttpRequest, fetch)

Is this consistency problem a blocker, or can we still merge this PR?

It can also be possible to modify the content itself to make it more consistent, because in some cases we have one link to a whole API (console), and sometimes we link to individual functions (Array methods).

In {set, clear}{Timeout, Interval, Immediate}, {request, cancel}AnimationFrame it's quite hard to know where to apply inline code blocks 😅 Note the , in the middle is not code.