The logic is fine. If you rename the variable to isAdmin, it makes perfect sense. Either they are an admin, or they are not an admin, or the state is unknown (here expressed as null). If you want to throw another JS-ism at this, undefined could be assigned before the check has been made.
I regularly use variables like this. If users is undefined, I haven’t fetched them yet. If they’re a list, then fetching is complete. If they’re null, then there was an error while fetching.
The only flaw is that the console.log states that null means user is not logged in.
If there are three or more explicit states, you should not use a nullable bool, but some more explicit data structure, like enum.
For example, if the state comes from a db, the user could be successfully logged in, but somehow for a range of possible reasons this variable ends up as null and you'll have a hell of a time debugging, because the log will give you nonsense.
if (var === true || var === 'true' || var === "true")
I'm just fortunate enough to not work with the frontend at our very backend service, but I always hear things that shouldn't be even allowed in this planet.
The logic is fine. If you rename the variable to
isAdmin, it makes perfect sense. Either they are an admin, or they are not an admin, or the state is unknown (here expressed asnull). If you want to throw another JS-ism at this,undefinedcould be assigned before the check has been made.I regularly use variables like this. If
usersisundefined, I haven’t fetched them yet. If they’re a list, then fetching is complete. If they’renull, then there was an error while fetching.The only flaw is that the console.log states that null means user is not logged in.
If there are three or more explicit states, you should not use a nullable bool, but some more explicit data structure, like enum.
For example, if the state comes from a db, the user could be successfully logged in, but somehow for a range of possible reasons this variable ends up as null and you'll have a hell of a time debugging, because the log will give you nonsense.
Good point.
Today i have seen:
if (var === true || var === 'true' || var === "true")
I'm just fortunate enough to not work with the frontend at our very backend service, but I always hear things that shouldn't be even allowed in this planet.
Yes JS is the crime in itself.
Not yes or no, but a secret third thing
How many "equal" symbols do we need to be absolutely sure?
It's JS, so about 5, I think.
Edit: Looks like TypeScript, but the same applies.
the fun/horrible thing about typescript is you can just start doing js stuff
as anytime you like...Like any good Boolean:
True / False / File not found
True, false, and magic.
Just use an enum lol
the real crime in this photo is the ===
The === is the best! I want to know they're really the same and not just evaluate the the same.
any sane language has == behave that way. Javascript == is just completely bonkers.
Obviously this should be a Result that the gets compiled to a nullable bool.
Aren't the first two if branches completely useless? The variable was just defined without a value, so it should always be
nullI'm so confused. I understand the reasoning behind two equal signs but three?
Afaik with three it also requires the types to be equal. Like 0 == false, but 0 !== false, because they're different types.