• Prime Mover (unregistered)

    'graph/sankey'

    So that's why you're moody.

  • rosuav (unregistered)

    Extra bonus benefit from using variables in template-generated JS: You can make an easy and generic "insert variables here" handler that JSON-encodes the values and puts them into the output code. That way, no issues with quoting, different formats, etc, etc, and it's completely generic, which means you don't have to deal with data-dependent bugs down the track.

  • Andrew (unregistered)

    "Clearly, the condition there is always going to be false."

    Are you sure you pasted the right code? Or is my sarcasm detector not working? To me, "development" is clearly not 'production', or does javascript's strict not equality operator care about single- and double-quoted strings?

  • MaxiTB (unregistered)

    Javascript, Javascript ... I heard that one before - that was the language use in the dark ages before Web Assembly was around, right?

  • Robin (unregistered) in reply to Andrew

    Maybe it's a meta-WTF, but most likely it's just a typo or inconsequential brainfart.

  • Hmmm (unregistered)

    Or it's for debugging output. Perhaps it was written by a human with ready to find text for changing output behavior with a small change

  • Shiwa (unregistered)

    This is actually a documented pattern : https://webpack.js.org/plugins/environment-plugin/ and not related to templates but to javascript minification.

    The source code probably looks like this reasonable line :

    if (process.env.NODE_ENV !== 'production')…

    In a nodeJS environment, it works as expected. In a browser environment that does not provide "process.env" global variable, the webpack plugin replace the variable with the desired value at bundle time. In the development bundle, the produced code looks a little weird but you get your debug log. In the production bundle, the condition is always false and the later minification step will delete the entire block, saving precious bytes.

  • innocenat (unregistered)

    The actual WTF here is why does the build tool didn't do dead code elimination. As Shiwa said, this is a documented, frequently-used pattern in JavaScript.

  • Conrad Buck (unregistered)

    Since libraries aren't going to be shipped minified and normally the minifier would prune the dead code, the correct fix would be to use babel-plugin-minify-dead-code-elimination, which is unfortuantely not maintained.

  • Charles (unregistered)

    I think the suggested replacement is worse. The original code may be a bit inelegant, but it is completely obvious. The replacement makes it more likly that it will be misunderstood to mean that there is a genuine possililty of the conditional sometimes being true. It also introduces a bogus variable, leading the reader to wonder where else this variable might be used.

  • Yikes (unregistered)

    I thought the fix would be something along the lines of not generating that Javascript section at all...

  • Twither (unregistered)

    Remy, you're adorable.

    As they say, any sufficiently advanced template engine will eventually converge to Common Lisp.

  • Airdrik (unregistered)

    I'd made a similar, if less eloquent declaration a few years ago wrt an app of ours which used JSP to generate/drive an AngularJS interface. And yes, it was using JSP's server-side templating to in/exclude UI elements depending on the permissions of the user, on top of AngularJS's templating of the interface itself which runs in the browser.

  • Shiwa (unregistered) in reply to innocenat

    The "replace process.env.NODE_ENV" pattern respects the main objective of each step of the code lifecycle :

    • source code must be easy to read and, for many libraries, executable in nodeJS
    • development bundle should be fast to build (skip dead code elimination) and keep debugging code
    • production bundle should be as small as possible (note that introducing a local variable might break dead code elimination)

    Given those constraints, a weird "if" statement in the development bundle is acceptable. TRWTF is the javascript ecosystem that leads to such constraints.

  • (nodebb)

    As someone who writes template-generated code a lot, this really bothers me. You have a perfectly good templating language there, why not use it to do the dead-code elimination too?

        let env = "development";
    let template = ``
    if env !== "production" {
         let template += `deprecateReplaceLog('focusNodeAdjacency', 'emphasis: { focus: \'adjacency\'}', 'graph/sankey'); \n`;
    }
    
    let template += `option.emphasis.focus = 'adjacency';`
    println(template);

    Which, when you're doing it a lot, becomes:

        // elsewhere
    let env = "development";
    function nonprodOnly(codestring) {
        return env !== "production" ? codestring : "" 
    }
    let template = ``
    
    //here
    template += nonprodOnly(`deprecateReplaceLog('focusNodeAdjacency', 'emphasis: { focus: \'adjacency\'}', 'graph/sankey'); \n`);
    
    let template += `option.emphasis.focus = 'adjacency';`
    println(template);

    Addendum 2022-06-30 17:52: Damnit, missed a let in the here section...

Leave a comment on “By Template”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article