You can split the validation in multiple functions/modules which you can then use both at submission or per step/page.
Also, it seems you're implying having two validation systems (on the client and server) is actually good?
You can split the validation in multiple functions/modules which you can then use both at submission or per step/page.
Also, it seems you're implying having two validation systems (on the client and server) is actually good?
You want to validate on the client side because it reduces latency and improves responsiveness.
You want to validate on the server side because you cannot trust the fucking client.
And I'm not saying you should be only validating on submit when using HTMX.
Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument.
Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the validity of a password.
The solution to that problem is to debounce or throttle your error messages. That allows you to report validation issues to the user quickly, but not overwhelmingly fast, before sending a network request potentially across the Earth and back.
Note that frontend forms libraries allow a lot of choice over when to show error messages.