User Feedback UI - Toasts, Flash, Validation

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming again hot. Here is Wes, Barracuda, Boss, and Scott

Welcome to Syntax. In this Monday, hasty treat, we're popping up into your inbox to talk about Toast messages.

Talk about flash messages. Talk about user validation.

All the types of things that you need to know about giving your users proper Feedback for when something happens in your application.

Hey, everybody. Excited to talk about flash messages, toast messages, and whatever other type of messages will pop it. Oh, whatever message will pop up.

Well, let's get into it. You know, I I think the the first thing you have to know about this type of stuff is These things really come into handy, 1st and foremost, when you need to alert the user of something that's going on. But unlike an alert or like a modal or a popover type of deal, those things typically, like, really take the focus Away from whatever you're doing. Right? They they go in front. They maybe like a modal prevents click on anything else, And it, like, really sits there on top of your application.

Where these types of things like a user feedback, toast, or Flash message or even validation from a form. They're typically enhancements or they're they're Suggestions. They're little dings. Right? You're walking through the airport and you hear a ding ding ding, you know? Yeah. That that's what they're there for. Yeah. It's it's funny that a lot of websites don't have a good UI for telling you

when something was successful.

The big one for me is that so many websites use the WordPress contact form 7 plug in.

And that one is you fill out the entire form, you click on submit, and then the whole thing just blanks out. And you go, shoot. Did it did it send? And you have to scroll all the way to the top and realize there's a tiny little message up there that says we have submitted it. And, like, I don't know what it is about contact forms on sketchy websites, but I just never feel like this is actually gonna get to the person That needs it. You know? Like, do you get that feeling as well? Yeah. Especially

if I submit a form and something funky goes on or something That is not crystal clear what has happened.

Yeah. You do just you're it's like have you ever had a situation where you put, Like a letter in some sort of a, you know, mailbox, and you're just like, I don't know if anybody's checking this thing. This is just going into the ether. Yeah. Yeah. Just like, okay. I was actually thinking about that the other day, how amazing the mail is. For,

what, 80¢ or whatever a stamp costs, You can put a little piece of paper in a metal box that they're literally everywhere.

Someone's going to figure out how to get it To the other person, the mail is amazing. Like, if you were to if you were to propose the mail today as, like, a start up, there's no chance that that would Anybody would say that's a good idea. We have to build this massive infrastructure. Yeah.

You know, you wanna hear what my most embarrassing moment along these same lines? This is this is actually very embarrassing for me to tell on the podcast, so buckle up, folks.

I was depositing a check once Into an ATM. Have you ever deposited

a check into an ATM? Oh, yeah. Yeah. Quite a bit, actually. I haven't done it in Maybe a year or so, but when I was doing, like, contracting and and whatnot,

I would get checks all the time in the mail. Yeah. I always just went into the branch and would fill out the deposit form and everything.

Well, I I went to I think the bank was closed or something, and I really needed it to at least get it Out of my hands and into the box Yeah. And I filled out all the form and I did the ATM thing.

And I didn't see that there was, like, a You know, like, this this part that opens up that you're supposed to put it in, and I just shoved it into what I thought was the deposit spot. But it was really just a crack In the ATM machine, I just slid it right in there, and I was like, why is this not going in? And I pushed it in, and it it, like, got pushed into the ATM machine. So No.

Like, the moment after I did it, the little door opened up or something. Like, you meet and I was like, Shoot. I'm such a dummy.

It's my 1st time doing it. I was a a teen, and then, I had to call a bank, like, the next day and be like, hey. I put the check, Like, into the machine, and they're like, alright. We'll have somebody open it up and try to fish it out.

Very embarrassing. That's hilarious. Yeah. We, are I won't talk too much about checks, but Yeah. We have, like, you can do it via the app now, which is really nice. So in the rarer time I do get a check anymore, you can just take a photo of it. And, like, my health insurance still sends a check us. To reimburse me for the dentist, which is nice because they're not connected to my dentist, and I love it because I pay with my credit card. And then they send me a check to reimburse me so I get all the credit card points on all that dentist work.

Let's talk about, Toast messages, though, and and success messages.

You wanna tell your users something happened, success error. Just I guess, like, I guess there's a couple different kinds. Right? There's a success, which is generally the green. You have an error, which is red, and then you just have, like, a yellow. What do you call that? Like,

Neutral? Just Do you know what I use for neutral? I use blue for neutral. That's nice. Yeah. Yeah. Just like Yeah. It happen. I think of blue as like an info. Info. So, like, the way I think about it is, like, red is bad, green is good, blue is, hey, is here's something you have to know. And then for me, yellow is it's a warning. It's like this is a problem, but it's not a disaster. I'm just looking at Bootstrap,

Which is where we got a lot of these colors from.

Blue is primary alert.

Gray is secondary.

Green is obviously a success. Red is danger.

Yellow is warning. So you're you're right. You're right in not using yellow.

And then like a a greenish blue is an info.

That is kinda interesting. So those things need that many. No. If you're if I'm being honest, I don't think you need that many different ones.

I don't think so either.

So you have all of these messages, and how do you get them to your actual user? There's kind of 2 ways to do it. Most likely, if you have built the app in the last 5, 6, 7 years, you're going to be using what's called a toast message Because a lot of your communication to your server is going to be done over Ajax fetch requests. Right? And when you send something, generally, what you get back from the server is some sort of success or error message. And then you, in your client side code, can parse that out and throw that into a Toast message, and that will Generally, you have some sort of dispatch system that you can use to say, like toast. Show. I'll let Scott talk about the one that we're using in the new syntax website because it's pretty sweet.

On the flip side, if you're doing everything on the server side, There's a concept of flash messages.

And a flash message is essentially whenever something happens on the server side, You can simply just say session dot flash, and you will throw a message onto the user's session.

And then when the next page loads, what comes along with the page load along with all your cookies and everything like that is a list of all of the Flash messages, and then you can part of part of what you do when you do your server side rendering of the page As you check and see if there are any flash messages that need to be shown to the user, I actually still use that on Part of my website because my whole login system is still just it's just it's just forms, And they're all server rendered, right? And in order to tell the user if they successfully signed up, if their Email address is already in use if like there's, I don't know, probably 15 different possible success or error messages that need to be shown to the user.

You just flash it. And then the next page load because you're doing full page reloads that you you render out all of the messages to your user.

Yeah. Yeah. And then that's really the the key bit there is that at the end of the day, you know, the user needs to be alerted to what's going on and whether that is coming from a JavaScript based validation or a server side based, message from, you know, not using, fetch to do your your call. Yeah.

At the end of the day, you just need to let your users know If the responses come back from whatever you're doing as a success or failure. Yeah. Because if you click Submit or send or anything on anything, and it doesn't let the user know they're gonna be upset. So whether or not you're you're using Client side frameworks to do this stuff or just straight up normal form validation or anything like that or straight up form submission Server side. So let's let's talk some, Toast best practices. And, Toast is gonna be the one that you see very commonly these days considering so much of what we do is Built in a client side JavaScript way or even the types of requests that we're doing like you mentioned. So a toast message, you know, I don't know where was the 1st time you ever came about the terminology toast, but, a toast message is called that because it pops up. You know, old school toasters and the current toaster that I use today, you put toast in, you push the button down, and then it cooks it vertically. And when it's done, it pops up. Oh, that's why it's called a Toast message. Just like Toast.

Yeah. And my first my first interaction with the word Toast was from Android development. That was the 1st time I saw it being referred to as a Toast message. Really? It always struck me as being odd.

Yeah. It was I was like, that's weird. It. I wonder what the origin of the Toast message is.

Like, somebody came up with this UI pattern to say, Alright. At any given time, we need to be able to overlay messages to the user, and it's not always ideal to try to Stick it into the page layout or the app layout. So it's it's they work great just to overlay it on top of it And just wham bam pop that toast right in front of there. I was gonna tell you my toaster at home is like It's it's juiced or something like that. I don't know what what it is, but when our toast pops up, I can, like, put my hands over top and grab it when it's in the air.

Oh, nice. Yeah. It's just got noss in it. Yeah. I was gonna yeah. I was gonna say wham bam, get that toast fam. I was trying to get, like, a little what? Yeah.

Yeah. So okay. Let's talk Toast best practices here, because a Toast message, they could be invasive. They can be annoying. They can be obnoxious. And there's some specific apps that I I've used before that the toast messages are just annoying or not not quite what I would want. So, You know, as we stated before, you want to indicate the status of whatever the response was with color.

Because at a glance, most users probably are just looking to see a check mark or green Green success or the word success or something like that, but most people aren't giving this a serious look unless there's an error. They just wanna see that it was a success. Right?

Next one we have here is iconography.

It's likely a good idea to put some sort of icon beside it. I think between the color and the icon, You should be able to communicate that something good or something bad happened, and the user shouldn't even have to read it unless they're actually going, oh,

Let me check that on out. What what type, which icon specifically do you like to see the most in these types of scenarios?

I'd like to see. Ideally, it would be an icon that is associated with what happened. So if an email is sent, maybe a little mail icon. If something is saved to the database, maybe a big check beside it.

If something has gone wrong, like something or something has gone wrong and it will retry in however many Seconds, maybe like a red with a clock on it.

Just enough information to sort of tell me what's going on. But it. At a very basic, an x or a check mark telling me

good or not. Yeah. And I don't mind emoji for these things Either personally. No. Me neither. Just me personally. I know that's like a newer thing that people are doing just instead of using an icon set, just tossing in an emoji. But I I do tend to like like a green, or I think like a check mark for good or smiley face or frowny face for bad or an x. I like to use an x or an exclamation point for maybe a warning. That's That's pretty typical. Those are the types of things you see.

Another thing, yeah, is that you need to have, like, a clear message Within the Toast message. If the Toast message pops up and it's red and it says success and that's it, Nobody's gonna have any clue what's going on.

So you need to make sure that one, the message and the iconography and the color and just the general status of it Is, you know, going to match up, but also it's giving the user a good enough error.

One one thing I've seen Too many times, and I I'm I gotta say I'm I've been guilty of this myself and in occasion by accident is if you throw on the server and it comes back Into a toast message and you're not cleaning up that error message to be nice to the user. Mhmm.

The user might see something like you submit a form And the the toast message could come back as, like, cannot read property of undefined, you know. And that is The last type of message you'll ever want to send to a user. What you typically wanna do is step in there and and If you're logging that or or even better sending it to Sentry, right, for them to log your errors for you, That's the type of error that the developers need to see. The users absolutely are going to be freaked out by that message unless they're developers. So you need to give them just a Even just a, oops, something went wrong submitting the form is way better than cannot read property of x of undefined.

Property cannot read x of undefined whatever indicates that your s h I t is broken. Yeah. It broke.

So yeah. Yeah. There's There's kind of a delicate balance there because sometimes you see an error and it says something went wrong.

And you're like, but what what went wrong? And sometimes I open up the dev tools, and I see that there was clearly a thrown error with a good error message.

Sure. That could have been piped into it. So, like, I guess, like, you could figure out, is this something that is just like an uncaught error or or something that is just thrown not from me. Mhmm. If so, then just say, oops, something went wrong.

You could even take it one step further and put an ID Along with that, sometimes I'll do that because people screenshot it. And it's it's really easy to sort of look it up really quickly to say, oh, okay. I I see you can look up the actual error that happened and and kinda get right into it immediately. Yeah. And you know what? That's a lesson you can learn from the the big boys of

The, tech world. I mean, anytime you get an error in an Apple application app or whatever I mean, every Air has, like, a an error code along with it so that they know on their end easier what's going on, but also, you know, helps with googling and stuff It depends on what type of system you're working on. Especially if you have, like, multiple languages as well, because if somebody wants to know explicitly,

This is an error. Like I have a couple errors in my code base that I don't necessarily want to tell the user what happened, but I need to know what had happened.

And it's it's usually around some of the catches of people doing nefarious stuff. And Somebody will send me a screenshot, and I'll I'll know okay. I know what that error is, and I'll see if it was, like, a false positive or if they were trying to To goof around with something. Yeah. For sure. Now another thing is like timeouts, and and I think we can

group this with manual close 1st auto close. Yeah. Because this is one thing that you should have both of in my mind. In my mind, your toast message should be closable.

Like, if the user's impatient, I can get impatient sometimes, and they don't want this piece of UI sitting on top of their application.

There needs to be a clear close x button or whatever, or you can just click it and have it disappear. Right? I like, You know, a little x button on there because it's free. You know? It's easy to have. You just click that and and remove it, but also setting a time out. And the time out bit of it is interesting. I don't know what you would typically expect for Toast messages. Although, I would say, you know, let let somebody use it and watch them use it or just use it yourself.

But as developers, if we know what the message is going to be, We can tend to lean too too closely to the side of not having the message be up long enough. We already know what that message is. We're not having to read it for the very first time. We think it's annoying that it's up there for so long. Yeah. Making that delay way too short. Yeah. I think the

The type of message you should probably think about, should this auto close? Like, something like successfully saved.

Of of course. It's saved. Everything's good. I don't need to manually dismiss that. It should auto dismiss. But, like, I think about, When somebody buys a product on one of my courses, you say, hey, yeah, everything is good. You should you should receive an email in Within 2 minutes. That's kind of, another thing I like to do with my clear messaging. Back to the last point you have is tell people what to expect. Because, like, I was getting sometimes people would say, hey. I bought something 30 minutes ago, and I'm not sure if maybe the email is still sending. It's like, oh, no. No. Like, something went wrong. Like, you Either put your email in incorrectly or or something's down or whatever. So it's important to say, hey, what you should expect is this thing will be shipped In 1 to 2 days, you'll get an email within 2 minutes.

And I think those ones should be manually dismissed.

Yeah. Well, I'm gonna say I would probably put that information in a validation a successful validation Yeah. Step instead of a Toast message. Yeah. You're right. Yeah. If you're if you're asking me, I'm gonna always have every Toast message be auto closed no matter what. Just whatever that that timeline is

Yeah. Let's talk about multiple messages stacking on top of them top of each other. I've had this before where you hit the save button A thousand times or something's not working or or you you have to do something 14 different times, all of a sudden you've got A bunch of different toast messages that are stacking, and you can't necessarily clear them all. You sort of have to sit there and wait. So, if you Are you have to account for there being more messages than you think, and either that is scrolling or they group together or, you should be able to dismiss once and and they come down. I've seen them where they just overlap on top of each other because somebody's simply just Position absoluted it on top. So think about what happens when there is multiple messages and you should probably allow for stacking.

Yeah. You know, I definitely allow for stacking, and that's something that it's you know, I really like is that most of these modern animation libraries that exist today or even, You know, in the the situation of using a toast library, it's just something they do without you thinking about it. Yeah. I know the the one that we use, You just send a function and that's it. And then automatically, no matter what, when you send the function, just stacks the next one on top. What's your ideal position, Wes, For a toast message. I think sometimes these toast messages need to be specific to each web application in terms of, like, where they end up popping up. I think my 2 favorite spots for them would either be in the bottom right or the top center because, you know, they are kind of like little notification pop ups. And And many times when you're writing these things or libraries or or anything, they don't stick them right in the center because that would be jarring and weird. Yeah. And kind of act like more like a modal. So they're usually kind of out of the way in one of the corners or edges of the screen. I think I like top center the best,

if it doesn't get in the way of anything, the reason being because I have a massive monitor.

And sometimes if I'm full screen in something, I don't I've many times I've seen I've not I'm sorry. I've missed the the toast message because it's in, like, a whole different country, On the application UI, like it's the bottom right corner. And I updated in something in the top right hand corner, and I didn't even think to look Over there. So, like, maybe even that's something good for responsive. If your user has such a large monitor, Maybe the bottom right hand corner is not ideal.

Top center is is usually,

I think, the best for me. Yeah. Yeah. I I dig that. I I like top center as well.

One other thing is I think people are, I do this myself, is they are expecting you to be able to right swipe a notification away even with your mouse.

Because At least in the Apple ecosystem, when a notification pops up, you can click it and just swipe with your mouse or with your finger, And nothing will go away. So it's likely a good idea.

It's too bad that we don't have, like, swipe events In the browser natively because you have to you'd have to reimplement the whole swipe algorithm.

But it's probably worth it, to do something like that because a lot of people sort of expect it.

And if you try to right swipe and you end up just selecting the text inside of it. Maybe that's not ideal.

Word. Yeah. I I don't typically implement swipe on these, but maybe I should.

Okay. What about using a library? So There is a lot of Toast libraries for anything that you're trying to use, whether that is React, use, Felt. I'm sure there's a really good web components to this library as well because seriously, if if you're out there and you want A little project to learn a UI library of choice. Yeah. Really, building a toast message is a great little project.

There's enough things where you have props or, you know, attributes on this to be able to style it differently.

You have events where you're sending messages.

You have a UI bit, and typically, a toast message is pretty well encapsulated.

So, I mean, if you wanna build your own, I've built my own. Heck, I I built my own for level up for literally no reason other than, I just I just wanted to have that control over. But at the end of the day, there There's a ton of these good libraries. And my honest suggestion, if you're not looking to do it as an exercise, just use a library because there's endless amounts of of good options there. Yeah, it's a great

little exercise to build this type of thing yourself because, like, you need some sort of Array of messages, right? And you need to be able to fire off an event.

You need to be listening for those events or you could just be Checking for that array to be changed. I think you could probably even do a pretty cool one with custom event listeners where you simply just Fire off a custom event. And in the custom event, you have an object with all the data that you need, so title, status, and message.

Mhmm. It'd be pretty pretty easy to to make. There's another one, React Hot Toast. It seems to be pretty popular.

Again, these things are not where it really starts to get complicated is when you move from Toast messages into Full application notifications, which is you need to Yes. Email your user and run them across multiple devices and group them. And, like, that's That's a whole another world of hurt. We had the sponsor for a while. What was it? Magic Bell? They seem to do a really good job at that. But Just simple toast is you can just grab a library and you're up and running. The stuff that Magic Bell does is is quite a bit more difficult too because

Having any sort of notification system in my mind is a much more complex problem than just, hey, here's a message. That message goes out, Pop up a little little alert. Right? Yeah.

So so definitely like a a much harder use case there. And and I wouldn't get those 2 things. Not not even saying you did. But I as a developer, I wouldn't get those 2 things to I wouldn't look at a Toastmasters and say, oh, I did that easy. Let me build a whole notification system like Facebook Because it is, quite a bit more complex there.

What about validation? So validation is a whole another class of user feedback. And typically, this is in the realm of Forms. Right? A user submits a form.

And one thing that I've noticed is that form submitting on native versus web is very different. You know, the web oftentimes we end up having to have a save button for some reason where people just expect it. That's like the common occurrence where On native, I don't know if people really expect a save button on most, like, user preferences or anything like that. They just Type the thing and and swipe away. Yeah. And honestly, I prefer not having that little save button as well. But, You know, typically what happens with these things is you submit a form, you click the save button. It was either a success and in that case, you could Do a toast message to let them know it was success success or in the thing a situation like a contact form where you don't want them to send multiple messages over and over again, You would hide the form and put the success screen after the form was submitted there. And in my mind, that is considered The same thing as, like, a positive validation of this form. This form has been positively validated, sent, and then you're getting that message.

But the big thing about validation in in general is what happens if you submit a form and it doesn't work for some reason?

How can we let the user know what's going on and what? Well, the one thing that drives me crazy is where they have one spot to display the validation, And it's like a massive form. So it'll be like there's 1 or more errors, or they'll tell you, like, make sure your phone number has a Entry code. By the way, I was sending out the syntax t shirts and, like, at least a 100 people did not put their country code in the phone number field. So I had to go through every single one and add the country code.

Oh, you did? Yeah. Because, like, it was like it was like rejecting the send. It's like, this is not a valid phone number. I'm gonna tell you what. As somebody in the States, we, like, never put our country code. Like, I guess ours is 1. Right? Like, North America is 1.

Yeah. But I guess that's the same for other people who live in those countries. They don't put their country code in there. Maybe for Europe they do because, like, The countries are so close to each other? Yeah. Actually, you know what? I I I subscribe to a service that is European based, and their login is only phone number based login.

And they ask for my country code every single time, and I get annoyed by it. I'm like, what do you mean? Why do I do that?

But yeah.

Default to America, everybody. Yes.

What do you mean you're not an American web service? All of the services are from America.

Okay. Let's talk about form validation, what makes it good and bad. So a user submits a form. And like you said, Wes, I I get so annoyed when there's a big long form and you and then you submit it, nothing Happens and then you scroll up only to find that there's an error somewhere. Yeah. Like the messages at the top.

The big thing is that you need to to show Validation both, you know, at the full form scale as well as an individual input scale. If an if a specific input is the reason why the form has failed, that form input, In my mind, should be colored red.

Like, the it should be outlined in red. Yeah. It should have, you know, the error it. Above it, directly above it, or directly below it, either way, someplace that is easy to see in probably in red as well Yeah. Or just at least, obviously, that it's a part of the air to let you know

Exactly what went wrong on which field specifically. You know what is one kind of cool use case of the new CSS has That I've been thinking about lately is if you have field sets field sets are kind of underrated. If you have like a field set is a good way to group. Totally agree. Multiple inputs. And, I'm pretty sure a field set itself can have a Invalid CSS property put on it. And any if any of the Mhmm. Inputs inside of it are invalid, then you can just, Like, it's nice. Put a little red border on the left hand of the field set so you can quickly say, like, okay. Well, I just filled out 80 different inputs.

Let me quickly scroll to the area that was it was invalid. Right? Instead of looking for 1 tiny little input, direct my attention to the field set itself.

But if you're not if you're using divs or for whatever reason or or if you're not using the the browser based validation, You could just say a fieldset has an invalid input or a fieldset has something with a class of invalid, and you can call out the entire thing. And you can even Scroll the user to the invalid field set rather than the form input itself.

Yeah. The that's a big part about this whole thing. Do not make the user guess where the problem is. I like that little bit about even scrolling to it. I don't typically like it when things jack my scroll, but, like, You you can jack my scroll when there's an error in a form. Just send me right to it. Yeah. There's there's I I have my note in here that There's nothing worse than when a form fails mysteriously.

You submitted and there it does not work. It says there's something wrong, and you're left to guess, like, which of these things Is totally wrong. Another thing I like to to say is to your best ability is to tell the user exactly what went wrong. Because I've had a situation where the this is this is a part of our, like, our onboarding to century. You know, like whenever you you onboard to a new company.

You have all these different services you're signing up for, and one of them was, like, part of the health insurance stuff. And there was, like, a form in the health insurance stuff that asked for a birth date, right, obviously. Yep. And it didn't tell you, one, it didn't tell you what format the date Should be. K. So it didn't tell you how to write the date. It didn't give you a date picker.

And if you type in a date, It just said the date is incur or invalid. Like, that was it. The date is invalid.

So tell me

What you want to do. You want. Oh, or even or worse when they they give you the date format, but they only give it to you as a placeholder.

So you have to delete the entire input so you can see what you want

or, you know what? I don't know if people with normal memories, have that problem, but definitely you and I have that problem.

I get it all the time where I'm just like, hey, month month month year. I have it. Write it down and then type it. And, like, it's just it kills me having to input. Data inputs is another we could do a whole show just ranting about data inputs.

Totally. But the other one in Canada is they often will require your postal code To be all upper case and if there's a space between the, first 3 and the last 3, Sometimes they want it, and sometimes they don't want it. So I've become a pro at being like, your postal code is invalid. I'm like, no. It's not. Like, can you just take the space out yourself, you know, like we have no one. Yeah.

Oh, drives me crazy, that type of stuff. But on on the flip side of Trying to mail like, I've mailed last time I did t shirts, it was 1400 t shirts.

The how rigid the inputs are From shipping companies is so frustrating because, like like I said, I just spent an hour and a half this morning fixing people's phone numbers.

And I was like, we should have built something into the phone number validation that made them put their country code.

You know, that would have been you would have been learn. Yeah.

Yeah.

I think that's it. Any other tips?

Oh, we yeah. We should talk about I think we'd be remiss to not mention HTML inputs. I mean, we did talk just a little bit about that, but, like, Oh, yeah. In HTML 5 and since we've been going on here, HTML has continued to add more and more input types.

Using the proper input type for whatever you're trying to do is not only going to become, you know, make your device smarter when you're typing into that field. That's a huge pet peeve of mine. You're entering a a field because the Ios keyboard likes to, you know, Show you certain keys based on what type of inputs you are.

And Android keyboards to not the same extent in a good way.

The but the iOS keyboard, if it's not showing me the the at sign because it's not expecting this to be an email or something, I'm I'm gonna lose my my mind doing that kind of stuff. But either way, proper inputs will validate themselves at an HTML level in a way that makes it so you have to do way less work.

So as long as you were using the correct input, you can make sure not only that, but also, like, required fields Can be an HTML feature.

So if you can use HTML wherever possible to validate your form for you, That can be a huge helper if you're trying to make sure that these input types are completely validated. Yeah. Definitely lean on it. The the one frustrating thing

About it is that the error messages are so awful and ugly.

Yes. You know? But there is I I didn't even realize this till a while ago. There is A JavaScript API to validate a form. So what you could do is on submit, you could run the validation and it will give you All of the errors that are available, like, there's there's a list of, like, 8 of them. It's like too short, too long.

I'm not sure what they all are, but And you could

Can you imagine getting your toes too short and too long?

I get that with passwords all the time.

Too too long of a password. Come on.

I'll post a link in this to a, you know, you remember, Shruti? Shruti Kapoor.

She does great work. She has a blog post here on freeCodeCamp about HTML 5 and JavaScript validation. That's really great. So, I'll link link to her post here. And give Shirdi a follow on Twitter too while you're at it. She's a a great speaker. Oh, yeah. Yeah. I met her at Reactathon.

She is From Toronto.

So fellow Canadian. Know that. Yeah. Yeah. Yeah. She just put out, I talked to her about a course She's putting out as well. I don't I forget what it was about. I think it was about,

like, management or something. I don't know. Check it out. Yeah. Yeah. You know? Also, you know, I just wanna say in along with that, she does show, you know, adding the event listener specifically. So if you're the type of person who wants to see some code along with some of this JavaScript For HTML validation, you know, you add the event listeners, set custom validity, check validity, those types of things. She she shows all of this in actual code. So, I'll give that host a link if you're writing some code here and you want more info.

Set custom validity.

Oh interesting, you can pass Your own you could pass your own error messages, I did not know that, with set custom validity. I'm just looking at the MDN docs for that. You gotta fill this out, yo, so you can overwrite those built in messages.

Oh, man. That's Yeah. A lot better than I had thought. Totally.

Cool. Well, that is form instant validations user feedback. Again, at the end of the day, you don't wanna keep your users guessing about what happens. So make it crystal clear. Is it good? Is it bad? Is it in between? I mean, good and bad is probably the the 2 that you'll you'll see the most here. An info message is, like, always kind of iffy because you're like, did something bad happen here? I don't know. Is there something I gotta do? Either way, let your users know what's going on in your application, Especially when they're interacting with it, and they will thank you. Alright. Thanks, everybody, for tuning in. Catch you later. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player Or drop a review if you like this show.