Frontend engineer. Enthusiast of just-in-time learning and learning by teaching as well as deep work concept. Sharing coding tips & my thoughts on dev work.
I love coding and what motivates me is problem-solving and preferably if it has an element of creativity.
I am a self-taught developer and work full-time as a front-end developer.
Location
Denmark 🇩🇰
Education
Bachelor in Nutrition and health (I know not super relevant to my current line of work!)
What's the purpose of the !! here? The && will cast the left-hand operation to a boolean already. Won't null and undefined already be converted to false for the purpose of the guard clause?
I love coding and what motivates me is problem-solving and preferably if it has an element of creativity.
I am a self-taught developer and work full-time as a front-end developer.
Location
Denmark 🇩🇰
Education
Bachelor in Nutrition and health (I know not super relevant to my current line of work!)
Ah okay! I wasn't sure if I'd missed something or not. I use guard clauses pretty extensively in my React code, but I also use quite a few languages across a bunch of projects. Wasn't sure if I'd gotten mixed up 😅
I love coding and what motivates me is problem-solving and preferably if it has an element of creativity.
I am a self-taught developer and work full-time as a front-end developer.
Location
Denmark 🇩🇰
Education
Bachelor in Nutrition and health (I know not super relevant to my current line of work!)
Nice writeup! I actually use the ternary a lot, but I do not find it useful for all purposes. I am a bit unsure!? So you are actually saying that the "!!" prefix would be needed here to "catch" all falsey values?
!!value is effectively the same as Boolean(value) and will therefore always return false in the case of all falsy values.
!!value&&<MyComponent/>
Will always resolve to false if the left hand side is falsy. False values are not rendered, so yes, that would catch all falsey values.
I still recommend Boolean(value) && <MyComponent /> over !!value && <MyComponent /> because it is both explicit and easier to read, albeit it a bit longer. It's easy to skip over !!, but more importantly, it's easy to forget to add !!. If you're used to seeing Boolean(...), that's less likely.
I love coding and what motivates me is problem-solving and preferably if it has an element of creativity.
I am a self-taught developer and work full-time as a front-end developer.
Location
Denmark 🇩🇰
Education
Bachelor in Nutrition and health (I know not super relevant to my current line of work!)
That's actually a great point! I haven't used Boolean(..) in my code I think 🤔 But I like how it's more descriptive! Thanks for taking the time to responde 😊👍
I also recommend Number(value) over the obscure +value, which both are usually better to "type-cast" than parseInt or parseFloat, as it will properly fail when the value isn't representing a number, instead of doingsomethingunexpected.
I love coding and what motivates me is problem-solving and preferably if it has an element of creativity.
I am a self-taught developer and work full-time as a front-end developer.
Location
Denmark 🇩🇰
Education
Bachelor in Nutrition and health (I know not super relevant to my current line of work!)
Ahh, cool. I haven't digged super deeply into the differences, I just really like "Number" because "it does what it says on the tin" 😆 I really like easy readable code 😊
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You could also wrap fetch logic in a hook that returns { data, loading, error }.
And then:
Nice one!
this is my everyday use. No status required.
I like that React-query allows for that approach and it works excellently in JS and in TS.
Yeah! That is also my approach!
I have this habit of writing
It is probably over-cautious, but checking for null and undefined is nice - these errors can be really hard to debug otherwise.
What's the purpose of the
!!
here? The&&
will cast the left-hand operation to a boolean already. Won't null and undefined already be converted to false for the purpose of the guard clause?I think you are actually right!! 😮 I always thought this was only a check for null.
Ah okay! I wasn't sure if I'd missed something or not. I use guard clauses pretty extensively in my React code, but I also use quite a few languages across a bunch of projects. Wasn't sure if I'd gotten mixed up 😅
You did miss something.
This is not true when it short-circuits. That is, when the left hand side is falsy.
No, they won't
In the end,
undefined
will cause errors,null
won't.false
depends on the renderer.Side note! If you want to be explicit, using
Boolean(loading)
is probably more readable than double negation (!!loading
).The best way is to not rely on
&&
(or||
) to return the right result, but use a ternary:Why? Now you don't need to think about all falsy values and the rendering never breaks :D
Nice writeup! I actually use the ternary a lot, but I do not find it useful for all purposes. I am a bit unsure!? So you are actually saying that the "!!" prefix would be needed here to "catch" all falsey values?
!!value is effectively the same as
Boolean(value)
and will therefore always returnfalse
in the case of all falsy values.Will always resolve to
false
if the left hand side is falsy. False values are not rendered, so yes, that would catch all falsey values.I still recommend
Boolean(value) && <MyComponent />
over!!value && <MyComponent />
because it is both explicit and easier to read, albeit it a bit longer. It's easy to skip over!!
, but more importantly, it's easy to forget to add!!
. If you're used to seeingBoolean(...)
, that's less likely.That's actually a great point! I haven't used Boolean(..) in my code I think 🤔 But I like how it's more descriptive! Thanks for taking the time to responde 😊👍
The _callable Global Objects are a gem ✨.
I also recommend
Number(value)
over the obscure+value
, which both are usually better to "type-cast" thanparseInt
orparseFloat
, as it will properly fail when thevalue
isn't representing a number, instead of doing something unexpected.Ahh, cool. I haven't digged super deeply into the differences, I just really like "Number" because "it does what it says on the tin" 😆 I really like easy readable code 😊