var lastdim3 = global.get('lastdim3') || 255;
If value of variable is 0 it will get 255, if value is 1 or more it will work, if i remove the || 255 it will then get the 0 if thats the value..
Yes.. as 0 is a falsey value in javascript so it passes to the next value (in this case 255).
https://j11y.io/javascript/truthy-falsey/
Ok that explains it Thank you. Stored the context as a string now it works. Now in the context data it is a red "0" instead of a blue 0 without quotes.
You can just use the more verbose
var lastdim3 = global.get('lastdim3');
if (lastdim3 == null) lastdim3 = 255;
I think that would be better as
if (typeof lastdim3 == "undefined") lastdim3 = 255
1 Like
I based my suggestion on the fact that the only valid values for him are numerics, and that truthy "== null" would cover both undefined and null cases, but not suffer the "== 0" truthy trap inherent in "if (value)".
It does work if you use ==0 as you have suggested, however you get a warning in the editor
Hovering over the yellow warning says that one should use === to compare with null, and if you do that then the test does not succeed. Therefore I think this would be a dangerous approach as at some time in the future the warning will be noticed and the code "corrected" so it won't work any more.
Since the reason for the test is to allow for the case where the global has not yet been set and there is no suggestion that the value might ever actually be null I still recommend testing for undefined.
That lint warning is wrong when you are looking to do this exact comparison. My example IS the exception to that lint rule. Its a suggestion because what Im using it to do is an UNINTENDED CONSEQUENCE of using it this way when you only want to check for null, but here it is the INTENDED consequence.
Of course if the little yellow triangle bothers you, you can do the long hand of that too:
if (typeof(lastdim3) === 'undefined' || lastdim3 === null) lastdim3 = 255;
1 Like
It is not that it bothers me, but left like that then at some point in the future one of the developers would 'fix' it. I would have to put a comment in explaining why it is like it is.
I don't see how the variable could ever be null, so what is the point in testing for it?
Can you not set a flow parameter to null? Im just being thorough, in case you can. In any SANE language we wouldn't have to have this convo... The linting rule is trying to tell you not to use the JS truthiness because its completely insane and is best avoided: and I can't really fault that.
This is actually about the ONLY place I'd actually use == over === specifically because (a) null checks are always everywhere and (b) this short hand does the actual comparison I almost ALWAYS want because JS decided to differentiate undefined and null for some stupid reason...
They took the SAFER default for the LINTing rule, I just think I almost always break this one because its MUCH rarer that I DON'T want to check for both than I only want to check for one.
Yes I am sure you can do that, but if you are testing for the case where the code has set it to null then why not test for -1 too? Or any other invalid number. The common case when a variable can be null is if it is declared but not initialised, but that is not the case here as it is initialised with global.get()
Yes I am sure you can do that, but if you are testing for the case where the code has set it to null then why not test for -1 too?
You could do that too. And for numbers greater than 255. Its all just validation. Layer in as appropriate. Most node-red projects I've seen (for a lot of home automation projects) I wouldn't exactly call bastions of best practice at all, so really we're just beating a dead horse here when the only problem our OP really cared about was solved long ago 
