Handling a form pre-submission processing – exploring some approaches
A form contains credit card details, some personal address details and some other unknown fields. On form submit, I want to:
a) tokenise the card details through an AJAX call. b) Validate address fields, some may use AJAX calls and some may use HTML5. c) If nothing fails then the form should be allowed to submit once all the
onsubmit triggers are complete. d) If any stage fails – tokenisation, validation etc. – then the form should be prevented from submitting.
I understand I can stop the form from submitting using
event.preventDefault on the submit event. However, I only want to do this if any of the triggers fails in their operation. My reasoning is that once that is issued, the only way to get the form to submit will then be to do so programmatically. The problem is, I won't know if there is some other validation rule that wants to prevent the submission, and could end up submitting an invalid form.
There could be any number of form events on the
onsubmit trigger, and they will operate in order, one after the other. As soon as any one of them issues
event.preventDefault() then I know the form won't get submitted at the end. That makes sense, is a simple concept, and works great for procedural code.
But, I want to wait until all the AJAX calls have finished before exiting the final
onsubmit event, because the moment I do, the form will submit. I want to know whether I need to issue
preventDefault before exiting.
Is there a way around this? Without shafting the CPU looping while checking the results of a bunch of promises, is there any way to just wait?
The way I see it solved normally is to issue
preventDefault right at the start of the submit event, then take control of the form submission programmatically. I would really like to avoid that, as I have no idea if there are other incomplete asynchronous things going on in that form. Or is that the only way to handle it? Is the choice of what can be done in a form submission between just (a) taking over full submission control of the form; or (b) not using any AJAX or other asynchronous actions in the event?
preventDefault right at the start, which is great, so it is doing some other kind of magic.
Looking again at that magic, this is what the card tokenisation does in the submission event: It first checks if the card is already tokenised. If it is, then it exits and everything else carries on as normal. If the card is not yet tokenised, then it starts the tokenisation AJAX process and prevents the default form action by existing
false (and I realise that is a deprecated thing). The AJAX callback then checks the tokenisation details, updates the form hidden fields and the resubmits the form from the start by pushing the submit button. That way all the bound events and validation can run run again, though it does feel like cheating. It also assumes that the card tokenisation is the first event bound to the form, and that if it's not, then prior events won't mind being fired more than once, like the user clicked the submit button twice. Feels wrong, but is this the way to handle it?
Submitted August 12, 2017 at 11:30PM by judgej2
via reddit http://ift.tt/2wEiawM