On one hand, I feel ridiculous I have a function that will only run once.
On the other, there are no let bindings in the file.
I did consider Array.prototype.includes() but elected not to use it for just two elements.
I don't think the RegEx has good readability, especially having had to escape the dots.
I also noticed that you used === for comparing to "undefined" but == for the domain.
Is there a reason you are using hasOwnProperty instead of just the truthiness of the objects? Is it more performant?
Myself, in the process of writing this, I went back and changed it, and was happily surprised that
// the expressionwindow.location.hasOwnProperty("hostname")&&window.location.hostname// collapsed towindow.location.hostname
Just a coder and a dad. I love my family and I love to code!!!! started coding at 11, so I have 25 years under my belt. Still love learning about it every day. Black lives matter!
Doing a function is typically a sure thing. It's never stupid to abstract out to a function. It's a great habit to practice. Even if it only gets used once, you are completely right about it helping to avoid having to do things such as declaring additional variables and also making the assignment highly clear const secure = needsSecure() vs const secure = !isLocal;.
With the RexEx, that was more of an option to show others that you could bring in RegEx to do your checking. But you and others have pointed out, that my goal was to make the code more readable... so to a lot of people, it's hard to read so therefore it did not make the code "easier to read".
Far as strict comparison, vs non-strict. That is a bad habit I need to break. You caught me red-handed lol. Stick with using strict comparison, and only use non-strict as needed.
Now for the final part, hasOwnProperty is there for a good reason. I am wanting to specifically check for a Boolean answer, so hasOwnProperty will give me that. You can definitely do it your way and it'll work. When it's a single variable, that is how I do it.
When I'm digging down in to an object I prefer to be more intentional with it by using hasOwnProperty
It's actually really unclear how to do such checks, you have to keep in mind what failures you actually expect to have.
On one hand, if you expect an object, truthiness gets rid of null, undefined, false (we'd be getting the false from the typeof equality, as well as hasOwnProperty) as well as less importantly 0, and "".
// OH NO;({location:undefined}.hasOwnProperty("location"))// true;({location:null}.hasOwnProperty("location"))// true// Better I guess!!({location:undefined}).location// false
But on the other hand, if you expect a number, you will have weird failure on 0, which is very commonly a normal number. In which case you often check for undefined.
constfn1=(num=1)=>num// How would we write this without default notation?constfn2=num=>num||1// NO, YOU DIE!constfn3=num=>(num===undefined?1:num)// it's okay to not use typeof x === "undefined" in this context, it's a declared argument.
But it doesn't solve everything!
constwindow={location:{hostname:{valueOf:()=>"localhost"}}}consthostname=typeofwindow!=="undefined"&&window.location&&window.location.hostname""+hostname==="localhost"// The triple equals won't save you now, once string concatenation happened!
Maybe we should always use typeof :/
But what is your next action if hostname is an object? Pretending it wasn't set and defaulting to secure?
Honestly, truthiness seems like the best bet to me, I just need to keep track of when it can be a 0 or "" or a literal significant false and it'll be okay.
I think I'll just keep using that.
>(undefined).potatoes//TypeError: Cannot read property 'potatoes' of undefined>(null).potatoes//TypeError: Cannot read property 'potatoes' of null>(true).potatoesundefined// And it will never be anything truthy on a non-object, right? RIGHT?>(true).valueOf[Function:valueOf]// OH GOD DAMMIT!!
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.
Out of curiosity, before reading the article I copied the initial example and tried my best on it myself.
This is what I ended up with:
On one hand, I feel ridiculous I have a function that will only run once.
On the other, there are no
let
bindings in the file.I did consider
Array.prototype.includes()
but elected not to use it for just two elements.I don't think the RegEx has good readability, especially having had to escape the dots.
I also noticed that you used
===
for comparing to"undefined"
but==
for the domain.Is there a reason you are using
hasOwnProperty
instead of just the truthiness of the objects? Is it more performant?Myself, in the process of writing this, I went back and changed it, and was happily surprised that
So I loved that you took try at it. You did good!
Doing a function is typically a sure thing. It's never stupid to abstract out to a function. It's a great habit to practice. Even if it only gets used once, you are completely right about it helping to avoid having to do things such as declaring additional variables and also making the assignment highly clear
const secure = needsSecure()
vsconst secure = !isLocal;
.Now far as this part, you can do 1 better.
this instead, removing an additional
if
statement.With the RexEx, that was more of an option to show others that you could bring in RegEx to do your checking. But you and others have pointed out, that my goal was to make the code more readable... so to a lot of people, it's hard to read so therefore it did not make the code "easier to read".
Far as strict comparison, vs non-strict. That is a bad habit I need to break. You caught me red-handed lol. Stick with using strict comparison, and only use non-strict as needed.
Now for the final part,
hasOwnProperty
is there for a good reason. I am wanting to specifically check for a Boolean answer, sohasOwnProperty
will give me that. You can definitely do it your way and it'll work. When it's a single variable, that is how I do it.When I'm digging down in to an object I prefer to be more intentional with it by using
hasOwnProperty
So then, something like this?
I guess.
It's actually really unclear how to do such checks, you have to keep in mind what failures you actually expect to have.
On one hand, if you expect an object, truthiness gets rid of
null
,undefined
,false
(we'd be getting thefalse
from the typeof equality, as well ashasOwnProperty
) as well as less importantly0
, and""
.But on the other hand, if you expect a number, you will have weird failure on
0
, which is very commonly a normal number. In which case you often check for undefined.But it doesn't solve everything!
Maybe we should always use
typeof
:/But what is your next action if
hostname
is an object? Pretending it wasn't set and defaulting to secure?Honestly, truthiness seems like the best bet to me, I just need to keep track of when it can be a
0
or""
or a literal significantfalse
and it'll be okay.I think I'll just keep using that.