Render valid React for Blockly XML in <SafeMarkdown/>

[maddiedierker]

This change updates our <SafeMarkdown/> component to render Blockly XML in a way that is valid React. We do this by wrapping each Blockly element in a custom component and using the components option in rehype-react.

Since Blockly elements aren't valid React (e.g., <xml> isn't a valid React component), we were previously seeing warnings any time Blockly blocks were rendered by our instructions panel:

This would also cause unit tests to fail for the same reason (we fail unit tests when console.warn is called), so we no longer have to skip or allow warnings in InstructionsCSFTest.js.

Links

• STAR-1680 - Unskip InstructionsCSFTest
• STAR-1708 - <InstructionsCSF/> logs warnings for instructions with embedded Blockly blocks

Testing story

Updates unit tests.

[epeach]

Do we know how this react component is read within the TTS system?

[dju90]

fwiw Blockly blocks are not currently read by our TTS (neither Acapela nor Immersive Reader)

[maddiedierker]

Do we know how this react component is read within the TTS system?

along with bryan's point, the resulting HTML output is nearly identical, so i don't think this change should affect our TTS, but i don't know the best way to double-check locally. i used our TTS feature on this level on both my feature branch and staging and there was no difference. i don't have an API key for immersive reader locally, so i'm unable to test that. i think i remember that our TTS files are generated at some point, which is why i'm not sure my testing method was actually the correct way to go about it.

[maddiedierker]

@epeach PTAL! let me know if there's a better way to test TTS with this change as well