https://www.sofascore.com/ doesnt load properly

[alex04]

https://www.sofascore.com/

top of page loads some stuff but everything under doesnt



PM 29.1.0 x32 on Windows 7 SP 1 x64

[New Tobin Paradigm]

Code: Select all

Timestamp: 3/13/2021 11:53:07 PM
Error: SyntaxError: missing ) after condition
Source File: https://www.sofascore.com/_next/static/chunks/26cfcb59.50afd13a09b5024f9744.js
Line: 1, Column: 83045
Source Code:
rorCode.API_ERROR);for(;;){if(0===this.yields.length&&await this.signal,this.err)throw this.err;const t=this.yields;this

[Moonchild]

Code: Select all

if(0===this.yields.length&&await this.signal,this.err)

How the hell is that supposed to be a valid if condition?

[The Squash]

Quite honestly, I don't see anything wrong with that if statement; it looks standards-conforming to me.

There is one thing that is a little bit unusual, though: the comma in the second half of the test expression, after the await statement. But according to MDN (https://developer.mozilla.org/en-US/doc ... a_Operator), the comma operator can be used in almost any expression, basically. So let me break this code down to the best of my understanding:

IF "this.yields.length" is equal in type and value to the number 0,
AND (wait for the Promise in "this.signal" to complete, then test if) "this.err" is nonzero...
THEN... well, then throw whatever error is in "this.err".

So it's a little unusual (I've only seen for loops use the comma operator, generally speaking), but it seems to me to be standards-conforming and technically legal.

EDIT:
And the await statement does seem to be what is the "syntax error" (the parser maybe thinks that the await is actually an identifier and not an operator keyword?), though that kind of usage should also be legal (technically speaking at least): https://developer.mozilla.org/en-US/doc ... tors/await

[Moonchild]

You can't use await inside an if conditional. It makes absolutely no sense to do so.
For starters, await usually returns a Promise object. You can't make a logical decision inside an if statement based on a promise.
Second, the expression await this.signal,this.err does not provide any sort of comparison with a known value that can be logically AND-ed with the lhs boolean.
Then there's the whole comma thing. According to you it would have to evaluate await this.signal separately from this.err, neither of which provide boolean results as far as I can tell.
So no, this statement makes no sense for multiple reasons.

[vannilla]

In some languages, the operator comma operator (or equivalent) means "evaluate this expression, then the next and return the value of the second evaluation", so the conditional would actually be if (0 === this.yields.length && this.error), with the side effect of starting a promise with await (whatever that means.)
The question then is: is javascript one of those languages?
Probably not, unless as usual Google added this feature in some new version.

[The Squash]

Not to be a smart aleck, but the above links I provided show example uses for await without using the Promise object that it returns, and also the comma operator still could make sense here -- maybe this.err is null or undefined unless an error is to be thrown.

So basically, the "gobbledygook" code above simply waits for a Promise to be fulfilled, and then tests if the Promise failed. It's unconventional I know, and I wouldn't do it, but I don't really see what's the complication here.

[Moonchild]

So basically, the "gobbledygook" code above simply waits for a Promise to be fulfilled, and then tests if the Promise failed.

No, it doesn't. According to your own explanation that is not at all what it does.
(you can try again explaining what it really does, if you can. I'm curious to see if you can figure it out)
It's also completely unclear in what order this kind of expression should be evaluated.

I don't really see what's the complication here.

The complication is that we don't support this kind of weird abuse of async keywords inside conditional expressions because it makes no sense whatsoever.
This is taking "saving a few keystrokes" waaaay too far, and whomever thought this would be a good idea (and I mean here both the person who thought this should be valid && the person who actually used it in website code) should be taken out back.

[The Squash]

First off, let me address this:

This is taking "saving a few keystrokes" waaaay too far, and whomever thought this would be a good idea [...] should be taken out back.

I agree with your attitude, but IMHO, all minified JavaScript is massively confusing. That's kinda how minified JavaScript works these days; obfuscation comes along with minification these days I suppose? Like, who writes the value first and the variable second in an equality-testing statement:

Code: Select all

0===this.yields.length

So ultimately if you were to kill whomever did this, then you should take out everybody who comes up with minified JavaScript.

---

Second, I'd like to openly confess I'm not infallible (and I'll put it in bold so that nobody can accuse me of shading truth): I grossly misinterpreted the expression below the first time through. After reminding myself of JavaScript's operator precedence (https://developer.mozilla.org/en-US/doc ... ence#table), I would like to reevaluate that expression:

1. First, if this.yields.length is the number zero, then and only then wait for the Promise in await this.signal to complete.
2. Whether or not this.yields.length is the number zero, test this.err for non-nullness. If it is non-null, then throw the error object in this.err.

A run through Mozilla's SpiderMonkey interactive shell confirms this behavior.

So yes, confusing as heck, and I think the designer of this should understand that this is incredibly confusing, but so is most minified JavaScript. And this is obviously minified JavaScript.

(And sorry if I initially came off as professorial and authoritative. I beg foregiveness for my initial screw-up.)

[vannilla]

Like, who writes the value first and the variable second in an equality-testing statement:

Off-topic:
I do, among other things.

[The Squash]

Off-topic:
I never thought I'd ever meet someone like that.

[Moonchild]

This has zero to do with the js being minified, so don't blame minification for it.
Minification doesn't come up with these kinds of constructs. It doesn't make any code changes like ordering, changing the keywords, or what not because that would very likely damage code functionality.
All it does is reduce legibility by reducing var and function names, white space, etc. from human-readable to something that takes up as little space/bytes as possible. The grammar and flow of programs do not change.

[The Squash]

Minification [...] doesn't make any code changes like ordering [...] The grammar and flow of programs do not change.

Are you sure? https://javascript-minifier.com/

Input:

Code: Select all

if (variable === 0 && other < 15)
  print("A string" + variable);

Output:

Code: Select all

0===variable&&other<15&&print("A string"+variable);

It sure looks like the 'variable === 0' got reordered to '0===variable', even though there is no size difference between the two.

I've said it before and I'll say it again: I don't mean to be a smart aleck, but it sure looks like you really cannot generalize JavaScript minifiers. Any chimp can come up with a program which removes unnecessary whitespace from a file, but it takes a fair understanding of the language to truly minify the code -- and if the program already understands the syntax of the language, then why not rearrange statements?

[vannilla]

Apparently that thing linked by The Squash really does a lot.

This junk input:

Code: Select all

if (foo()) {
    bar();
    baz();
    if (quux() == 2) {
        niz();
    }
}

becomes this:

Code: Select all

foo()&&(bar(),baz(),2==quux()&&niz());

[Moonchild]

And there's a good chance that kind of "minifier" (which is more of an obfuscator by making it even harder to read even if formatting is restored) totally breaks JS because it makes assumptions about (1) sloppy mode and (2) the target JS parser's quirks.

Still, effectively there is little difference between the two with the only real thing being that if statements are changed to implied branches because of early-exit when evaluating. But even that simple "optimization" to reduce size is risky; complex if statements might not deal well with just making it a sequence of ANDed conditionals.
And here's the crux: by shuffling all that around and effectively removing scopes, special keywords become part of expressions that would normally never have those keywords in them (like await...). Scopes are there for a good reason; it isolates context.