6 ms·

I got stuck trying that. To facilitate non JS by default my products are checkboxes and the checkout button submits the form (it is a spa). This works well but

• savolai 2y ago
  I have done this in projects with POST forms: ”To avoid the resubmit warning when hitting back, use the Post/Redirect/Get pattern: after a POST, redirect with a 303 to a normal GET page. The browser skips saving the POST in history, so back just takes you to the form without complaining.”
  • skydhash 2y ago
    I thought that was the normal pattern, either rendering the form again when there's an error or redirect to the correct page in case of success.
    • savolai 2y ago
      Yeah, it's just been a while so I felt sketchy advicing something that might have changed.
• zdragnar 2y ago
  The usual way to deal with it is to respond to form submissions with an HTTP redirect to another page. The user can still hit the back button, but the scary popup won't occur. However, you run the risk of the user re-submitting the form anyway. Since this is involving orders and money, you may want the order confirmation / submit page to have a nonce or temporary ID representing the checkout session in the URL such that, upon revisiting that page, you can lookup the order status on the backend and redirect them to the order success page again.
  • moring 2y ago
    This will prevent re-submission but still be confusing for the user. Why even allow submitting when navigating back? If the order has been submitted already, the submit button should be greyed out with a message saying that the order has been submitted already. The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.
    • jpc0 2y ago
      > Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server And how would one do that without using JS?
      • moring 2y ago
        Which part exactly? Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today. Identifying the order using an ID in the URL is standard practice everywhere. When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.
        • econ 2y ago
          The must have js part for me starts where one can open the store in multiple tabs then add and remove things on the first two and check out on the 3rd tab.
    • zdragnar 2y ago
      This is why I suggested the URL for the submission page be unique- having a session nonce / token or similar. That way, once the user checks out you invalidate the checkout session, and if the user hits the back button you redirect them to the appropriate page. I specifically called out the issue of re-submitting certain forms and proposed the above solution. I don't think relying on cache headers is going to be sufficiently reliable.
• bowsamic 2y ago
  The user you’re replying to thinks the web is the wrong tool for any app