Throw ElementError for missing elements during Character count instantiation

[romaricpascal]

Adds two errors thrown when:

• The textarea is missing or not an HTMLTextareaElement or an HTMLInputElement
• The textarea description is missing (preventing the component to replace its content with the live count)

Closes #4125

[github-actions]

📋 Stats

File sizes

File	Size
dist/govuk-frontend-4.6.0.min.css	118.07 KiB
dist/govuk-frontend-4.6.0.min.js	47.1 KiB
dist/govuk-frontend-ie8-4.6.0.min.css	79.27 KiB
packages/govuk-frontend/dist/govuk/all.bundle.js	77.38 KiB
packages/govuk-frontend/dist/govuk/all.bundle.mjs	72.69 KiB
packages/govuk-frontend/dist/govuk/all.mjs	3.84 KiB
packages/govuk-frontend/dist/govuk/govuk-frontend-component.mjs	359 B
packages/govuk-frontend/dist/govuk/govuk-frontend.min.css	120.45 KiB
packages/govuk-frontend/dist/govuk/govuk-frontend.min.js	37.65 KiB
packages/govuk-frontend/dist/govuk/i18n.mjs	5.83 KiB

Modules

File	Size
all.mjs	68.79 KiB
components/accordion/accordion.mjs	21.91 KiB
components/button/button.mjs	4.7 KiB
components/character-count/character-count.mjs	22.02 KiB
components/checkboxes/checkboxes.mjs	5.68 KiB
components/error-summary/error-summary.mjs	6 KiB
components/exit-this-page/exit-this-page.mjs	16.61 KiB
components/header/header.mjs	3.83 KiB
components/notification-banner/notification-banner.mjs	4.54 KiB
components/radios/radios.mjs	4.67 KiB
components/skip-link/skip-link.mjs	3.73 KiB
components/tabs/tabs.mjs	9.07 KiB

View stats and visualisations on the review app

---

Action run for 808f7ec

[romaricpascal]

Looks like we'll have to port the tests currently run in JSDom to Puppeteer. Even after adding an element for the textarea description, appending the markup to the document (so document.getElementById matches), cleaning it up between tests, we run into the lack of implementation of innerText from JSDom (hadn't seen this coming 😊 ) .

[colinrotherham]

@romaricpascal Any quicker fixes to avoid innerText? So we don't lose code coverage

[romaricpascal]

Digging a bit, we're using innerText to support IE8. I'll switch back to textContent and that should allow us to keep the tests in JSDom (I'll tidy the other occurences of innerText at the same time).

[romaricpascal]

I think it's properly ready for review 😊

@domoscargin The removal of the quotes has a tiny bit of overlap with the tests you may be writing for the Tabs. It should be fairly easy to update with a search and replace for an instance of "(.*)" and of type "(.*)" once merged. Equally, we could be leave it until we've got all the errors and tidy up their wording, keeping the quotes for now. Not fussed either way, let me know what you'd prefer 😊

[colinrotherham]

With (potentially) multiple textarea components on the page, how much do we worry about scoping selectors against their module?

[colinrotherham]

Linking with #4263 (review)

For these "module child" selectors it could be brilliant to show a scope that the browser can inspect

Suggested change

	identifier: '.govuk-js-character-count',
	identifier: '.govuk-js-character-count',
	scope: $module,

[romaricpascal]

🤔 Yeah, that's probably the component most likely to be on a page multiple times. We recommend to start with a single question per page so that limits the risks. It doesn't completely avoids the possibility of multiple of those on the page (especially if we consider the radios/checkboxes potentially revealing fields). That said, there shouldn't be too many of them on a given page that it's tricky for developers to find back the one that's wonky (either by looking carefully at the page or breaking on error in the devtools). I would say it's not something we should not worry too hard about at the start. We can always dig deeper if we receive feedback.

If we have a simple solution, though, not against adding extra information, but it might be tricky to add that consistently. The element with data-module does not really have anything identifiable usually. Here, the $textarea could provide an id (but only if it is on the page so nothing if it doesn't exist).

[romaricpascal]

Whoops, there wasn't your second message when I started writing mine, sorry. How would users access the $module you propose passing as $scope (it's fine if that part still needs looking into)? Do browsers log extra fields from the errors? the cause maybe, in browsers that support it (that'd be neat)?

[colinrotherham]

One to investigate. Would be amazing if you could hover over scope and it highlighted the element

Can leave them off for now if we don't need it

[romaricpascal]

That'd speed debugging indeed, but let's see if people come back needing more pointers to where things happen as I think that'd need a good bit of investigation 😊 Had a quick glance at cause, Firefox logs it (only if the element itself, if an object, you get Object {...}, not expandable), not Chrome, nor Safari (at the time of this message). We could always override toString to log before the message gets computed for display in the console, but seems quite hacky anyway 😆

[romaricpascal]

Sorry, not the clearest blurb. I'll (try to) clarify:

• I'd prefer leaving it off until we have the need for it as it'd require more investigation to make it work
• Got curious and gave a quick check at where Error's cause are logged (no luck there) and tried a quick hack by overriding toString to log before the error message gets computed (can log the element, but a bit hacky).

[colinrotherham]

No don't worry, the confused face was wondering why cause wasn't logged

One for another day (and don't want to be Chrome specific) but some nice ideas in:
https://developer.chrome.com/docs/devtools/console/log/

[colinrotherham]

It works 🙌