[Discussion] Add component small: true Nunjucks option

[colinrotherham]

Description

This PR proposes the small: true Nunjucks option for discussion

Should other modifiers be supported as flags like secondary: true etc already used by the card component?

• Radios with --inline via inline: true
• Radios and checkboxes with --small via small: true
• Button, action link, back link and breadcrumb --reverse via reverse: true
• Button modifiers --secondary, --secondary-solid etc

These are all available in the NHS.UK React components

Checklist

• Tested against our testing policy (Resolution, Browser & Accessibility)
• Follows our coding standards and style guide
• CHANGELOG entry

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[anandamaryon1]

This is testing our gov alignment…

It'd be a bit messier but we could perhaps defer to gov where the component is shared and only add flags like this for our own things, eg. small buttons.

Or, if we're diverging here, we already have the size in use for headings etc. so we could go whole hog and use that for all size options.

[colinrotherham]

I prefer size: "s" but small: true aligns with NHS.UK React components

We support secondary: true on cards, yet only the --secondary class modifier on buttons

[colinrotherham]

If this was size instead of small here's an alternative for guidance

Effectively "s" would work but "m" (default) would be intentionally ignored

size: {
  type: 'string',
  required: false,
  description: 'Size of the button – `"s"` or `"m"`. Defaults to `"m"`'
},

---

This is a bit like .nhsuk-body and .nhsuk-body-m being aliases

[frankieroberto]

I think I prefer small: true here. It's inconsistent with size: "s" however it’s consistent with the terms used in the actual CSS classes.

And I think on balance it’s better to align to CSS, to make the param names easier to remember if you already know the CSS modifier. Also may help the designer-developer handover if the terms are aligned?

[colinrotherham]

Good point, I like this thinking

Can I ask how you'd configure a hypothetical large search input?

Bearing in mind:

• Text input is large
• Primary button default size

Would you use Nunjucks to pass large: true in params, only params.input, or something else?

[frankieroberto]

Is it a cop out to suggest that that could be a separate search component (which includes both the input and the button)?

[colinrotherham]

Yeah, this PR for small: true was formed to solve that question regarding:

• [v10] Add search input component #1660

What do you think?

[frankieroberto]

Alternative idea: variant.

Eg, variant: "secondary", variant: "secondary-solid", variant: "warning", etc

One possible advantage is that it helps to imply that the variants are mutually exclusive, eg you can’t have a button that is both secondary and warning.

This wouldn't work for small though, as you can have small secondary buttons... 🤔

[colinrotherham]

Or --small and --inline radios?

Bit like some of the card combos with clickable too

[frankieroberto]

@colinrotherham yeah, variant would have to be only for mutually-exclusive modifiers. Not sure how many of those we have!

Potentially variant: "inline", small: true would work? (or variant: "inline", size: "small").

[edwardhorsford]

It'd be a bit messier but we could perhaps defer to gov where the component is shared and only add flags like this for our own things, eg. small buttons.

We're in a tricky case where the current NHS default sizings are often way bigger - and can look stupidly spacious in services. And probably a greater percentage of our stuff is (or could be?) business facing - so I see more of a need for compact variants of many things.

A separate way of tackling it could be some kind of global modifier or config - generally setting the design system in to compact mode. That's probably not incompatible with individual components supporting a size though.