I'll be discussing the newest JavaScript/Typescript tips which also includes ES2020 additions & Typescript's new type related additions in this...
For further actions, you may consider blocking this person and/or reporting abuse
I agree with the
+
, it should not be used that often, if ever.But, it's not always about speed, I think he was just showing other less common methods, that are useful in some scenarios. Though I have tested and It's quite a lot slower, around 27%. Benchmark here
Though this post was not about performance, I think it's always good to advise people.
You mean advise* people. Thank you dot the feedback
I've updated the post to point out the potential problems that can occur for using
+
instead ofparseInt
/parseFloat
. Also mentioned the performance penalty forfor_of
loop withArray.entries
so that everyone stays informed...Thanks to all of you, who've corrected this out. You guys rock💪
Yeah, I saw the difference.
for_of
is almost 20%-30% slower thanforEach
. It makes sense asArray.entries
has to take an iteration to map out the index. I wonder why there's no native way of getting the index infor_of
without a performance penalty🤔!for_of
is so much more readable & mitigates the callback hell at least a little bitAlso I wouldn't really recommend anyone to use
+
instead ofperseInt
orparseFloat
. Just mentioned as it is also doable tooThank you so much for your corrections❤️
If you wanted an index to reference, but want to use
for...of
you'd be better off (performance wise) using a variable to track it.I'm still on the edge of converting to parseInt parseFloat sect. But their behavior to convert '23 somestring' to 23 still off putting to me.
Looks like a possible silent failure for edge cases
Edit: I found an actual case, bennadel.com/blog/3803-i-prefer-th...
I am not saying + is better overall, but it has better behavior in this case
A counter argument.
I feel
+
for number conversion is extremely common in JS and readable. The behavior meets expectation well, it can be float or integer when I don't care.It looks intentful, since everyone know JS type coercion.
I will give code a pass.
That's true, I can agree with that. The example was a weird use-case, but entries has some uses though.
Funny, on my test benchmark I realized that a regular for is slower than forEach in that particular example, wich surprised me a bit. I'm guessing the engine is doing some optimization, which are not done for regular fors...
That optional function call. Thank you
Ah, that one really made me amazed when I found it accidentally while optionally chaining objects where one of the property was actually a method😅
not sure, why i would do this
```const moods = ['good', 'better', 'best']
for ([idx, mood] of moods.entries()) {
console.log(
${index}. ${mood}
)}```
In my opinion looks a little bit more complicated
For sure! Not much point in using
for...of
in this use case when afor
will do just fine, but I'd also never do afor...of
witharr.entries()
so there's that too 😂I agree,
+
to convert something to a number is a hack. It also converts empty string to 0, which can lead to bugs. Better to useNumber.parseInt()
(or parseFloat) and then do a NaN check.It always bothered me that the override keyword wasn't required, I'm definitely adding this noImplicitOverride: true setting to our project now that I know it exists.
Optional function calls? Damn, JS/TS is lookin' good, fellas! The more of this comes up, the more I love its syntax!
Type shadowing is a function overloading
Very helpful, thanks
You're most welcome
I first knew Type Shadowing concept. I didn't found this concept in TS official docs. Is it functions overloads?
For functions yeah, it is known as function overloading too
ty
Cheers, I agree
Yeah, that one isn't. But outside arithmetic it's ok.
It just need common sense to know mixing + and arithmetic is bad. Well, lots of people has no common sense, haha.
Vlogmo.com has the cheapest courses