innerText isn't supported by jsdom

[matthew-black]

Description:

I think we've avoided this issue up until now because the lecture notes use textContent, rather than innerText. I used innerText in lectures with Biscayne, and a student encountered this:

• https://primeacademycampus.slack.com/archives/C06K5JLSDND/p1711819584913089

Here's my current understanding:

• textContent is a DOM node's raw text content.
• innerText is a DOM node's opinion about what its rendered text is.
• jsdom's DOM instance doesn't perfectly recreate a browser's DOM instance when it comes to distinguishing between raw text and rendered text. There remains a distinction between:
  • What actual text a DOM node contains.
  • What of that actual DOM node's text will be rendered.
• It doesn't seem at all to be a priority for jsdom (which, btw, is the default test environment for Jest) to communicate this issue.
  • There's no mention of innerText at all in their docs.
  • I assume this is because of the fact that writing integration tests on Vanilla JS front-ends is not really a thing that people are doing out there. (Discovered this when looking for resources while creating these tests. 🙂)

---

How to Fix:

We'll need to:

• Add verbiage that innerText cannot be used in INSTRUCTIONS.md.
• Add a test that checks for innerText usage and tells students to use textContent instead.

Or:

• Find and replace innerText with textContent in students' JS files before we run this line of code.

  • I'd prefer to give this a try. Thinking about it pedagogically, I don't like the idea of adding a "by the way, please avoid this arcane gotchya introduced by a dependency of the automated tests" requirement to the very first weekend challenge students encounter. 🫤

And Also, To-Dos

• Ensure other pre-React weekend challenge tests deal with this issue.
• FSE instructors talk through pros/cons of just using Cypress for all DOM-related challenges.
  • Or, maybe a fun pivot could be to just do all the tests with Playwright, and add a week of E2E testing w/ Playwright to the curriculum. :)

[DoctorHowser]

\binnerText\b Explanation:

\b: A word boundary, ensuring innerText is not part of a larger word (e.g., it wouldn't match myinnerTextVariable). innerText: The literal text to match. \b: Another word boundary for the same reason as the first.

const jsContent = `element.innerText = 'Hello, world!';`;

const findInnerText = /\binnerText\b/g
const replacedContent = jsContent.replace(findInnerText, 'textContent');

console.log(replacedContent);

[dgilleland]

@matthew-black - If you are looking for a work-around to share with others who need it in their tests, here's an idea. I had to do this for tests I've been creating as part of a course teaching JavaScript fundamentals. It was necessary to check .innerText because students were being taught how to use that property on DOM elements.

beforeAll(() => {
    Object.defineProperty(HTMLElement.prototype, 'innerText', {
        get: function() {
            return this.textContent.toString();
        },
        set: function(str) {
            this.textContent = str.toString();
        }
    })
});

The extra use of .toString() was needed for ensuring that you always get/set the value as a string. Otherwise, you might encounter strange errors from the "plumbing" of JSDOM, such as not being able to use .split() if the value is a 'number'.

Now, this does not really "fix" the problem, as other commentary around .innerText points out the whole layout concerns with that property. So this should be treated as a "workaround" that's only intended to mess with simple string content of .innerText (and it's not bullet-proof, as it assumes no nested DOM elements in the HTMLElement you would be modifying.