Fixed a bug in EuiCodeBlock docs where import statement example was raised up and evaluated.

[1Copenut]

Summary

EUI end user reported a bug in the EuiCodeBlock sandbox this weekend. After investigating I determined the sample import React from 'react' was being raised up and evaluated by CodeSandbox instead of being rendered as a code block. I changed the block to a general JS object and tested locally to ensure it rendered properly. adjusted the regex logic to ignore the string "React" in code comments.

---

Before

---

After

QA

Remove or strikethrough items that do not apply to your PR.

General checklist

• Checked in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Added documentation
• Added or updated jest and cypress tests
• Checked Code Sandbox works for any docs examples
• Checked for breaking changes and labeled appropriately

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6595/

[elizabetdev]

@1Copenut IMO we shouldn't change the example. But we should fix the regex that transforms the demo code to the demoJS tab.

If we pass a code like the following one:

const jsCode = `/* I'm an example of JS */
import React from 'react';`;

When we open the DemoJS tab, the regex thinks that import React from 'react'; that was passed as a string and assigned to const jsCode is a real import. This is not correct. As we can see in the following screenshot the const jsCode is not correct. It doesn't contain the import that was moved to the third line. Consequently, the CodeSandbox fails.

The regex that generates the DemoJS tab can be found here: https://github.com/elastic/eui/blob/main/src-docs/src/components/guide_section/_utils.js. Not sure if it is a lot of work to fix this... 😬

CC @cee-chen.

[1Copenut]

IMO we shouldn't change the example. But we should fix the regex that transforms the demo code to the demoJS tab.

Excellent call. I refactored the regex that populates the remainingImports[] to ignore matches with "React" string in them. Added a unit test to confirm this behavior.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6595/

[cee-chen]

While this works, I'm not a fan because it's not actually targeting the issue we want to solve - which is to say, it's finding an import string within a code snippet that isn't actually an import. So if the import snippet in question changed to import foo from 'bar', we'd still have the exact same issue.

I would strongly rather fix this with a negative lookbehind to find any backtick character before any import statement and not React specifically. You should be able to accomplish this like so:

Suggested change

	/(\/\/.+\n)?import ((?!React)[^]+?) from ('[A-Za-z0-9 -_.@/]*';)/g,
	/(?<!(`[\s\S]*))(\/\/.+\n)?import ([^]+?) from ('[A-Za-z0-9 -_.@/]*';)/g,

Since regexes are incredibly hard to read, we should also document this new addition in the code above line 78:

    // (?<!(`[\s\S]*))               - negative lookbehind ensuring that import statements aren't part of a template literal
    // (\/\/.+\n)?                   - optional preceding comments that must be above specific imports, e.g. // @ts-ignore

[1Copenut]

I pulled in your suggested change and ran it through Regex101 with a few test strings. It works well for our purposes here, as long as the template literal is the last item we're looking for.

[cee-chen]

There should be no scenario where a real import comes after a template literal backtick - our current eslint rules ensure that all legitimate imports are at the top of the file, so this is a fairly safe assertion to make.

[cee-chen]

Code changes LGTM - waiting for CI/staging to update and will approve then

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6595/

[cee-chen]

Staging LGTM! Nice attention to detail when catching this bug Trevor!