True crime
-
Common JavaScript L
Not wrong, but funnily enough, it's a linting rule win. I'd go nuts if I didn't have my type checks and my linters. My current L, though, is setting up the projects initially and dealing with the configuration files if I raw dog it, but that's a problem with ESLint configs and the ecosystem as a whole having to deal with those headaches. So in the end, the JS devs got clever and shifted the blame to the tooling.
-
This is quite reasonable, aside from the variable name which should be
isAdmin. A user either is an admin, or isn't. Unless we don't know, then it's null. You are correct this is bad if the point was to represent roles, but it's not supposed to.Admin is a role though, was my point. And besides, if you check for three different states, and you decide to go with a boolean to represent that, I really find it hard to believe anyone would think it reasonable. It’s valid and it’s practical, but can you really say it’s reasonable?
I don’t do typescript, but wouldn’t a union of a null and a bool be just more resource intensive than simply using an unsigned byte-sized integer? I struggle to find reasons to ever go for that over something more reasonable and appropriate for what it attempts to represent (3 distinct states as it stands, and likely in future more than just 3 when they have a need for more granularity, as you’d often do with anything you’d need an admin role distinction in the first place), but likely I’m just not familiar with ts conventions. Happy to hear the reasoning for this though.
-
Admin is a role though, was my point. And besides, if you check for three different states, and you decide to go with a boolean to represent that, I really find it hard to believe anyone would think it reasonable. It’s valid and it’s practical, but can you really say it’s reasonable?
I don’t do typescript, but wouldn’t a union of a null and a bool be just more resource intensive than simply using an unsigned byte-sized integer? I struggle to find reasons to ever go for that over something more reasonable and appropriate for what it attempts to represent (3 distinct states as it stands, and likely in future more than just 3 when they have a need for more granularity, as you’d often do with anything you’d need an admin role distinction in the first place), but likely I’m just not familiar with ts conventions. Happy to hear the reasoning for this though.
wrote last edited by [email protected]So in a language with nullable types, are you against a boolean ever being nullable? Null means "empty, missing info". Let's say we have
rolevariable with a enum type of possible roles. It could still reasonably be nullable, because in some scenarios you don't know the role yet, like before log in.In any use case where we need to store some boolean, it's a common occurrence that we don't have the data and it's null. It would be overkill to use an enum with
True,False,NoDatafor these cases, where there is already a language feature made just for that, nullable values.I've never used TypeScript, just writing from experience in other languages.
-
This post did not contain any content.
Same as ?
std::optional<bool> role; if (role.value()) { std::cerr ("User is admin");} else if (!role.value()) { std::cerr ("User is not admin");} else if (!role.has_value()) { std::cerr ("User is not logged in");}Here
has_value()should have been checked first, but the JS seems kinda fine.
Which is it? -
So in a language with nullable types, are you against a boolean ever being nullable? Null means "empty, missing info". Let's say we have
rolevariable with a enum type of possible roles. It could still reasonably be nullable, because in some scenarios you don't know the role yet, like before log in.In any use case where we need to store some boolean, it's a common occurrence that we don't have the data and it's null. It would be overkill to use an enum with
True,False,NoDatafor these cases, where there is already a language feature made just for that, nullable values.I've never used TypeScript, just writing from experience in other languages.
wrote last edited by [email protected]Yeah, but if it is about being an admin or not, hence the bool, it’d be idiomatic and reasonable to assume it to be false if we have no data. Unless we want to try and allow admin access based on no data. Having three states for a simple binary state is weird. And if it is not about just being an admin or not, the bool is inherently a too limited choice for representation.
-
I mean aside of the variable name, this is not entirely unreasonable.
The variable name is 90% why this is so unreasonable. Code is for humans to read, so names matter.
-
Product manager: "I want a new role for users that can only do x,y,z"
Developer: "uh.. yeah. About that... Give me a few days."
Hmmm I need a datatype with three states... Should I use a named enum? No, no that's too obvious...
-
Same as ?
std::optional<bool> role; if (role.value()) { std::cerr ("User is admin");} else if (!role.value()) { std::cerr ("User is not admin");} else if (!role.has_value()) { std::cerr ("User is not logged in");}Here
has_value()should have been checked first, but the JS seems kinda fine.
Which is it?a === breturns true ifaandbhave the same type and are considered equal, and false otherwise. Ifaisnullandbis a boolean, it will simply return false. -
I would certainly rather see this than
{isAdmin: bool; isLoggedIn: bool}. Withboolean | null, at least illegal states are unrepresentable... even if the legal states are represented in an... interesting way.Admin false LoggedIn false doesn't feel illegal to me, more redundant if anything
-
Admin is a role though, was my point. And besides, if you check for three different states, and you decide to go with a boolean to represent that, I really find it hard to believe anyone would think it reasonable. It’s valid and it’s practical, but can you really say it’s reasonable?
I don’t do typescript, but wouldn’t a union of a null and a bool be just more resource intensive than simply using an unsigned byte-sized integer? I struggle to find reasons to ever go for that over something more reasonable and appropriate for what it attempts to represent (3 distinct states as it stands, and likely in future more than just 3 when they have a need for more granularity, as you’d often do with anything you’d need an admin role distinction in the first place), but likely I’m just not familiar with ts conventions. Happy to hear the reasoning for this though.
My preferred way of modelling this would probably be something like
role: "admin" | "regular" | "logged-out"
or
type Role = "admin" | "regular";
role: Role | null
depending on whether being logged out is a state on the same level as being a logged-in (non-)admin. In a language like Rust,
enum Role {Admin, Regular}
instead of just using strings.I wouldn't consider performance here unless it clearly mattered, certainly not enough to use
role: number,
which is just about the least type-safe solution possible. Perhaps
role: typeof ADMIN | typeof REGULAR | typeof LOGGED_OUT
with appropriately defined constants might be okay, though.Disclaimer: neither a professional programmer nor someone who regularly writes TypeScript as of now.
-
Admin false LoggedIn false doesn't feel illegal to me, more redundant if anything
wrote last edited by [email protected]I was thinking of the three legal states as:
- not logged in (
nullor{isAdmin: false, isLoggedIn: false}) - logged in as non-admin (
falseor{isAdmin: false, isLoggedIn: true}) - logged in as admin (
trueor{isAdmin: true, isLoggedIn: true})
which leaves
{isAdmin: true, isLoggedIn: false}as an invalid, nonsensical state. (How would you know the user's an admin if they're not logged in?) Of course, in a different context, all four states could potentially be distinctly meaningful. - not logged in (
-
This post did not contain any content.
You could make it even dumber by using weak comparisons.
-
Yeah, but if it is about being an admin or not, hence the bool, it’d be idiomatic and reasonable to assume it to be false if we have no data. Unless we want to try and allow admin access based on no data. Having three states for a simple binary state is weird. And if it is not about just being an admin or not, the bool is inherently a too limited choice for representation.
wrote last edited by [email protected]Depends on your requirements.
If the admin status needs to be checked in a database, but most actions don't require authentication at all, it's pointless to waste resources checking and it would be left null until the first action that needs the information checks it and fills it in as true or false.
-
Ackshually three equal signs check for type as well. So mere truthiness is not enough. It has to be exactly true.
Also, everyone knows FILE_NOT_FOUND isn't a string but a boolean value.
yeah, it's funny how my brain collapsed the boolean check into
if (role)rather thanif (role === true)- that's trickywhat is
FILE_NOT_FOUND? I can't find much on it ... -
I was thinking of the three legal states as:
- not logged in (
nullor{isAdmin: false, isLoggedIn: false}) - logged in as non-admin (
falseor{isAdmin: false, isLoggedIn: true}) - logged in as admin (
trueor{isAdmin: true, isLoggedIn: true})
which leaves
{isAdmin: true, isLoggedIn: false}as an invalid, nonsensical state. (How would you know the user's an admin if they're not logged in?) Of course, in a different context, all four states could potentially be distinctly meaningful.ah you are right! i am so dumb.
- not logged in (
-
yeah, it's funny how my brain collapsed the boolean check into
if (role)rather thanif (role === true)- that's trickywhat is
FILE_NOT_FOUND? I can't find much on it ...FILE_NOT_FOUND is from an old story on thedailywtf.com. Someone created a boolean enum with TRUE, FALSE and FILE_NOT_FOUND, if I recall correctly. It's been a recurring running joke.
-
I was thinking of the three legal states as:
- not logged in (
nullor{isAdmin: false, isLoggedIn: false}) - logged in as non-admin (
falseor{isAdmin: false, isLoggedIn: true}) - logged in as admin (
trueor{isAdmin: true, isLoggedIn: true})
which leaves
{isAdmin: true, isLoggedIn: false}as an invalid, nonsensical state. (How would you know the user's an admin if they're not logged in?) Of course, in a different context, all four states could potentially be distinctly meaningful.Honestly logged in is state and shouldn't be on the user object.
- not logged in (
-
a === breturns true ifaandbhave the same type and are considered equal, and false otherwise. Ifaisnullandbis a boolean, it will simply return false.I see, so logically it is fine.
Just not in the context. -
My preferred way of modelling this would probably be something like
role: "admin" | "regular" | "logged-out"
or
type Role = "admin" | "regular";
role: Role | null
depending on whether being logged out is a state on the same level as being a logged-in (non-)admin. In a language like Rust,
enum Role {Admin, Regular}
instead of just using strings.I wouldn't consider performance here unless it clearly mattered, certainly not enough to use
role: number,
which is just about the least type-safe solution possible. Perhaps
role: typeof ADMIN | typeof REGULAR | typeof LOGGED_OUT
with appropriately defined constants might be okay, though.Disclaimer: neither a professional programmer nor someone who regularly writes TypeScript as of now.
wrote last edited by [email protected]Yeah obviously with constants for the set roles per value. Some languages call them enums, but the point is that what we pass and use is always still the smallest integer type possible. With the extra bonus that if the roles ever become composable, the same value type would likely suffice for a bitflag and only thing needing refactoring would be bitshifting the constants.
But anyway, this turns out to be the weirdest hill I find myself willing to die on.
-
Depends on your requirements.
If the admin status needs to be checked in a database, but most actions don't require authentication at all, it's pointless to waste resources checking and it would be left null until the first action that needs the information checks it and fills it in as true or false.
I don’t really follow you there, wouldn’t it be exactly the opposite and wouldn’t checking for nulls be, as a premise, more wasteful? But doesn’t really matter, time to digress. I’m conventionally educated as an engineer so what I know and find reasonable today might be outdated and too strict for most contemporary stuff.
