description of checkout events accurate?

freshjonesfreshjones Member
in Help edited August 28
The following event descriptions on your website are very confusing to me

checkout-submit: Called when the checkout is submitted
checkout-submit-enable: Triggered when the checkout button is set to enabled (when all fields are completed and errors are handled).
checkout-submit-disable: Called when checkout button is disabled due to errors

particulary the enable and disable. to me it reads like enable is called if there are no errors, and disable is called if there are errors, when it does not appear this is the case...the checkout-submit-disable event is always called first out of these three, just after the submit button is disabled after being clicked (irregardless of whether or not there are errors on the form), next checkout-submit is called, and then assuming the form could not be submit, checkout-submit-enable is called (ONLY if there are checkout errors), right after the submit button is re-enabled so the user can correct and attempt a re-submit.

is this accurate? its important to me because I'd like to know the best way to determine if a form has errors or not when the submit button is clicked.

I'd also love to know how i might disable the form button completely until the form is free of errors, and only then enable it, this seems nicer than allowing it to be clickable, only to find out I missed a requirement.

thank you



Comments
  • fc_adamfc_adam FoxyCart Team
    @freshjones,

    Great question - you're right, those descriptions are misleading to their true actions. I've just updated them like this:

    checkout-submit-enable: Triggered when the checkout submit button is re-enabled (if a checkout submit attempt is stopped due to validation errors).
    checkout-submit-disable: Called when checkout submit button is clicked, disabling the button and triggering validations to run.

    In our original planning, the descriptions were what was intended, but unfortunately we missed updating their descriptions when their purpose changed.

    The enable/disable events there are triggered whenever the submit button is disabled or enabled. When the submit button is clicked - we disable it to prevent the customer clicking it again, which triggers the checkout-submit-disable event.

    If after validating the checkout there are errors present, the submission is stopped and the checkout submit button is enabled again, triggering the checkout-submit-enable event.
    is this accurate? its important to me because I'd like to know the best way to determine if a form has errors or not when the submit button is clicked.
    With the above in mind - you should be able to trigger off of checkout-submit-enable as an identifier that a checkout submit event failed to proceed. You can also check the FC.json.messages.errors object to see if any errors are present too.
    I'd also love to know how i might disable the form button completely until the form is free of errors, and only then enable it, this seems nicer than allowing it to be clickable, only to find out I missed a requirement.
    Initially - the checkout submit button can't be disabled as at that point we don't actually know if a customer has completely skipped a field or not. It acts as the final validation to look for any of those kinds of fields. After they've clicked the checkout button and triggered validations, you do have a better idea of the number of fields that were missed at that point. Again though, the customer could make a change to their checkout (for example checking the box to specify a different billing address) and again miss a required field completely - so the final checkout validations would again be needed to catch that.
  • ok thanks for clearing that up, i am using checkout-submit-enable but I wanted to make sure I was using it correctly. thanks
Sign In or Register to comment.