Add drafted content for 'Building your own JavaScript components'

[romaricpascal]

Important

This PR should only be merged after the next release of GOV.UK Frontend v5.

Adds the documentation for the public JavaScript API parts implemented so far, which help you build and initialise your own components.

Fixes #467

[netlify]

✅ Deploy Preview for govuk-frontend-docs-preview ready!

Name	Link
🔨 Latest commit	2a892c5
🔍 Latest deploy log	https://app.netlify.com/sites/govuk-frontend-docs-preview/deploys/67079eb676262600091cb093
😎 Deploy Preview	https://deploy-preview-468--govuk-frontend-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[romaricpascal]

@calvin-lau-sig7 This looks like a remnant from before we had the section explaining how to implement static properties. I think we can drop it and just have the example following the list.

[romaricpascal]

Oh sorry, I mean dropping the whole sentence altogether rather than trying to reduce it. It use to be:

If your project supports native static properties

<CODE EXAMPLE>

Otherwise

<OTHER CODE EXAMPLE>

Because it applied to many code examples, we added that first 'Defining static properties' on components and wrote all the examples with the native syntax, making sure there's a link to the 'Defining static properties' section when we introduce a static property (for the moduleName here, and for the elementType in 'Customising the expected type of the root element').

I was thinking that because of that the sentence can be completely removed.

Suggested change

If your project supports native static properties, the `moduleName` property can be defined as a native static property:

[calvin-lau-sig7]

Ahh yes, sorry I misunderstood.

Sure, that's fine. Though I'd suggest moving the bullet list after the example, to make a better intro for the example and it's clear what it's showing. I'll make a suggestion.

[romaricpascal]

Is it worth putting the message in a blockquote, or maybe at least on its own line to avoid the '<NAME_OF_YOUR_CLASS>' part going awkwardly to the line?

Here's how it looks like with a blockquote:

Here's how it looks like as its own paragraph (quotes courtesy of the <q> element):

[calvin-lau-sig7]

I'd just put it as its own paragraph here – this quote is an interesting one, because it's showing a message to look for, rather than something we want the service team to tell the user (the usual reason we put things in quotes).

[romaricpascal]

this quote is an interesting one

As in 'we should keep it'? Hadn't seen the next suggestion, sorry.

[calvin-lau-sig7]

Okay, I've had a look through and it looks pretty good as far as I can tell!

Tech docs involve a lot of backtick styling, code snippets, etc. but everything I see looks pretty readable, and consistent with the rest of the Frontend docs.

The 2i review suggested that some of the intro paragraphs could be a bit more specific about what's happening in the examples, but @seaemsi agreed it's probably one to look at after publishing.

I'm happy to approve once we've got everything added in and reviewed.

EDIT: I'll also give a proofread this afternoon, should be just minor things like sentence flow, style, contractions, etc.

[romaricpascal]

@calvin-lau-sig7 Thanks for the edits, accepted all of them wholesale I think appart from one for which I left the conversation unresolved above.