• NULLPTR (unregistered)

    <pointer>null</pointer>

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Let's prented there was no spelling error in this article!

  • Robin (unregistered)

    The bonus WTF here is that this code doesn't even do anything. Well it shows a confirmation dialogue, but it doesn't matter at all what the user selects, since you can never use the return value of an event handler.

  • LCrawford (unregistered)

    Wait, JQuery is legacy already?

  • Ltrlg (unregistered) in reply to Robin

    Not quite. The return value of the handler is used to determine whether the event should be propagated (both to other custom handlers and the default handler). Returning false probably prevents the validation of a form here.

  • Scott (unregistered) in reply to LCrawford

    Yeah, I don't get that either. I thought jQuery was pretty commonly used.

    Of course, around here, I'm an evil wizard because I can make the form change without a postback. (Cue the Holy Grail witch scene).

  • ymdhis (unregistered) in reply to LCrawford

    If a library is popular, it is automatically considered deprecated.

  • Julian Jones (unregistered) in reply to Robin

    Oh, but it does. In jQuery returning false from an event handler is shorthand for preventDefault and stopPropagation. Which, in turn, means that the confirmation dialog actually suppresses what I assume is a button submit. And that in the second-most annoying way possible: pretending the button wasn't pressed in the first place. Only to be topped by replacing the form action by a noop.

  • Wouter (unregistered) in reply to Robin

    IIRC (it's been a long time since I did serious jQuery), returning false from an event callback handler calls event.preventDefault() on the originating event, thus preventing any bubbling or propagating. Could be mistaken though.

  • NoLand (unregistered) in reply to Robin

    "The bonus WTF here is that this code doesn't even do anything (…) since you can never use the return value of an event handler"

    There's probably something much more sinister going on: in jQuery, returning false from a handler stops the event from both bubbling and propagating. So there's very likely a second click handler and this one is controlling, wether the second one will be triggered or not. As a bonus, the nice comments utterly fail to provide any information on this.

  • Tobi (unregistered) in reply to Scott

    "Legacy" is not always "old technology". It can just as well be a bunch of undocumented and cryptic code using the latest shit. If it is "inherited" by a developer (team) that is no longer available, but no one understands the code, it can be considered legacy.

  • NoLand (unregistered)

    P.S.: Here's how to implement a similar logic in vanilla JS (yes, you could do it using arrow functions as well):

    document.addEventListener('DOMContentLoaded', function() {
    var element = document.querySelector('#evilButton');

    element.addEventListener('click', function handler1(event) {
        // Nice comment: Ask user, if we should continue
        // returns true, if user confirms, else false.
        event.returnValue = confirm('Continue?');
    }, false);
 
    element.addEventListener('click', function handler2(event) {
        if (event.returnValue) {
            alert('Wiped production data.');
        }
    }, false);

}, false);
  • ooOOooGa (unregistered)

    OK. I'm not the greatest at javascript or jquery. So just confirming that this could be written simply as

    $('.notification-exp').bind('click', confirm( 'Confirm expiration?' ));

    Which still wouldn't let you use the return value of the confirmation box. Though the javascript framework may still abort the click action if confirm() returns false.

  • ymdhis (unregistered) in reply to NoLand

    If you do this with vanilla JS instead of jQuery, then you won't be able to remove anonymous event handlers.

    One can argue that if you want the event handlers removed then they should not specify anonymous functions, but one could also argue that jQuery("#elem").off("hover"); makes for simpler code. jQuery allows for the removal of anonymous handlers becase every time you use on() to add an event listener handler, it stores the handler functions in an internal variable, and off() just iterates through that. Because there's no native Javascript method to get all handler functions for an element! There's one command I don't remember from the top of my head, but it's a console command only - which doesn't mean that it works from the console only - it works from anywhere, as long as the console is open, making it extra fun to debug...

    So sometimes it's easier to just use jQuery instead of trying to be "smart".

  • I'm not a robot (unregistered) in reply to Julian Jones
    And that in the second-most annoying way possible: pretending the button wasn't pressed in the first place.
    How is that annoying? If you ask the user if they're sure and they say no, surely "pretending the button wasn't pressed in the first place" is exactly what they want.
  • Robin (unregistered)

    Thanks all - I never knew that returning false from a jQuery event handler did that, although it's somewhat consistent with how jQuery handles other things. (I've always just called e.preventDefault() and e.stopPropagation() manually as needed.)

    Regarding jQuery being "legacy" - it kind of is by now, although not for any reason to do with jQuery being bad. It's very good at what it does - simplifying the horrendously verbose native DOM API. The trouble is though that, if your website/app is fairly simple, it's better to just suck it up and use the native API than it is to force your users to download a pretty large library script simply in order to save the developer a few keystrokes. (Plus you could always define your own simplified functions if you feel like it.)

    Whereas, if you're doing anything complicated, using an imperative approach, as forced on you by both jQuery and vanilla JS, rapidly becomes an unmaintainable mess. Then you're better off using a framework that lets you write in a declarative style. (Say what you like about the notoriously "cult of the new" JS ecosystem, the 3 main frameworks are all pretty mature by now.)

    That, and the fact that all modern browsers behave pretty much as per the spec as far as JS is concerned (so no need for a library to iron out browser-specific quirks), mean there's little need for jQuery any more. I have used it quite a bit in my last 2 jobs, but that's only because those projects included it already (one was a steaming pile of legacy crap, the other job was mostly doing Wordpress sites which seem to all come with jQuery whether you want it or not). Thankfully I recently started a new job where I get to use React.

    Apologies for the essay, clearly I am TRWTF.

  • xtal256 (unregistered) in reply to ymdhis

    The real WTF is that jQuery thinks the opposite of "on()" is "off()". Isn't it supposed to be "on" as in "when this happens"? Like, "on click" means "when click happens". Not "turn on the click event".

  • sizer99 (google) in reply to Tobi

    You can have well documented and functioning legacy code as well. There's no reason legacy code must be terrible, it just usually is (because most code is terrible).

  • Old timer (unregistered)

    Legacy code is legacy either because the platform is legacy --- or because the code is poorly documented and dysfunctional.

    And legacy platforms are legacy either because ....

  • (nodebb)

    @ ooOOooGa Not quite. The handler argument has to be a function, not just a function call. But you're right that you don't need the if(x) return true; else return false; anti-pattern. So it should be

    $('.notification-exp').bind('click', function() { return confirm( 'Confirm expiration?' );});

  • Peter Wolff (unregistered) in reply to Barry Margolin 0

    You never know whether confirm returns a boolean in every case and whether the calling code checks for result===false or something like that.

    So, to be safe, at least return !!confirm( 'Confirm expiration?' );

  • Some Ed (unregistered) in reply to Tobi

    Once upon a time, I was part of a two man and one woman team that managed a service for a subset of a business unit. There were other groups that did similar things, but we ran our own service because the other services our department could've used instead were either fragile or couldn't handle certain basic situations that they wanted to handle.

    The company in question eventually noticed that they had roughly 203 different departments all providing more or less this same capability, and they decided the thing to do was to consider the capabilities and the cost effectiveness of each group, and either improve the current corporate offering to handle the sorts of things all these groups felt was sorely lacking or promote something more capable than the current corporate offering to be the new corporate offering.

    My team's product was selected and promoted to corporate, and despite the fact that 100% of the team at the time of that product selection was still on the team, our code was somewhat documented, and better written than any of the other groups we interacted with who felt they needed to port some aspect of their functionality to our system since they were no longer allowed to run their thing, suddenly all of our code was legacy code. Admittedly, only about 50% of the team was the old team.

  • Perri Nelson (unregistered)

    Legacy code, is code without unit tests. At least according to Michael Feathers. So, most code in the wild.

  • medievalist (unregistered)

    jQuery was great, but now it is obsolete. Therefore it's legacy, and deservedly so. Anything you think you need jQuery for is better handled by another framework - or, if you wanna go pro, by learning actual Javascript.

    The attitude around here is that there are still odd dark corners in vanilla js, but if you can't make a more maintainable, more readable, and more performant application without a "framework" maybe you should just stick to COBOL and FORTRAN. And punch cards. Frameworks are for wilsons and olds (this is not at all true, by the way, but it's the attitude).

  • ymdhis (unregistered) in reply to medievalist

    Why change to another framework though, if jQuery still does everything we want to, and does it significantly more simple than vanilla JS? Some us like to be productive instead of reinventing the wheel with every new project.

    The way I look at it, jQuery is not a framework, but just a bunch of pre-written functions that make it more logical to use javascript. Changing all that to use vanilla JS is sometimes either not possible, or adds unnecessary complexity.

  • (nodebb)

    The "useless use of if" is one of my favorite mini anti-patterns…

    if (condition)
    return true;
else
    return false;

    as opposed to just "return condition;" – this anti-pattern can be further improved by writing something like "if (isFrumious == true) …" because everyone knows that's so much more readable than "if (isFrumious)". (Yes, I know in some cases, you would need a cast when directly returning the result of the condition.)

  • (nodebb) in reply to Alexis_de_Torquemada

    Yes, but I have done that a lot of times. Why? Because in the branches I can add log statements or it eases debugging, i.e. setting breakpoints. Of course, I always plan to change it into "return condition", but I forget or I don't have time. Whatever.

    If I got a dime each time I did that, I would be able to buy me a beer. (At least a cheap one.)

  • Anon (unregistered) in reply to jonhaug

    You can also add comments to explain what each value represent.

  • Richard Wells (unregistered) in reply to Alexis_de_Torquemada

    That anti-pattern is the first one I show in the "How not to code like a n00b" lecture I give at some point every semester.

  • EveryOS (unregistered) in reply to ooOOooGa

    In response to your snippit, you would actually have to put that code in an arrow function So: $('.notification-exp').bind('click', ()->confirm( 'Confirm expiration?' ));

Leave a comment on “Legacy Documentation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article