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.

Sign up for GitHub

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

Jump to bottom

Deny navigation to the next step if there are open subforms on the page #4072

Open
andlbrei opened this issue Oct 7, 2024 · 10 comments
Open

Deny navigation to the next step if there are open subforms on the page #4072

andlbrei opened this issue Oct 7, 2024 · 10 comments
Labels
enhancement New feature or request

Comments

@andlbrei
Copy link
Contributor

andlbrei commented Oct 7, 2024

🚀 Feature Proposal

When the user has a subform open they should not be allowed to navigate to the next page before committing or cancelling the subform.

Motivation

We want to make sure the user is confident that the information they want to store in the form is stored, or discarded if the user does not want it there after starting to fill it out.

Example

If the user has started adding a new entry to a array, but not pressed "Cancel" or "Add", they should not be allowed to navigate away and lose the data they have entered.

Pitch

It would enhance the existing validation mechanisms of Eufemia Forms.

Notes

I do not see this as critical functionality, but it might be a good addition, depending on how much effort it takes to implement.
It might make sense for it to be a strict-mode feature.
The example mentions a Iterate.Array use case, but I see this as something that would make sense for Isolation as well.
Any subform that provides a "commit" or "cancel" action to the user.
@tujoworker
Copy link
Member

Kind of required on a Iterate.PushContainer or Form.Isolation?

@andlbrei
Copy link
Contributor Author

andlbrei commented Oct 7, 2024

Perhaps that is a good way of looking at it, yes.
The user is required to choose either the "commit" or the "cancel" action before proceeding.

@andlbrei andlbrei mentioned this issue Oct 9, 2024
Closed
@tujoworker
Copy link
Member

Currently, fields are usually responsible for informing the form when more data is needed. However, when used in isolation, they lose that capability. This feature addresses that by allowing isolated fields to pass the data requirement back to the parent form if there's an error.

  • I believe this behavior should be optional (opt-in). Do you agree?
  • What would you suggest as a prop name to make this opt-in work as intended?

@andlbrei
Copy link
Contributor Author

andlbrei commented Oct 9, 2024 •
edited
Loading

I would agree that it should be optional 👍
After you mentioned required I have a hard time thinking about anything else, but I'm not sure if that is the best name for it as this functionality is a bit different 🤔 😅 I will think about it some more.

Also, my initial suggestion here was not based on fields within a subform not validating, but rather that the user should finish the process of committing the subform to the actual form (or cancelling), so that they do not fill in data in a bunch of fields, and then forget to click "Add" to actually store the data before progressing to the next step in the form.
Combining this with what you stated in letting the subform inform the parent of validation state is also natural to do, and a very good point.

@tujoworker
Copy link
Member

tujoworker commented Oct 9, 2024 •
edited
Loading

propagateErrors maybe? or forwardErrors?

@tujoworker
Copy link
Member

tujoworker commented Oct 9, 2024 •
edited
Loading

Its actually not only about the errors.

  • When an error is passed through, then it prevents the form from submitting ✅
  • But when it gets resolve, the user may still not have committed the data.

That leads us to use a different name. Kind of back to required.

Maybe something like requiredInMainForm or validateWithFormHandler or delegateValidation.

@tujoworker tujoworker mentioned this issue Oct 9, 2024
Merged
@tujoworker
Copy link
Member

For now I think we only should support fields that are in error state.
We may add another prop that could solve the issue where data needs to be committed. But this is a complex challenge. Because we then also need to show an error, when there is user data that is not "committed".

Any thoughts on this topic?

@tujoworker tujoworker added the enhancement New feature or request label Oct 9, 2024
@andlbrei
Copy link
Contributor Author

andlbrei commented Oct 10, 2024 •
edited
Loading

I would think along the lines of what is done with the push container, to have some internal required paths in the isolated subform, that the buttons use to store a boolean, or whatever non-undefined, value to before validation. Then the value is removed ( or filtered out) after validation is successful and the data has been committed to the form.

If the user does not press any button, then the required field would cause a validation failure in the delegated validation (or whatever name we end up with there) because it does not have a value before "Add" or "Cancel" is pressed.

Not sure if that is possible.
Or what side effects it could have...

@tujoworker
Copy link
Member

We have concluded that we add this feature as prop called requireUnchanged or requireUncommittedData – any suggestions?

  • With that, we can show an error on the form submit request, in case there are changed/uncommitted data.
  • But what then also is "required" is to put a "Clear Button" side by side the "Add/Commit Button".

@andlbrei
Copy link
Contributor Author

Ok, nice 👍
requireUncommittedData sounds ok. I feel like there is a better name out there somewhere, but I can't find it 😄

When you say "form submit request" you also mean step changes I assume?
Do you intend to have Eufemia put a "Cancel" button there when the prop is present, or will it be the consumer's responsibility?

tujoworker added a commit that referenced this issue Oct 11, 2024
@tujoworker
feat(Forms): add bubbleValidation to Form.Isolation and Iterate.Pus…
880f870 
…hContainer to prevent the form from being submitted when there are fields with errors (#4103)

Partially solves #4072
tujoworker pushed a commit that referenced this issue Oct 11, 2024
@semantic-release-bot
chore(release): 10.52.0 [skip ci]
7789277 
## [10.52.0](v10.51.2...v10.52.0) (2024-10-11)

### 📝 Documentation

* **NationalIdentityNumber:** add docs about validation ([#4077](#4077)) ([51bfd80](51bfd80))
* **OrganizationNumber:** adds docs about validation ([#4078](#4078)) ([c785c51](c785c51))

### 🐛 Bug Fixes

* **Autocomplete:** Show whole suggestion list after item selection ([#4060](#4060)) ([0acf061](0acf061))
* **Field.NationalIdentityNumber:** validate on all digits(not only 11 digits) ([#4079](#4079)) ([7c34fc9](7c34fc9))
* **Field.OrganizationNumber:** should validate on all digits(not only when 9) ([#4071](#4071)) ([08a4b51](08a4b51))
* **Forms:** add support for `Form.SubmitConfirmation` inside Wizard ([#4088](#4088)) ([e1167a4](e1167a4)), closes [#4086](#4086)
* **Forms:** don't call internal `exportValidators` when they not are exported as an array ([#4113](#4113)) ([cd54ed0](cd54ed0)), closes [#4106](#4106)
* **Forms:** ensure `emptyValue` is set in the data context when defined ([#4111](#4111)) ([dcc5694](dcc5694)), closes [#4070](#4070)
* **Forms:** ensure `onBlurValidator` gets called when `validateInitially` is true ([#4069](#4069)) ([59cf6c5](59cf6c5)), closes [#4068](#4068) [#4066](#4066)
* **Forms:** ensure Field.SelectCountry has a fallback locale (nb-NO) ([#4114](#4114)) ([568229a](568229a))
* **Forms:** ensure Form.clearData works in React.StrictMode ([#4053](#4053)) ([da0c93a](da0c93a)), closes [#4048](#4048)
* **Forms:** Fix use of unpolyfilled structuredClone in useData hook ([#4108](#4108)) ([1f59f10](1f59f10))
* **Forms:** keep `Iterate.EditContainer` open when falsy value or empty object was given as the iterate value ([#4087](#4087)) ([e932059](e932059)), closes [#4046](#4046)
* **Forms:** show error on every value change when using exported validators ([#4068](#4068)) ([cab6d01](cab6d01)), closes [#4067](#4067)
* **Icon:** icon property typing should accept FormStatus icons ([#4091](#4091)) ([f49eb34](f49eb34))
* **NationalIdentityNumber:** use `onBlurValidator` instead of `validator` ([#3982](#3982)) ([0a93755](0a93755))
* **Typography:** match medium heading font size in Sbanken theme ([#4039](#4039)) ([ce50529](ce50529))

### ✨ Features

* **Forms:** add `bubbleValidation` to Form.Isolation and Iterate.PushContainer to prevent the form from being submitted when there are fields with errors ([#4103](#4103)) ([880f870](880f870)), closes [#4072](#4072)
* **Forms:** add `createMinimumAgeValidator` to Field.NationalIdentityNumber make a customizable `adultValidator` ([#4057](#4057)) ([6c20ba2](6c20ba2))
* **Forms:** add `Form.useSnapshot` hook to handle snapshots of data ([#4102](#4102)) ([d451793](d451793))
* **Forms:** add `isolatedData` prop to `Iterate.PushContainer` ([#4076](#4076)) ([ede5f8e](ede5f8e))
* **Forms:** add `isValid` to Form.Visibility for showing content based on the validation of a field ([#4038](#4038)) ([7536752](7536752))
* **Forms:** add `Iterate.ItemNo` component ([#4095](#4095)) ([c736c9e](c736c9e))
* **Forms:** add `transformLabel` to all Value.* component ([#4056](#4056)) ([d63e472](d63e472))
* **Forms:** add support for `defaultValue` (and `value`) for fields used in `Iterate.Array` ([#3987](#3987)) ([afbdddf](afbdddf)), closes [#3882](#3882)
* **Forms:** add support for `id` for when using dynamic steps with `activeWhen` ([#4093](#4093)) ([248da92](248da92))
* **Forms:** remove internal pattern from `Field.NationalIdentityNumber` in favor of the internal validator ([#4098](#4098)) ([fb35722](fb35722))
* **Forms:** remove internal pattern from `Field.OrganizationNumber` in favor of the internal validator ([#4092](#4092)) ([e829f8b](e829f8b)), closes [#4073](#4073)
* **Skeleton:** stop animation after 30 seconds ([#3479](#3479)) ([f67b3bb](f67b3bb))
* **Value.PhoneNumber and NumberFormat:** displays country code using prefix `+` instead of `00` ([#4051](#4051)) ([fb363d0](fb363d0))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tujoworker @andlbrei