Nice article. Small suggestion: I’d add a section about always validating form data on server side, too, as all client side checks can be circumvented by a bad actor.
Harper said:
Nice article. Small suggestion: I’d add a section about always validating form data on server side, too, as all client side checks can be circumvented by a bad actor.
Thanks, yeah this is kind of a permanent disclaimer for this topic. I’ll think about how to add it without taking away too much attention
@Winter
Maybe talk about the differences in usability vs security. Client side checks are nice for usability as the user gets immediate feedback while server side checks are necessary for security to hinder bad actors.
@Harper
Best comment! Too many people implement server only and user only finds out they made a mistake after they think they’re fully done.
Nico said:
@Harper
Best comment! Too many people implement server only and user only finds out they made a mistake after they think they’re fully done.
And the form resets. Like entirely.
@Winter
Just put a note at the top: Note: Remember that client side validation is not a replacement for server side validation.
Disclaimer: this is my own article, but I’m not promoting anything and I’m very passionate about this particular subject
There are even more “tricks” with setCustomValidity
that I occasionally use and I wish to make these techniques more common
Nice write up! We need more content like this showcasing built in platform stuff. Our industry reinvents the wheel too much!
Denver said:
Nice write up! We need more content like this showcasing built in platform stuff. Our industry reinvents the wheel too much!
Totally! There also was a time when native form validations didn’t work in mobile browsers, but thankfully those times are long gone
Well done dude, keep it up
Exactly! Just good old basics can make some cool stuff!
Sky said:
Exactly! Just good old basics can make some cool stuff!
For sure! Though my impression that these basics currently do require a “recipe” for a nicer DX, hence the article. There are actually quite a lot of nuance in the form behavior when inputs are being updated imperatively by some code
It would be nice to add an example that shows the error message below the input instead of relying on the native tooltip. It’s a bit confusing if the input becomes red while typing but you don’t know what the error is until you submit.
@Bryce
Handling how and when to display invalid states is another interesting topic. For the demos in the article, it makes sense to show invalid states as soon as possible, but for a nicer UX in real apps you need to take into account “touched” and “submitted” states for the form and per input
Custom validation > HTML5 validation