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

andlbrei commented 6 days ago

🚀 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 commented 6 days ago

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

andlbrei commented 6 days ago

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.

tujoworker commented 4 days ago

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 commented 4 days ago

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 commented 4 days ago

propagateErrors maybe? or forwardErrors?

tujoworker commented 4 days ago

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 commented 4 days ago

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?

andlbrei commented 3 days ago

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 commented 2 days ago

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 commented 2 days ago

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?

dnbexperience / eufemia