In our app, we need to take two actions upon form submission. First, we perform a registration ajax event that is internal to our own app. Then, if that succeeds with a 200, we want the button they clicked to do the regular form submit thing – method=POST action=a-third-party-url.com . How can we have the button do both a our special thing and THEN a client browser visit of the action URL (with the form payload)? We are using Clojurescript, built on React and so with a virtual DOM, and want to combine the some ajax with the default behavior, as if there were a default-submit-behavior function. How can this be done?
Store the result of that AJAX request somewhere -
nil initially. Let’s call that state
Intercept the form’s submit event and check the value of
nil, prevent the default action of submitting the form and make the AJAX request that’ll store some non-
nil value in that
x and submit the form via JS.
x is not
nil, just let the form be submitted regularly.
Alternatively to the state
x, you can override the submit event listener. The default one is the one that does the AJAX request. The other one is
nil to allow the default form submission process to work.
Part of the default behavior is to send the client browser to
url WITH the payload of the form. The payload alone could be pure ajax, but it’s the user-session part that is tough. We still need their browser and payload to go there, and this is the part I don’t know how to do via CLJS or JS. The AJAX portion is old-hat bread-and-butter for us; it’s just how to do the default thing (is there a JS function for that, or is it really just perform a click on a button?)
If I understood you correctly, you can just attach the payload that you just retrieved via AJAX to the form’s submission’s payload by using a hidden input field.
If that’s not it, perhaps you can create a minimal project with mocked out backend and the relevant UI parts already there, up to the point where you don’t know how to proceed - then I can just alter that project and make a PR or send you a diff or whatever.
Ah! I see. That hidden field idea is tried and true.
We also found a solution to my original question with an answer so obvious that everyone probably thought we knew it already.
(.submit (.getElementById js/document my-form-id)) does the trick of performing the same action as clicking a submit button. So, with some careful handling of the form-id to pass it around appropriately, we can perform the submit at the time we want to, after the other thing.
That’s exactly what I initially meant by “submit the form via JS”.
Just in case - note that if you’re using some React-based UI library, you shouldn’t rely on IDs. Instead, that form should be given a ref and you should access the form via that ref when it gets populated.
I want to know more about the ids thing you mention. I’ve often used IDs as a way of grabbing things in Reagent, sometimes in form-3 components. I’ve seen the suggestion to include :key on them, but have understood that as a “to please the react library” rather than something that actually does something. But if I understand your comment, you are warning about using getElementById in case the virtual dom has not actually instantiated that thing yet, correct?
:key is completely orthogonal here.
getElementById can still be used with React, but shouldn’t. It makes reuse much harder, you have to name one extra thing and put it in the global context (all HTML elements’ IDs are global and must not be reused). There might be other issues that I can’t immediately recall.
Refs are a replacement mechanism for IDs in the React world.