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 support for customising item inputs’ field names in date-input #826

Closed
wants to merge 1 commit into from

Conversation

lhokktyn
Copy link

Add support for a new item.{}.fieldName parameter on the date-input
macro. This allows the author to explicitly set the field name on each
item input rather than rely on the <param.name>-<item.name> default
convention, which is not always convenient and couples the field name to
the displayed label too tightly.

Also fix a few minor missing/incorrect parts in the date-input README.

Add support for a new `item.{}.fieldName` parameter on the `date-input`
macro. This allows the author to explicitly set the field name on each
item input rather than rely on the `<param.name>-<item.name>` default
convention, which is not always convenient and couples the field name to
the displayed label too tightly.

Also fix a few minor missing/incorrect parts in the date-input README.
@lhokktyn lhokktyn force-pushed the add-dateinput-fieldname branch from d790cdb to 98abbac Compare June 24, 2018 04:46
@kr8n3r
Copy link

kr8n3r commented Jun 25, 2018

Hi James, thanks for raising this.
It looks like an interesting amendment.

As it involves modifying what we deem as public api, we'll have a discussion how to proceed.
Will keep you updated.

@lhokktyn
Copy link
Author

Thanks for the update @igloosi.

The primary reason for its introduction was down to our particular need to have date inputs named as date[dd], date[mm], date[yyyy] so that they could get automatically parsed into an object format by our service backend (Express, body-parser), but having control over the name is useful regardless.

Secondly, it seemed that the name was perhaps being too tightly coupled with the presentation by virtue of suffixing -{{ item.name }} to the names. If we wanted these to be different, there's currently no way to achieve that.

Look forward to the outcomes of your discussion 👍

@36degrees
Copy link
Contributor

That makes sense - I can see how this change would be beneficial.

I'd like to try and avoid adding another similarly-named argument if at all possible - I don't think the distinction between name and fieldName is obvious and I think it is likely to cause confusion for users.

If we were to make params.name optional and only prefix item.name if it's set instead would that meet your use case?

e.g.

  "name": (params.name + "-" + item.name) if params.name else item.name,

Ollie

@lhokktyn
Copy link
Author

Hi Ollie. That would be perfect, and is a much cleaner api that reflects the semantic use of name in other macros. However, item.name is also currently in use by the input label so there'd remain a conflict, i.e.:

govukInput({
  "label": {
    "text": item.name | capitalize,
    "classes": 'govuk-date-input__label'
  },
  ...
})

Perhaps the introduction of an item.{}.label object that can be passed directly into the govukInput macro? ie.

govukDateInput({
  items: [{
    label: {
      text: 'DD'
    },
    name: "my-date[dd]"
  }]
})

(and default values are used if not specified by the template author)

@lhokktyn
Copy link
Author

lhokktyn commented Jun 28, 2018

It could even be made a little simpler, and align more with other components by just adding a new item.{}.text parameter for controlling the input label, and use item.{}.name as the input element's name.

This is the way it's done in other macros, such as checkboxes (https://github.com/alphagov/govuk-frontend/tree/master/package/components/checkboxes#component-arguments) and radios (https://github.com/alphagov/govuk-frontend/tree/master/package/components/radios#component-arguments)

@36degrees
Copy link
Contributor

@lhokktyn I think #857 has addressed your needs, so I'm going to close this now. Please feel free to re-open or create a new issue if we've missed something 👍

Thanks again for raising this and helping to improve GOV.UK Frontend.

@36degrees 36degrees closed this Jul 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants