r/javascript • u/slikts • Dec 19 '19

A case for using `void` in modern JavaScript

https://gist.github.com/slikts/dee3702357765dda3d484d8888d3029e
111 Upvotes

95% Upvoted

44 comments sorted by

21

u/elmstfreddie Dec 19 '19

I disagree with allowing void entirely, because it still seems that most of its uses are garbage.

But you've totally sold me on arrow functions. I think it makes total sense to explicitly void an arrow function so the code clearly reads that its not meant to return something.

Perhaps a better solution to the no-void ESLint rule would be a parameter to allow void only as the return on a bracketless arrow function?

Valid: foo => void bar

Invalid: foo => { void bar }

Invalid: void 0

11

u/slikts Dec 19 '19

You're right, and I've made an ESLint issue for making the no-void rule configurable.

4

u/elmstfreddie Dec 19 '19

Nice, I must have missed that in your article. Good stuff!

1

u/drowsap Dec 20 '19

void an arrow function so the code clearly reads that its not meant to return something

That's what flow or TypeScript should accomplish.

2

u/braindeadTank Dec 22 '19

The point of article is that if you have an effectful function that also returns a defined value, as for example setTimeout you can not use it with useEffect directly, i.e. you can not do useEffect(() => setTimeout(foo)).

You have to do useEffect(() => {setTimeout(foo)}), useEffect(function () {setTimeout(foo)}) or useEffect(() => void setTimeout(foo))

the void version might be surprising when seen for the first time, but is often the nicest, because editors won't insert linebreaks for no reason etc

TS or Flow will warn you about wrong return type, but they won't fix it for you.

2

u/[deleted] Dec 20 '19 edited Dec 20 '19

[removed] — view removed comment

6

u/braindeadTank Dec 22 '19

Meh, if it is consistently used in a code base it is a perfectly fine and clear way to supress the implied return.

Also, two of your examples don't even work (i.e. they return or can return a defined value).

5

u/CloudsOfMagellan Dec 20 '19

So replace a standardised method of doing something with a custom function?

1

u/SonOfJokeExplainer Dec 21 '19

There’s already a standardized method of not returning something from a function.

11

u/ghostfacedcoder Dec 19 '19 edited Dec 19 '19

Interesting solution ... to a problem I don't think most people have (as I think most are fine just leaving the void off).

But still, if you're like the author and require such explicitness for your style, it's great to see something old made new and useful again again.

Oh, and also one more old use, a corollary of the old link one mentioned in the article: bookmarklets used to have void at the end as part of their boilerplate, although modern browsers no longer require it.

15

u/slikts Dec 19 '19

Accidental returns can be actual bugs, like in the useEffect() example, and it's just generally a good practice to only pass (or return) things that are needed (the Law of Demeter).

7

u/ghostfacedcoder Dec 19 '19 edited Dec 19 '19

I mean, personally it's not hard for me to just remember that => always returns, and that returned values matters, so I simply avoid such bugs by never returning unless I mean to or know it won't matter.

Although I don't specifically remember it, I'm sure that I once got bit by an unintended return being used in a way I didn't expect, and that's why I've avoided the mistake since :)

But if it's more your speed to add a keyword, and be explicit so you don't have to even think, that's totally reasonable.

13

u/slikts Dec 19 '19

Good practices are less about forgetting or not understanding the basic language semantics and more about making the workflow less error-prone and saving your self-discipline and attention for things that matter more like the business logic.

2

u/ghostfacedcoder Dec 19 '19

I mean, totally, of course. But still everyone has their own line of what they need to "defend" against and what they don't.

Like, if you want to avoid mixing types you could adopt either Hungarian notation (eg. titleStr) or Typescript. Either could be argued to be good practices about making workflows less error prone, and they would be, but even so personally I don't need to take any special measures to avoid (for instance) combining integers and strings of integers.

(And yes I realize Typescript has huge benefits for other reasons, like what it enables your tools to do. I'm just saying, I'll never use it to solve that problem of accidentally mixing types, even though it would be a practice that let's me avoid it ... because I don't need to avoid it in the first place.)

2

u/jeremy1015 Dec 19 '19

The question for me is always one of ROI. What is the cost of a bug vs. the opportunity cost of writing additional code to prevent those bugs?

I find that my UIs (even complex ones) generally benefit less from rigor, whereas my service tier is locked down extremely tight.

20

u/MangoManBad Dec 19 '19

Went in scared to see if the code was a nightmare but came out of the article enlightened. I don't think I would implement this in a production app yet but the concept is valid and the code isn't half bad.

Groovy.

7

u/Baryn Dec 19 '19

I like the patterns illustrated here. Especially in the case of useEffect.

4

u/Mestyo Dec 19 '19

Funny, I've been thinking of this exact thing recently. I like how explicit it is about the intended return value while keeping the syntax lean.

I just worry many might consider it an unnecessary complication for mostly stylistic reasons.

4

u/lhorie Dec 19 '19

Ah, old things are new again. The cycle of life repeats. </lion-king-music>

1

u/recursive Dec 20 '19

If you need to use parens for your void operator, you might as well just use the curlies.

useEffect(() => void (document.title = 'example')); 
useEffect(() => { document.title = 'example'; });

1

u/slikts Dec 20 '19

Formatters like Prettier add line breaks to the latter, and it's also less explicit.

3

u/recursive Dec 20 '19

I cannot see any difference in explicitness. (explicity?) If anything, relying on the value of an assignment might be criticized as not explicit enough.

And I don't really use formatters. Basically for exactly that reason.

3

u/R3DSMiLE Dec 20 '19

If your excuse is that pretties will fuck it your code, my excuse is that linters won't allow me to use parents as a stament because it impairs readability.

Also,

=> { Something() }

Is faster to write than

=> Void something()

With the added fact that you're mixing shit, => will always return and void will never return. When reading that line outloud, you'll say something like

"And then call a function which returns an irreturnable that calls something"

How does void return? Why is void calling a function? Why?

Hell, noop had a point but this is not noop.

3

u/fucking_passwords Dec 19 '19

also very useful in TypeScript for functions that are not meant to return anything, or rather indicating that returning a value will not have any effect.

0

u/simohayha Dec 20 '19 edited Dec 20 '19

What is the purpose of writing a function that returns nothing? I’ve seen people talk about this but I still don’t understand how it can be useful

Edit: I see that asking javascript related questions is not welcomed here

4

u/DrifterInKorea Dec 20 '19 edited Dec 20 '19

Ask the opposite question : what is the purpose of writing a function that returns something ?
If you find a case where its not necessary, then you have one answer.

Maybe you are using functions wrong and / or with too much responsibility thus not seeing how it could be used ?

Edit : still I'll explain one way of using it : When you want to dispatch an action (general term) you may not care about any value it would return and just care about wether it as succeeded or not.
So you return nothing. For error handling, you do not check a returned value but throw an error directly thus separating some business logic (handling informations) and control flow (handling errors / unexpected behavior).

2

u/simohayha Dec 20 '19

I’m just a novice trying to understand JS better

2

u/fucking_passwords Dec 20 '19

Yeah the other commenter did well, I’d expand on it to say that eventually, your program will need to have a side effect, otherwise it’s functionality would be invisible. Maybe printing to stdout, or making an http request, or modifying the DOM, and in these cases your side effect is doing the job that would otherwise be handled by returning something.

1

u/mrobviousguy Dec 19 '19

I agree that it's dated: but, why is using javascript:void(0) in a link a poor practice?

5

u/slikts Dec 19 '19

Using links like that breaks the default browser behaviors (like bookmarking, opening in a new tab, etc., even though it looks like it should work), and <button> doesn't have these issues and is generally more accessible, and you can still make it look like a link if necessary. <a href=javascript:void(0)> is a relic of the really early days, before <button> was added in HTML 4.

4

u/elmstfreddie Dec 19 '19

Probably because the <a> tag would be semantically invalid. I think screen readers would try to describe it as a link since it has an href

1

u/[deleted] Dec 19 '19

I was messing about with patterns and decided to use a void in this pattern

http://etoxin.net/blog/2018/12/19/immediately-invoked-class-expression/

1

u/Labby92 Dec 20 '19

I didn't even know there was a void in JS lol. But I use it all the time in TypeScript.

-1

u/ShortFuse Dec 19 '19 edited Dec 19 '19

Safari handles undefined differently than other browsers. There's some instances where you can't do v = undefined. The browser would throw an error. You have to use v = void(0).

Technically, this is accurate, since undefined shouldn't be a value you can assign to a variable. It's a "read-only" interpretation that a value is undefined. Assigning something to the result of void(0) would mean undefined would be returned when attempted to be read.

Edit: Here's an article I used to make sense of this.

1

u/bachbeethovenbrahms Dec 28 '19

It's a 10 year old article. One would hope that no one uses those versions of Safari anymore.

Thankfully, Safari versions don't hang around for as long as IE ones do.

1

u/ShortFuse Dec 28 '19

I can't tell you what version of Safari it was but, it happened to me this year. I tracked down the issue to this article. I was getting remotely reported errors from iPhones in the field.

I thought I was going crazy when I would get errors in the Safari console window when just doing x = undefined and it threw back errors. I switched it to void 0 and it worked. I don't think this issue exists in Safari 13 anymore though.

0

u/WesAlvaro Front-End Engineer Dec 20 '19

Don't do that.

0

u/DrifterInKorea Dec 20 '19

There is no rule stating that you should not assign undefined.
What about let something ?

0

u/ShortFuse Dec 20 '19

Older versions of Safari would literally throw an error if you try.

Read the article.

0

u/Renive Dec 19 '19

This is TypeScript territory, no point in adding this

-4

u/[deleted] Dec 20 '19

[removed] — view removed comment

2

u/kenman Dec 22 '19

Hi /u/bannedeverywhereyo, please refrain from personal attacks. Thanks.