This prevents duplicate form submission, #57
Ideally, make the button look nice. To be fancy, you could use animation until a server response is received.
Honestly, I firmly believe that the onus of proper form validation falls upon the end-user instead of the repository owner as it should be their responsibility to address the issues that their applications may face. The fact that you have shared a completely functional demo as well as a comprehensive tutorial is extremely appreciated and should suffice most use-cases.
Having said that, the so-called issue of handling multiple form submissions by rapidly clicking the Submit button, or otherwise, can be resolved very easily by enlisting the support of "once" event listener, which seems to have become a new standard for form submissions nowadays.
As such, I've generated PR #219 which aims to successfully resolve this issue. As ever, a live functional demo is available on CodePen to preview the effect of this one-line change. Hope this helps.
thanks for the info!
I kind of agree. The challenge of this being a tutorial, is that we have advanced features sprinkled all over, which adds to the complexity of the code, especially when not everyone wants all of those features. Even simple things like email can be checked natively in some cases but not all, e.g. older IE or Safari:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email
Thanks for including the live demo too, very nifty! Wish more of our issues/comments had these :)
I completely understand the requests of implementing additional features, such as various methods of form validation, etc. Naturally, people will be drawn towards a very useful and popular repo to suggest "enhancements" that they could very well implement themselves but would rather have someone do it on their behalf.
Personally, I think the scope of this project should be limited to focusing on the Google Apps Script, where all the magic happens. For example, the email validation could be as simple as declaring type="email", required=true for all I care. Anything else is additional baggage that the user can choose to implement themselves, if they so desire.
That's not to say that _really_ good suggestions shouldn't be mentioned/featured under "Advanced Features" of your Readme.md. However, the code itself should be seldom changed unless it affects the overall project functionality as a whole. I like your approach of creating a separate test.html page. Perhaps, you can create a few more of these to provide specific instances to demo certain "Advanced Features" instead of trying to pack as much as possible into index.html.
Hopefully, not coming across as a rant 馃槄! I'm really grateful for the work you've shared and would rather not let it be tarnished for no good reason.
I believe #236 now takes cares of this request?
Most helpful comment
I believe #236 now takes cares of this request?