fix: preserve form input values on custom form validation

[joshuagraber]

Background

See #58

Sometimes we will want to do custom validation on form submission. (See the login / signin form in data-sources). When this happens, the UX will be better if we preserve the current input values for the user, rather than clearing them on every form submission automatically.

Description

• Adds new prop resetOn to Form of type 'submit' | boolean. If 'submit' is passed, the form clears on submission. If boolean is passed, the form only resets when the resetOn prop changes to true.
• Updates Form tests
• Updates documentation

To test

1. Run the demo app, navigate to localhost:8888/sign-up-demo
2. Add a valid password in each box, but mis-matched (i.e. Password1! and Password2!
3. Ensure that on form submission, you are presented with an error, but the form input values persist.
4. Correct the mis-match
5. Click the submit button, ensure that the form data you entered is logged to the console (it's a debug log, so you may have to turn those on in your browser).

[josh-chamberlain]

@joshuagraber When I go to test, using the same password in each field, I still get an error.

In the console, I'm getting a message about cookies...relevant? edit: the message appears on page load, not form submit

[joshuagraber]

Hmm, @josh-chamberlain could you share more steps to reproduce? If both inputs contain a matching, valid (per validation currently on data-sources) password, it should clear automatically.

https://github.com/Police-Data-Accessibility-Project/design-system/assets/68428039/ccb48efb-109d-47dd-936d-4e85cfc22dc6

Not sure about the cookies, but we're not reading anything cross-site, so it must be something about the dev env. (Edit: or maybe browser extensions. Those can sometimes cause console errors/warnings as well.)

(We do want to handle that autocomplete warning though, so I'll do that next week after I'm back.)

[josh-chamberlain]

sorry about the delay @joshuagraber !

I get the same behavior whether I use the same password or different passwords.

[joshuagraber]

@josh-chamberlain No worries. Those are input-level errors, which means these are not valid passwords. The messages aren't super informative (we'll craft better ones for v2), but on this demo it's just dummy validation.

A valid password requires: 8 characters, of which: 1 Capital letter 1 lowercase letter 1 number 1 special character

I've just been using Password1!

What we're testing here is the form-level errors passed while the calling component validates any extra requirements that we can't handle with our schemas (yet, although that's not a bad idea...) on submission, i.e. that the passwords match. So no input-level errors should be there at all. Otherwise, the form is prevented from submitting.

[gitguardian[bot]]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

| GitGuardian id | GitGuardian status | Secret | Commit | Filename | | | -------------- | ------------------ | ------------------------------ | ---------------- | --------------- | -------------------- | | [9480360](https://dashboard.gitguardian.com/workspace/349891/incidents/9480360?occurrence=151250669) | Triggered | Generic Password | 34b20a0a972b03e1ccb1d3630368c174337d2299 | src/components/Form/form.spec.ts | [View secret](https://github.com/Police-Data-Accessibility-Project/design-system/commit/34b20a0a972b03e1ccb1d3630368c174337d2299#diff-481898299d8ace39333602399315f8ec5f02f2e9730e12bc61d030106393dfd0L202) |

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code. 2. Replace and store your secret safely. [Learn here](https://blog.gitguardian.com/secrets-api-management?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) the best practices. 3. Revoke and [rotate this secret](https://docs.gitguardian.com/secrets-detection/secrets-detection-engine/detectors/generics/generic_password#revoke-the-secret?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). 4. If possible, [rewrite git history](https://blog.gitguardian.com/rewriting-git-history-cheatsheet?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment). Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data. To avoid such incidents in the future consider - following these [best practices](https://blog.gitguardian.com/secrets-api-management/?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) for managing and storing secrets including API keys and other credentials - install [secret detection on pre-commit](https://docs.gitguardian.com/ggshield-docs/integrations/git-hooks/pre-commit?utm_source=product&utm_medium=GitHub_checks&utm_campaign=check_run_comment) to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[github-actions[bot]]

:tada: This PR is included in version 3.0.0-beta.2 :tada:

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: