Components in scope for this gem

[tijmenb]

For visibility, @peteryates, @tvararu and I had a discussion on the DfE Slack about the scope for this library.

The consensus (I think) is that this library lives along side other projects that enable developers to build applications using the GOV.UK Design System. For forms, there's govuk_design_system_formbuilder, which means that form elements are out of scope for this gem. We suspect that some GOV.UK Design System components like tables might be too complex to be built nicely using ViewComponent, and would benefit from a custom DSL.

This is a quick list of components and whether or not they're in scope. Feel free to edit & comment.

Component	In scope?
Accordion	Too complex? Maybe in 2 components
Back link	Yes, in scope for this gem
Breadcrumbs	Yes, in scope for this gem
Button	No, part of form builder
Character count	No, part of form builder
Checkboxes	No, part of form builder
Date input	No, part of form builder
Details	Yes, in scope for this gem
Error message	No, part of form builder
Error summary	No, part of form builder
Fieldset	No, part of form builder
File upload	No, part of form builder
Footer	Yes, in scope for this gem
Header	Yes, in scope for this gem
Inset text	Yes, in scope for this gem
Panel	Yes, in scope for this gem
Phase banner	Yes, in scope for this gem
Radios	No, part of form builder
Select	No, part of form builder
Skip link	Yes, in scope for this gem
Summary list	Yes, in scope for this gem
Table	No - too complex. We may create a different gem.
Tabs	Yes, in scope for this gem
Tag	Yes, in scope for this gem
Text input	No, part of form builder
Textarea	No, part of form builder
Warning text	Yes, in scope for this gem

[tvararu]

I agree, and:

Perhaps if only accordions and tables are the "one-offs", they should still live under this gem, but can be implemented without ViewComponent (to make them easier/ergonomical to use) and could have different semantics / a separate section in the docs.

I like the idea of minimising the number of "micro-dependencies" that each have their own Gem publishing pipeline etc. It would make it easier to keep everything in sync when govuk-frontend releases breaking changes.

[peteryates]

On this point, there are several other patterns I've noticed on just about every project that uses the design system.

For example, lots of projects implement their own #govuk_link_to helper (along with similar #govuk_mail_to and #govuk_button_to siblings).

Is there a place for the too? Perhaps in another gem if there turn out to be more than a handful.

[peteryates]

Also, there's a discussion on the ViewComponent issues about extending content areas to be more useful. It sounds like the push is to allow #with to be called multiple times, which could make things like the Accordion achievable in a nice way, perhaps something like this (in slim for brevity):

= render GovukComponent::Accordion.new do |accordion|

  = accordion.with(:item, title: "The first tab") do
    h1 First tab content
    p lorem ipsum sit ....

  = accordion.with(:item, title: "The second tab") do
    h1 Secondtab content
    p lorem ipsum sit ....

Clearly, it's not ready yet but worth considering when (if) the functionality lands

[aliuk2012]

I think Button should be part of this gem. If you look at design system implementation you can have a link styled as a button eg. Start now "button" which is really just a link. We might also want to style that "button" in various states. If you look at govuk-frontend nunjucks api (see macro), the developer can just pass in isStartButton: true and the component will output a start button link rather than a button. Under the hood you could use link_to etc.

[peteryates]

I'm closing this one now. The listed components are present and have been incrementally improved.