Leaderboard

I've hidden your, let's say, unconstructive post. Since I'm an actual developer who wants to see other people learn and grow so they can become actual developers, I don't tell people something that they can copy and paste into their code. I give them information and hope that they're willing to put in the time and effort into understanding what it is they're doing. So thank you for your feedback but I'm going to continue calling out instances of people writing 1990s-era Javascript without understanding what they're doing and why it isn't working. After all, there's a very simple and fundamental principle in play right here: if you're going to work with something, the least you can do is try to learn more about it. If you want something to tell you the answer so that you can copy and paste it into your code then you already know about ChatGPT, but did you also know you can do things like throw terms like "javascript onclick modern way" into Google and it'll spit out some AI nonsense of its own that is actually occasionally useful? I tend to assume people will invest time into a thread so I tend to avoid writing long knowledge-dump replies - because it's too much information at once, and also becomes sometimes it turns out to be a waste of my time - but had this thread continued, maybe it could have gone like this: Q: Okay, so I understand that onclick is just executing code, but what do you mean it isn't returning a value? The return statement is right there. A: Yes, the return statement for ConfirmDelete, but there's no return statement for the onclick itself. Like I said, it is basically a function even though it's written as an attribute in the HTML, and it's that function that needs to return true/false. Q: So is that the modern way? Returning from the onclick? A: No, the modern way is to not use any of those on* attributes and instead attach events through Javascript. As in, when the page loads you run a bit of Javascript that attaches events to whatever elements it needs to using addEventListener. Q: I read up on addEventListener and switched to using it, but now when I click the button, I get the confirmation and it still submits the form. [Insert code here.] A: That's because event handlers done through addEventListener work a little differently. You can't just return false to stop the event - the code needs to be a little more sophisticated in that it explicitly says "stop the event"... except you don't actually need that. There's another way that (IMO) is simpler to work with. Q: What's the other way? A: Instead of making the button be a submit button, make it be a regular button. And instead of making the event handler stop the form from submitting, it directly makes the form submit. Meaning instead of "if not confirmed then stop" it's now "if confirmed then submit". Which probably makes more sense from a human-being angle: you typically think about these things in a proactive way like "if I click the button then I want to get a popup asking me if I'm sure I want to submit the form" (which the new code would say) and not the reactive way of "if I click the button then submit the form, but only first after asking the user if they want to" (which the old code says). It's a subtle distinction, and admittedly not one that's relevant all the time. Q: I don't follow. What would I do differently? A: Change the button to a regular "button"-type button, keep with the addEventListener, but change your popup thing to be "if (confirmed) { submit form }". [Insert code here.] Q: That sounds complicated. Why should I do all this when I could have just stayed with onclick and returning true/false? A: Because if you ever want something fancier than the confirmation popup you have now, the onclick+return pattern simply won't work. You can only do that when the code can make an immediate determination of whether or not to continue with submitting the form. If the confirmation was any sort of Web 2.0-style modal then it couldn't return immediately and you'd be forced into this alternate scheme. You might as well get used to the pattern now so it'll be easier to remember when you need it. Besides, it's not like it's a huge amount of work, and the additional work compared to onclick+return isn't wasted because you're improving the quality of the code as you go. And quality of code directly translates into quality of life.

1. the fact that you removed my post and added a long and dull answer to a comment that you did not have th eballs to face proves you are full of sh.. 2. d umb a ss, just because somebody wants to see an example of a functioning code it does not mean he wants to copy and paste it you num bskull. Old windbags like you may make replies and say things that are wrong or not working. A working example proves that the answer is not waste of time. This is the last time I am wasting time in this idiotic gathering of knowitall windbags so save your answer for your fat as s you insufferable bore.