Error message from field on a manual location?

[Tim-Wils]

Is there currently a way for field errors to have a manual/custom position somewhere in the template?

Question and use-case
We have a donation form with a hidden field that contains the final amount (value is filled with AlpineJS logics).
We have a added a custom validation rule that works minVal:1, so that someone should be seeing a message that the value should be a minimum value.
This error message is not shown, because it is directly below the hidden input and that field is being set to display:none by us, because the field should not be in the flow of the visible form-elements.

Is there a neat way to move the message/error-position to another location (without changing templates)?

Idea
Alternatively I think it would be a great idea to have error/message-field that could be dropped in the editor to -let's say- somewhere in multipages (page1, page-2 etc). Default is that this field is showing all the validation errors, but if you edit the settings of this field you can choose which fields you want to show in the error/message-field.

[engram-design]

It's probably not a good idea to include validation on a hidden field for this reason, as the error message won't be seen. There's not really a way to move an error message at the moment. What Formie version are you on? Client-side validation varies between Formie 2 and 3.

I'm not a massive fan of introducing another field just for the error message of another field, sorry! Even if this were a summary of all errors for the form, I'm not quite sure how useful it'll be for most people. I can certainly see the benefits here in this case, but that's nothing a custom field couldn't achieve (you could have the field loop through submission.getErrors() for example and list them).

[Tim-Wils]

Thanks for your points and opinion, appreciate it!
We're still on Formie 2 with this project.

I like the idea of creating a custom field that's showing the error messages that we wish to show at a given position. You're saying submission.getErrors() would be a start. Does Formie 2 have that functionality in a JS/front-end function too, like formEl.form.formTheme.validator.getErrors() ?

More info on this: For performance reasons (hundreds of submissions per minute) we're submitting a multi-page form only at the last step, but we validate every page in the front-end on 'next page' (which works great). For that reason I would like to make the custom field work with submission.getErrors() and a front-end getErrors().

Edit:
FYI: Just thought of another use-case where a error-field like this would be useful (I know there's a date field, so this is a pure practical example): a row with small fields for an enddate day/month/year.
Because of the messages below those fields would be to large to show below the fields, a general row>eror-field below those field that shows 'Date is not valid, it should be after the start date'

[engram-design]

Gotcha, makes sense!

The client-side validator (bouncer.js) doesn't have a collection of errors. But are you calling that validation on-demand like:

const invalidFields = formEl.form.formTheme.validator.validateAll($form);

or similar? If so, this returns the invalid fields. Anything more than that and we'd need to alter the validator behaviour to accommodate for this. In Formie 3 validator.getErrors() is possible.

Using submission.getErrors() is only going to work in Twig, which isn't going to be applicable here for your use case.

You almost don't need a custom field - you could use another Hidden field, or even a cosmetic field (Heading, Section, etc) and just include JS to render content in that field with the errors for the form.

I see your point in that example, and needing to provide a means to control the error location. It's not a common pattern I've seen in any other form builder out there, so will give it some thought!

[Tim-Wils]

Again, thanks for your answer!
Agree with you that it's not a common form-builder pattern, but it gives you so much more control (optionally) to make the site user experience better :)

I think I will go with the 'cosmetic field + some js' for now.

And thanks for having an open mind about it.

[engram-design]

Appreciate the feedback and ideas, certainly taking it onboard!