-
Notifications
You must be signed in to change notification settings - Fork 328
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
Allow values for the default date input #4932
base: main
Are you sure you want to change the base?
Conversation
thinking some more, if the main value here is for prototyping, it might be better to look into an option to automatically set all Update: Here is the investigation: alphagov/govuk-prototype-kit#1316 Update 2: This approach is no longer possible in v13 due to the way macros are imported |
you could add another property to handle errors for the default case:
|
This looks good, and would resolve #1154. I wonder if the values key would be slightly more intuitive as an object, eg: {{ govukDateInput({
values: {
day: data['passport-issued-day',
month: data['passport-issued-month'],
year: data['passport-issued-year']
},
}) }} That would save people having to know which order it's in, and would also allow you to just set one or two of the date part values if needed (although this seems less likely). |
dbad55e
to
72e63ae
Compare
I've update to latest Frontend and added the |
@joelanman Thinking about this some more, having the {{ govukDateInput({
namePrefix: "passportIssued",
values: data.passportIssued,
...
}) }} The only other change needed would be to change the default for the Feels like that’d be worthwhile? |
It is simpler and I can see how |
@joelanman Thanks for your patience. These new options look pretty useful, so we'd be keen to add them to the component. Before we can merge this, though, there'd need to be:
Is that something you'd be comfortable adding? @frankieroberto Receiving a |
I think the bracket syntax has always worked in the GOV.UK prototype kit, at least for as long as I can remember. The @romaricpascal The change in the default name could come later, and still use the object format for values, which would mean having to do something like this initially, which isn't much more code over an array:
Alternatively, I guess it could make sense to support both an array and an object? (Although possibly that’s over-complicated?) One other advantage of accepting an object is that this could then set the values even if you used a custom |
Oh, good spot, had missed that
I believe that @edwardhorsford's suggestion could also work for arrays, using
Untested (and unsure of the syntax), like Ed's suggestion, but I guess it wouldn't be too terrible to look at both array and object access when rendering the item with something like:
That'd require some thorough testing around false-y values to ensure that an unexpected 0 (submitted by mistake, for example) gets handled correctly. |
It's still true that "not all backends will parse the brackets in submitted names" - the kit is only one place Frontend is used, other people could be using the components in other backends and frameworks |
Yup, we'd certainly want a review of what Node backends do in any case before changing the default name of the field (Ports being free to adapted the naming of the fields to their language conventions, like what govuk-form-builder does). |
I agree it should be considered a breaking change, even if we don't know of any services it’d affect. Using a option for the macro seems like a nice way of avoiding it being a breaking change, and then it could always become the default in the next breaking change release? |
There are two ways to use
govukDateInput
, by passingitems
or leaving that blank and getting the default Day, Month and Year that most services need.However you nearly always need to set the values, at which point you can't use the default mode, you have to set all the items individually.
This PR adds a
values
option similar to the checkboxes component, so you can keep using the default mode. This is particularly useful in prototyping, where the current approach is much more complex for non-developers.In usage this looks like:
compared to the existing approach:
It also supports errors:
compared to