Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide and document our JavaScript conventions for components #1722

Closed
4 of 5 tasks
Tracked by #1389
hannalaakso opened this issue Jan 30, 2020 · 1 comment
Closed
4 of 5 tasks
Tracked by #1389

Decide and document our JavaScript conventions for components #1722

hannalaakso opened this issue Jan 30, 2020 · 1 comment
Labels
epic Epics are used in planning project boards to group related stories javascript

Comments

@hannalaakso
Copy link
Member

hannalaakso commented Jan 30, 2020

What

Decide and document our JavaScript conventions for GOV.UK Frontend components. At the moment, our JavaScript has some undocumented conventions (e.g: init methods) which we should document. We should also think about conventions that we don't have in place yet, for example:

  • public vs private methods
  • conventions for triggering and/or listening to events
  • managing state

We need to keep in mind that these conventions should work for future components we build, especially more complex ones like modals. Modals have more unique functionality, e.g: how do you initialise/manage more than one per page; how do users hook into the open/close?

Why

In our component JavaScript at the moment, we don't have a concept of private vs public methods. Doing this will:

  • make it possible for users to control some behaviour of components from their application (e.g: Character count message does not update when textarea is updated programmatically #1677)
  • make it easier for users to understand which JS methods/variables it is recommended they access in their application script.
  • make it easier for us to understand which changes to our JavaScript will affect users and which changes should be considered breaking ones

Having any 'accidental'/unintentional conventions documented will mean we're more likely to follow them in future when building new components or making changes to existing component JavaScript.

Related issues

Who needs to know about this

Developers; Tech Writer

Done when

@hannalaakso hannalaakso added the epic Epics are used in planning project boards to group related stories label May 11, 2020
@vanitabarrett vanitabarrett changed the title Have a JavaScript public API for components Decide and document our JavaScript API conventions for components Feb 28, 2022
@vanitabarrett vanitabarrett changed the title Decide and document our JavaScript API conventions for components Decide and document our JavaScript conventions for components Feb 28, 2022
@36degrees
Copy link
Contributor

Closing, although we should make sure we're including this as part of our 'done when' criteria other JavaScript related work

@36degrees 36degrees closed this as not planned Won't fix, can't repro, duplicate, stale Apr 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Epics are used in planning project boards to group related stories javascript
Projects
None yet
Development

No branches or pull requests

4 participants