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