3 ms·
> 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
by bogdan 2y ago
> 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/Reference/Operators/void https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- teamonkey 2y agoIs there any reason you’d want to do this?
- winrid 2y agosaves a couple bytes if you're not using a modern build system :)
- leosanchez 2y agoI think minifiers use 'void 0' instead of undefined.
- pintxo 2y agoExecuting something with side-effects when you don’t care for the return value?
- gbalduzzi 2y agothan just don't save the returned value? If you don't want the result, just call someFunction() instead of const a = void someFunction()
- Mustachio 2y agoI've seen it being used before to call async operations within a class constructor. Hated it though.
- chrisldgk 2y agoIt’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.
- throwitaway1123 2y agoSome 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-using-void https://immerjs.github.io/immer/return#inline-shortcuts-usin...
- DemocracyFTW2 2y agoMy 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<<
- demurgos 2y agoAs 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.