Spend past 2 days trying to hunt down a bug...
I forgot `0` evaluates as `false` so this statement always returned `false` if `id` was `0` >.>

1. How come id can be 0 ?
2. I am pretty sure you can pass -1 and it would pass, so you could also do id || id ===0

IDs should start at 1 though..?

@just8littleBit no, why ?

We even use negative Ids some time.

Waiting for the "it's not weak typing that sucks, it's the people using it" arguments as per usual...

@AlmondSauce complaining about weak typing bugs in JS is like complaining about memory leaks in c. If you're going to use the language, you need to watch out for these things.

@danielstaleiny
That the language autocasts to bool does not mean, that you should actually let it do so.

Always test for what you actually want to test. In this case, test for id === undefined as the comment says - and then delete the comment as it got obsoleted by the code...

P.S.:
You absolutely have to decide globally, whether you want to initialize optional things to undefined or null, when they are meant to not be "defined"/specified.
In JavaScript, undefined is what you get automatically when omitting function arguments.
But null is, what almost everyone coming from other languages expects unknown data to be...

So in JavaScript i would use undefined for "omitted" values and null for unknown data.

@danielstaleiny Id can be 0 because id can be 0 xD

Nothing much to add there xD

It just starts at 0.

@Oktokolo Yea, in this case it can be null as it can be unknown data (don't ask, something upstream that does this)

@Oktokolo It always depends on the requirement but I have no problem using truthy or falsy values but when I use them I know the value will not be falsy etc. Yes, I agree that you should be explicit.

when I start to fight with this kind of issue, I start to want proper types like Purescript has, with optional types, patter matching and case suger to find valid case and ignore the rest.

@danielstaleiny
Yeah, weak type systems are annoying when dealing with input from 3rd-party code. But you can always write some tiny and well-named wrappers which perform the correct checks and call them everywhere you need to.
That way, you keep the checks consistent, don't need to think about the correct checks over and over again, and automatically document your intention.

@AlmondSauce Weak typing isn't even the issue here, even strongly typed languages support truthy values in if statements.

And even it if it was type coercion bullshit, JS supports strict equality comparisons. Maybe OP should be using id !== null instead

@AlmondSauce weak typing sucks, truthy values suck, and the people who are using them and find them great suck, too.

@Lensflare I'm fine with weaktyping, truthy values are annoying though (for obvious reasons).