Why is Minified Code not Equivalent to Original?

Question

When I ran my MVC 4 project in Release mode, one page that uses SlickGrid did not display correctly (the grid is very, very tall and the grid cells are missing).

However, I do not think this is an issue of SlickGrid, but rather of how the bundler (System.Web.Optimization that is integrated into MVC 4) minified the code.

I grabbed the minified JavaScript and began reversing minification in one area at a time until the problem was fixed. I found that changing (and forgive the scrolling, I want to leave the minified version exactly as-is)

function SlickFilter(n,t){var i=n.option,r=t.searchString;return n.pctSortKey.key<t.percentCompleteThreshold||r!=""&&i.indexOf(r)==-1&&i!="Unweighted Response"&&i!="Median"&&i!="Average"?!1:!0}

to the original

function SlickFilter(item, args) {
    if (item.pctSortKey.key < args.percentCompleteThreshold) {
        return false;
    }

    if (args.searchString != "" && item.option.indexOf(args.searchString) == -1 && item.option != "Unweighted Response" && item.option != "Median" && item.option != "Average") {
        return false;
    }

    return true;
}

resolves the issue if all other elements of the minified file are unchanged.

The function is used like:

dataView.setFilter(SlickFilter);

to provide a callback function for SlickGrid to filter out certain results.

How is it that the original and the minified function are not equivalent?

UPDATE

SlickGrid is "compiling" the filter function that I provide. That compilation step is failing with the minified version. The compiled minified code looks like:

function anonymous(_items,_args) {
var _retval = [], _idx = 0; var n,  t = _args; _coreloop: for (var _i = 0, _il = _items.length; _i < _il; _i++) { n = _items[_i]; 
    //debugger;
    var i = n.option,
        r = t.searchString;

    return 
    n.pctSortKey.key < t.percentCompleteThreshold 
    || 
    r !="" 
        && i.indexOf(r)==-1 
        && i != "Unweighted Response" 
        && i != "Median"
        && i != "Average"
? !1
: !0
; } return _retval; 
}

Note the multiple return statements.

With this additional insight, I was able to identify a relevant SlickGrid bug:

https://github.com/mleibman/SlickGrid/issues/301

Are you minifing the js by yourself? There are tons of minifier tools out there so I recommend you to try another one. — lolol, Feb 22 '13 at 19:41
@lolol: No I'm using `System.Web.Optimization` that is integrated into MVC 4. Updated the question to clarify that. — Eric J., Feb 22 '13 at 19:48
My bad, I can't really help you then. Sorry. (i got similar problems, but i was doing it myself, changing the tool solved the problem) — lolol, Feb 22 '13 at 19:53
Strange, someone just downvoted this question many months after it was asked with no comment. — Eric J., Oct 08 '13 at 16:27

score 4 · Accepted Answer · edited Feb 22 '13 at 21:57

4

The one difference I see is that item.option and args.searchString are being evaluated even when the first condition is true when they would not have been in the original code.

Have you tried stepping into the code to see what the values are and how it acts on them?

Here is the unmangled minified code to save anyone else doing the same, or if you wish to try it and step into it.

function SlickFilter(n,t) {
var i = n.option,
    r = t.searchString;

return 
        n.pctSortKey.key < t.percentCompleteThreshold 
        || 
        r !="" 
            && i.indexOf(r)==-1 
            && i != "Unweighted Response" 
            && i != "Median"
            && i != "Average"
    ? !1
    : !0
}

EDIT (by OP)

This got me on the right path, but it turns out that SlickGrid is "compiling" the filter function. There's a known issue that the compiler sometimes fails. Indeed compiling is optional and not necessary in this case since the minifier already produces optimized code.

https://github.com/mleibman/SlickGrid/issues/301

edited Feb 22 '13 at 21:57

Eric J.

147,927
63
340
553

answered Feb 22 '13 at 20:13

telb

76
2

I'm with you - that's the only difference I see. But that difference of evaluating those two items shouldn't have any effect - they're just returning values, so no code is actually executing any differently. Even if they don't exist, they'd just return undefined, and the code would continue. The short-circuited `||` would mean that the values of `i` and `r` will never be used unless the first line doesn't happen, which is the same behavior as when they were separate `if` statements. – Joe Enos Feb 22 '13 at 20:28
It looks like proper parenthesis would fix it right?, from return to ? – technosaurus Feb 22 '13 at 21:14
For the record, this formatted version exhibits the same behavior as the version I posted. I'm now debugging to look for side-effects based on your suggestion. I'll let you know! – Eric J. Feb 22 '13 at 21:24
Strike that! Reverse it. While debugging with this version of the code, there's an error in the SlickGrid code base. Going to debug with the non-minified SlickGrid. – Eric J. Feb 22 '13 at 21:31
@technosaurus As ugly as it is without parenthesis, it should behave properly - `&&` has priority over `||`, so after the first line runs, the `&&`s are evaluated together (assuming the first line is false), then they're "or'd" together. These all have priority over the `?:` operator, so that's executed based on the result of the entire top expression. I'd never write code like that in real life, but in a minifier, it should be ok. – Joe Enos Feb 22 '13 at 21:32
@JoeEnos it was the return that I get confused on. I thought it may be doing (return (a)) || b && c && d ... parens around the whole expression would avoid that too. I guess I should look return up in the standard. – technosaurus Feb 22 '13 at 21:41
Eureka! Turns out it is a SlickGrid issue after all. Updated the question with additional information, editing and accepting this answer because it got me on the right path. – Eric J. Feb 22 '13 at 21:56

Why is Minified Code not Equivalent to Original?

1 Answers1