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

Add configuration helpers to the public JavaScript API #5373

Open
22 of 36 tasks
romaricpascal opened this issue Oct 3, 2024 · 1 comment
Open
22 of 36 tasks

Add configuration helpers to the public JavaScript API #5373

romaricpascal opened this issue Oct 3, 2024 · 1 comment
Assignees
Labels
epic Epics are used in planning project boards to group related stories javascript

Comments

@romaricpascal
Copy link
Member

romaricpascal commented Oct 3, 2024

Brief

Design and document a public API to enable components outside of GOV.UK Frontend to receive a configuration in the same fashion the components from GOV.UK Frontend do.

This will allow further code sharing between code from GOV.UK Frontend and that of services or other Design Systems, leading less duplication in the compiled bundles sent to users, as well as avoiding to recreate a solution to the problem for services and other Design Systems.

This will also open the door to offering helpers for internationalising components, which we could start looking at as a stretch goal towards the end of the epic if time allows.

Relevant links

Epic lead

@romaricpascal

Driving role(s)

@seaemsi , @patrickpatrickpatrick, @Izabela-16

Further detail

Publish new API

  1. patrickpatrickpatrick
  2. javascript
  3. documentation javascript

Dev

  1. domoscargin patrickpatrickpatrick
    romaricpascal

Documentation

  1. romaricpascal
  2. documentation
  3. documentation
  4. documentation
  5. javascript

Community

  1. domoscargin
@romaricpascal
Copy link
Member Author

A couple of thoughts:

  • Not all components accept a configuration, so we need the feature to be composable rather than baked into the Component class that all components will inherit, and especially able to be tree-shaken if not used. If some steps in the feature are optional, it'd be neat if they can be tree-shaken when not used, as well. However, there'll be a balance to strike between something monolithic that encapsulates all steps, ensuring they run in the right order, and something more fragmented leaving it to the user to run each step but where unnecessary steps can be left out of the bundled code.
  • Some of our components do validations on the configuration they receive. We'll need to check how costly it would be to offer this as part of the public API as it could quickly spin into lots of Kbs that services can already use a 3rd party package to handle themselves (we have to implement ours to remain dependency free for now)
  • Most components do a straightforward merge of configuration options from their defaults, HTML dataset and constructor argument. The Character Count needs to do some overriding which we'll need to account for.
    • I think that's the only component with such shenanigans in GOV.UK Frontend, but it's worth a double check
    • Components outside GOV.UK Frontend may need a similar thing where the presence of one or multiple options in the constructor argument may mean some option(s) from the defaults or HTML dataset need clearing up.
  • as always, we'll be the first consumer of our feature, so it's good to look at the components in the Design System and see if any can be configured one way or another (the Cookie banner looks like it could)

@patrickpatrickpatrick patrickpatrickpatrick self-assigned this Oct 16, 2024
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
Status: No status
Development

No branches or pull requests

2 participants