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

Backlog: Normalize how optional form fields behave #123

Open
1 of 5 tasks
kitajchuk opened this issue Sep 29, 2022 · 0 comments
Open
1 of 5 tasks

Backlog: Normalize how optional form fields behave #123

kitajchuk opened this issue Sep 29, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@kitajchuk
Copy link
Contributor

kitajchuk commented Sep 29, 2022

TL;DR: Option 2 is the way to go and this is probably the functionality we want:

Option 2 (hold on to field values in case I check the box again)—but if I leave the box un-checked and save the fields should be set to null when sent to the backend. After I get the toast if I were to then toggle the zone open again the values would be empty since they were deleted on the backend. And obviously things would continue to function as they do—if the box is checked the fields are always kept and saved as expected.

TL;DR: Settings form functionality:

zoom_0.mp4

Checklist:

  • Settings form (fine as is—done)
  • Account form (needs to be converted to option 2 behavior)
  • Application form (needs to be converted to option 2 behavior)
  • Carrier form (needs to be converted to option 2 behavior)
  • Speech form (needs to be converted to option 2 behavior—can work the same as settings form but doesn't use checkzone)

Original discussion notes:

Currently we handle optional form fields a couple of ways currently across the app. Most notably there are some optional field sets on the Carrier form in which un-checking the box wipes them out of local state. However on the Account/Application forms we have optional HTTP basic auth for web hooks and un-checking the box there leaves the entered values in tact—e.g. they would post on save and persist on the backend and the checkzone would toggle open to reveal them again. The Settings form is like this last method however it saves the field value in temp state and empties the field and then replaces it since this checkzone isn't using the hidden prop. Perhaps we need to decide on an official house rule about these optional fields and normalize them all across these implementations?

If it's the case that we normalize to one style there are two viable options:

  1. Un-checking the box empties the fields that are toggled by the box. The user then has to check the box again and enter them again if they decide they want to do that. This means values are not persisted for un-checked boxes in local state and are therefore deleted on the backend when saved—even if they existed on the backend.
  2. Un-checking the box doesn't empty the fields and they are persisted in local state and saved to the backend. In this case for the Checkzones the act of saving ultimately toggles the zone back open because the fields are saved on the backend.

Option 1 currently looks like this:

zoom_0.mp4

Option 2 currently looks like this:

zoom_0.mp4
@kitajchuk kitajchuk added the enhancement New feature or request label Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant