[v10] Add date input day, month and year options

[colinrotherham]

Description

This PR adds individual date input Nunjucks options per field

Closes #1853

Checklist

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

[colinrotherham]

I've gone with this syntax:

{{ dateInput({
  fieldset: {
    legend: {
      text: "What is your date of birth?",
      size: "l",
      isPageHeading: true
    }
  },
  year: {
    value: "2025"
    error: true
  },
  values: {
    year: "1984"
  }
}) }}

But which values wins?

We currently prioritise the items[] item.value over values so 2025 is the year value

E.g. We've had this line in the Nunjucks template for a while:

value: item.value or params.values[item.name],

So I've assumed this behaviour should stay, with values set in this priority order:

1. When items is set with value(s)
2. When day, month, or year have value(s)
3. When values is set with values(s)

We do something similar in radios/checkboxes where items[] item.checked overrides values

[frankieroberto]

@colinrotherham that priority order makes sense to me. There's also the option of not supporting day.value at all, in order to just limit it to 2 ways to set the value. But I don't think supporting the 3rd way does much harm.

For prototyping at least, I'd expect values to be set using values: data.dateOfBirth and then the day, month and year keys to be used only if you need to change the label or set the error state, or the autocomplete value (day: { autocomplete: 'bday-day } ).

[frankieroberto]

Looks good to me. This’ll make using the date input component in prototypes a lot easier.

[colinrotherham]

Thanks! Happy for this to go in v10.5.0 with icon buttons and search input?

[frankieroberto]

Thanks! Happy for this to go in v10.5.0 with icon buttons and search input?

Yep. It’s entirely backwards-compatible.

[edwardhorsford]

I agree with the base idea of this, but unsure we should immediately merge this, and wonder if we should think on it for a bit.

@anandamaryon1 any thoughts?

[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]

I like how it abstracts away lots of the code for individual items. Seems much cleaner and more bespoke.

I don't really grasp why the standalone value is still needed if each has it's own value anyway?

And not sure why we still need items if we're now naming them each as options, is that for backwards-compatibility? Or flexibility?