Check against null, as 0 is a falsy value.#24
Check against null, as 0 is a falsy value.#24hilios merged 1 commit intohilios:masterfrom romanbsd:master
Conversation
|
Yeah, blame on me I didn't though on this :( much appreciated with this fix, the only comment that I have is to follow the Google JavaScript Guidelines and do a strict comparission Thanks |
|
It's deliberately != because it can be undefined. So either have two strict conditions or this one. |
|
|
|
Then you'll need - if (typeof instanceNumber !== 'undefined' && instanceNumber !== null)I deliberately picked instanceNumber != null because it's shorter, and because I know what are the possible values here and I want javascript to cast the value. |
|
Where is the |
|
I never fully worked in the code btw, this is the first time I see it. But as I can see from github view it is not setting |
|
yep, it does a delete. And delete is supposedly sets it to undefined. So it can be just: typeof instanceNumber !== 'undefined' |
|
I would go for |
|
Not that I personally care |
|
if you want to save characters, then != null wins hands down :) |
|
|
|
|
|
heh, nice 👍 |
|
Besides all the technical details involving this issue, for me the problem here is the linter configuration of the project. This PR build is broken by the rules adopted, understand that the decision of following the Google Guidelines was to ensure a proper workflow for collaborations, like yours. As well isn't a good practice to merge a broken PR. The solution for the idiosyncrasy is found at jQuery.data documentation, as the following explanation and example: "[...] If no data at all was set on that element, undefined is returned." alert( $( "body" ).data( "foo" ) ); // undefined
$( "body" ).data( "bar", "foobar" );
alert( $( "body" ).data( "bar" ) ); // foobarIn theory a simple I don't want to loose track of the collaboration I will try to add a commit to this PR before merging, or if @romanbsd do it first it would be 👍 Thanks guys! |
|
yeah, go ahead, I don't mind :) |
|
I just added a proper testing to this issue. By the way this PR fixed bug #22. |
For the first countdown instance it returns 0, and it's a falsy value.