fix: keep the parser registration alive across effect remounts

[dariusz-biela]

Details

MarkdownTextInput (native) registered its parser worklet in a useMemo and unregistered it in a useEffect cleanup. When React ran the cleanup without unmounting the component (React StrictMode, a hidden <Activity>), the id was erased from the C++ registry, useMemo did not recompute, and the decorator view kept a dangling parserId. The native parser then returned no ranges, so the input silently stopped formatting markdown for the rest of its life.

In the app

• Markdown formatting keeps working after a screen wrapped in <Activity> is hidden and revealed, and under StrictMode in development.
• An input that React keeps mounted but hidden still formats when native code re-applies styles in that window.

In the code

JS:

• Registration lives only in a layout effect, inside the new useParserId hook. The effect body registers, its cleanup unregisters, and the id reaches the decorator view through state. The first commit carries 0 (no parser yet); the effect then publishes the real id and both native views re-apply formatting for it.
• Nothing registers during render any more, so a render React abandons (a suspended tree, an <Activity> removed while still hidden) cannot leak a registry entry.

Native:

• The registry is now only a handoff from JS to native. When the decorator receives a new parserId, MarkdownParser resolves the worklet once and keeps it alive for as long as the view lives, so a parse that happens after JS unregistered the id (a hidden but still mounted input) still formats. An id the registry does not know leaves the previous worklet in place.
• iOS: MarkdownParser holds the worklet, RCTMarkdownUtils passes the id through on both the component and the measure path, and parseUncached resolves the worklet before touching the worklet runtime, because the first commit's id 0 can arrive before the runtime exists.
• Android: MarkdownParser becomes an fbjni hybrid that holds the worklet, and MarkdownTextInputDecoratorView owns it so the MarkdownUtils recreated on every attach does not drop it.
• getMarkdownWorklet, which threw std::out_of_range, is replaced by findMarkdownWorklet, which returns nullptr for an unknown id.
• @types/react-dom is added as a devDependency for the new test suite.

Related Issues

Expensify/App#98254

Manual Tests

Automated: src/__tests__/parserRegistration.test.tsx renders the native MarkdownTextInput through react-dom into jsdom with a mocked registry. It covers mount, unmount, a rerender with the same parser, StrictMode, a hidden and revealed <Activity>, an <Activity> removed while still hidden, an abandoned suspended render, two inputs sharing one parser, and a parser identity change (visible, inside a hidden <Activity>, and in an initially hidden <Activity>). Every test also asserts that no registration is left behind after unmount. The StrictMode and <Activity> cases fail without the fix.

Example app, iOS 26.3 simulator and Android 16 emulator, both with the rebuilt native code:

1. Cold start: the initial value is formatted on the first frame, so the extra commit for the real id does not leave the input unformatted or mis-measured.
2. Wrap the input in <Activity>, hide it and reveal it: formatting is intact and typing _new_ renders italic.
3. Swap the parser prop to a worklet that marks the whole text as strikethrough and back: the input follows each parser.
4. Wrap the input in <React.StrictMode>: formatting stays and typing *sm* renders bold.

To reproduce in the example app, pass the parser as a worklet that calls parseExpensiMark(input, 4000). With react-native-worklets 0.10.2 the default parameter maxLength = MAX_PARSABLE_LENGTH is evaluated before the worklet closure is destructured, so parseExpensiMark itself throws Property 'MAX_PARSABLE_LENGTH' doesn't exist on the worklet runtime. That is unrelated to this change (the parser and the plugin are untouched here).

Linked PRs

Expensify/App#100318

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[dariusz-biela]

I have read the CLA Document and I hereby sign the CLA