True crime
-
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.
-
Ah, the ol' tristate boolean switcheroo
wrote last edited by [email protected]tristate as in three states or tristate as in five states?
-
tristate as in three states or tristate as in five states?
Is that a quantum boolean?
-
This post did not contain any content.
And what if it's
undefined? -
That's good to know. Don't know how I didn't know this. Been writing JS since 2000. Always just used them I guess. Ecmascripts look funny to me without them
wrote last edited by [email protected]Fair enough, I like it better without but I don't have a strong preference and have no issue adapting to whatever the style of the repo is.
I learned about it researching tools to automatically enforce formatting style and came across StandardJS, which eliminates them by default.
-
Hmm, a webdev colleague said he'd normally prefer without semicolons, but used them anyways for better compile errors.
Interesting, I'm not aware of any way they would affect compile errors. I'd be curious to know more.
-
tristate as in three states or tristate as in five states?
wrote last edited by [email protected]That is the jankiest thing I have seen in at least ten years.
Edit: because of course it's office.
-
Fair enough, I like it better without but I don't have a strong preference and have no issue adapting to whatever the style of the repo is.
I learned about it researching tools to automatically enforce formatting style and came across StandardJS, which eliminates them by default.
I can see the benefit of matching style when working with others. I only code for myself and never had to worry about conformity for project consistency.
It is good to learn new things.
I'm sure I have some coding habitats that would annoy others.
-
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.
thank you for letting me in on the joke
and for catching my error!
-
I can see the benefit of matching style when working with others. I only code for myself and never had to worry about conformity for project consistency.
It is good to learn new things.
I'm sure I have some coding habitats that would annoy others.
Consistent styling helps make the actual meaningful changes easier to spot. Probably also useful for your own commit history when working solo in a repo, but most useful in a team, yeah!
-
Interesting, I'm not aware of any way they would affect compile errors. I'd be curious to know more.
I don't have experience with how it affects JavaScript specifically, but independent of programming language, it usually removes the guesswork where the error might be.
The thing is that compilers use fairly static rules for their grammar. So, even if you just typo a comma where there should've been a dot, then its grammar rules don't match anymore and it doesn't really know what to do with your code.
To some degree, it's possible to say certain symbols just cannot appear in a specific place, but especially with a comma, it could be the start of the next element in a list, for example.Without semicolons, it's likely going to tell you that something's wrong between somewhere before your typo and the next closing brace (
}). With semicolons, it can generally pinpoint the specific statement where the comma is wrong.
This should also make analysis quicker while you're editing the code, as it only has to check one statement (or two, if you're inserting a new line and haven't typed the semicolon yet).
