DEV Community

JavaScript/Typescript Tips compilation 2021🚀

Kingkor Roy Tirtho on August 03, 2021

I'll be discussing the newest JavaScript/Typescript tips which also includes ES2020 additions & Typescript's new type related additions in this...
Collapse
 
nombrekeff profile image
Keff • Edited

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.

Collapse
 
gruckion profile image
Stephen Rayner

You mean advise* people. Thank you dot the feedback

Collapse
 
krtirtho profile image
Kingkor Roy Tirtho

I've updated the post to point out the potential problems that can occur for using + instead of parseInt/parseFloat. Also mentioned the performance penalty for for_of loop with Array.entries so that everyone stays informed...

Thanks to all of you, who've corrected this out. You guys rock💪

 
zulvkr profile image
zulvkr • Edited

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

Collapse
 
krtirtho profile image
Kingkor Roy Tirtho

Yeah, I saw the difference. for_of is almost 20%-30% slower than forEach. It makes sense as Array.entries has to take an iteration to map out the index. I wonder why there's no native way of getting the index in for_of without a performance penalty🤔! for_of is so much more readable & mitigates the callback hell at least a little bit

Also I wouldn't really recommend anyone to use + instead of perseInt or parseFloat. Just mentioned as it is also doable too

Thank you so much for your corrections❤️

Collapse
 
jamesthomson profile image
James Thomson

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.

const array1 = ['a', 'b', 'c'];
let i = 0;
for (const element of array1) {
  console.log(element,i);
  i++;
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
zulvkr profile image
zulvkr

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.

Collapse
 
mistval profile image
Randall • Edited

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 use Number.parseInt() (or parseFloat) and then do a NaN check.

Collapse
 
dhatguy profile image
Joseph Odunsi

That optional function call. Thank you

Collapse
 
krtirtho profile image
Kingkor Roy Tirtho

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😅

Collapse
 
sesay profile image
sesay

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

 
jamesthomson profile image
James Thomson

For sure! Not much point in using for...of in this use case when a for will do just fine, but I'd also never do a for...of with arr.entries() so there's that too 😂

 
nombrekeff profile image
Keff

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...

Collapse
 
captainyossarian profile image
yossarian

Type shadowing is a function overloading

Collapse
 
bglamadrid profile image
Benjamin La Madrid

Optional function calls? Damn, JS/TS is lookin' good, fellas! The more of this comes up, the more I love its syntax!

Collapse
 
talr98 profile image
Tal Rofe

Very helpful, thanks

Collapse
 
krtirtho profile image
Kingkor Roy Tirtho

You're most welcome

Collapse
 
demeno profile image
Demeno

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.

Collapse
 
gruckion profile image
Stephen Rayner

Cheers, I agree

 
zulvkr profile image
zulvkr • Edited

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.

Collapse
 
joshuapozos profile image
Joshua Pozos

ty

Collapse
 
64467904macias profile image
Juan macias

Vlogmo.com has the cheapest courses

Collapse
 
mrdulin profile image
official_dulin • Edited

I first knew Type Shadowing concept. I didn't found this concept in TS official docs. Is it functions overloads?

Collapse
 
krtirtho profile image
Kingkor Roy Tirtho

For functions yeah, it is known as function overloading too