Repeater pattern component #336
Conversation
…r remove a set of questions
… prop for other field types
…for all input types. :
New template for managing risks within GitHub, with specific fields to complete.
|
Terraform plan for tts-10x-atj-dev Plan: 0 to add, 2 to change, 0 to destroy.Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
!~ update in-place
Terraform will perform the following actions:
# cloudfoundry_app.tts-10x-atj-dev-server-doj_tts-10x-atj-dev-server-doj-app_380DB029 will be updated in-place
!~ resource "cloudfoundry_app" "tts-10x-atj-dev-server-doj_tts-10x-atj-dev-server-doj-app_380DB029" {
!~ docker_image = "ghcr.io/gsa-tts/atj-platform/server-doj:afbde7f1d70c4920d82fa504c9f73bf879af14ed" -> "ghcr.io/gsa-tts/atj-platform/server-doj:ba304df413a515b2a0522f0504b10e2825f59d2e"
id = "6246c063-6cf4-423d-812a-4bfdeb62bcae"
name = "tts-10x-atj-dev-server-doj-app"
# (17 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
# cloudfoundry_app.tts-10x-atj-dev-server-kansas_tts-10x-atj-dev-server-kansas-app_337A9CF1 will be updated in-place
!~ resource "cloudfoundry_app" "tts-10x-atj-dev-server-kansas_tts-10x-atj-dev-server-kansas-app_337A9CF1" {
!~ docker_image = "ghcr.io/gsa-tts/atj-platform/server-kansas:afbde7f1d70c4920d82fa504c9f73bf879af14ed" -> "ghcr.io/gsa-tts/atj-platform/server-kansas:ba304df413a515b2a0522f0504b10e2825f59d2e"
id = "f7c60971-bffd-4a6e-a0bb-af1191079918"
name = "tts-10x-atj-dev-server-kansas-app"
# (17 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
Plan: 0 to add, 2 to change, 0 to destroy.📝 Plan generated in Post Terraform plan to PR comment #346 |
| <button | ||
| type="button" | ||
| className="usa-button usa-button--outline" | ||
| onClick={() => append({})} |
There was a problem hiding this comment.
Do you think it'd be possible to make these submit buttons, so we could support adding/removing fields when Javascript is disabled?
I'm not really sure how we'd do that server-side...
There was a problem hiding this comment.
@danielnaab - I think that sounds doable. I can add a value to the button that would distinguish between the submit events that were triggered by the add/delete actions vs. the one the user would press if they mean to submit and finalize the form. There would need to be a check for this on the backend. What kind of data would you want for this check?
There was a problem hiding this comment.
Somehow, it'd need to be checked for in the submitForm service - forms/src/services/submit-form.ts. This might be something better done after plugin/pattern refactoring. Could we create a ticket to loop back and progressively enhance this later?
|
Wrote some better tests for the repeater component to test the add/remove feature. Changed the button in that component to submit with a value so we can do the backend part to handle the JS disabled use case. |
| <button | ||
| type="button" | ||
| className="usa-button usa-button--outline" | ||
| onClick={() => append({})} |
There was a problem hiding this comment.
Somehow, it'd need to be checked for in the submitForm service - forms/src/services/submit-form.ts. This might be something better done after plugin/pattern refactoring. Could we create a ticket to loop back and progressively enhance this later?
| @@ -10,6 +10,7 @@ import { type FormSession, nullSession, sessionIsComplete } from './session.js'; | |||
| export type TextInputProps = PatternProps<{ | |||
| type: 'input'; | |||
| inputId: string; | |||
| idSuffix?: string; | |||
There was a problem hiding this comment.
I'm a little uncomfortable passing this detail into the UI components. Is there a way we could have the repeater pattern append the suffix directly to the ID in its createPrompt function?
| const children = pattern.data.patterns.map((patternId: string) => { | ||
| const childPattern = getPattern(session.form, patternId); | ||
| return createPromptForPattern(config, session, childPattern, options); | ||
| }); |
There was a problem hiding this comment.
If the idSuffix were appended to the child IDs here, would that remove the need for the cloneElement logic in the repeater component?
There was a problem hiding this comment.
One more question. As I understand, the value of each child pattern is stored as a repeater attribute on the child pattern's session data. Is that right?
If so, I'm wondering if altering the structure of the child pattern's user data might be confusing down the road, and if it would be more clear to store user session data on the repeater pattern's session object. So essentially, the repeater's value might be something like:
[
{"patternIdA": "first row a", "patternIdB": "first row b"},
{"patternIdA": "second row a", "patternIdB": "second row b"},
{"patternIdA": "third row a", "patternIdB": "third row b"},
]
Added the repeater pattern with basic support for the available question types at the start of the sprint (short answer and radio group).
There is a bug in the form submission side where the thank you page flashes briefly, and then re-renders the form fields with the user input, so the summary table on the results page was turned off for now.