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.
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.