Hacker News Reader

Comment by bogdan | Hacker News Reader

> void doesn’t introduce any new semantics to the language.

I'm sure the author is most likely aware of this plus the context is around TypeScript but I think it can still be misunderstood and if you haven't been around when IIFE were very common you might not be aware that:

`void` is a javascript operator and it does have semantic meaning, it evaluates an expression and returns undefined.

   const a = void 1;
   console.log(a); // undefined

see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

View on HN

Is there any reason you’d want to do this?

saves a couple bytes if you're not using a modern build system :)

I think minifiers use 'void 0' instead of undefined.

Executing something with side-effects when you don’t care for the return value?

than just don't save the returned value?

If you don't want the result, just call

someFunction()

instead of

const a = void someFunction()

I've seen it being used before to call async operations within a class constructor. Hated it though.

It’s good for firing off an async function in sync contexts, like for example a fetch request with side-effects being called by React‘s useEffect hook. That‘s the only context where I found any value for it though, and its usefulness is only in describing that we really don’t care if it finishes or not (since handling that case will happen somewhere else) directly in the function call.

Some functions accept a callback and behave differently depending on whether or not the callback returns a value. If your callback is a single expression arrow function, then you might find it cleaner to just void the result instead of wrapping the body of the function in a code block (which prettier will format using multiple lines). Super contrived example:

  import { produce } from 'immer'
  
  let i = 1
  const a = produce({ x: 0 }, draftState => i++)
  const b = produce({ x: 0 }, draftState => void i++)
  const c = produce({ x: 0 }, draftState => {
    i++
  })
  console.log({ a, b, c }) // Logs: { a: 1, b: { x: 0 }, c: { x: 0 } }

The immer docs have a section about this pattern: https://immerjs.github.io/immer/return#inline-shortcuts-usin...

My answer from decades of experience is "No, why would you?". But like the precious gadget that turned out to be better used as a door stopper `void null` is sometimes used as a safeguard instead of `undefined` because in JS you can re-define `undefined`. >>Sigh<<

As mentioned in the article, you can declare a binding named `undefined` and assign a value to it. This shadows the base `undefined` binding (since it's NOT a keyword).

`void 0` ensures that you get the `undefined` value regardless of any shadowing that may be happening with the `undefined` binding.

Reply on news.ycombinator.com