I now reach for this a lot to allow me to write expression oriented programs in JS
williamdclt 1 days ago [-]
Yeah I remember reading this post, thinking "whatever" about it, and then finding myself implementing and using it regularly-ish.
Usually I use it to encapsulate a complicated initialisation of a variable, where some mutation is needed/easier. I still want colocation for readability, but I dont want intermediate variables in the scope or to declare the variable as mutable
motorest 5 days ago [-]
This blog post is referenced by Mozilla's page on IIFE.
I frequently reach for IIFE when I use switch/case. It's a very convenient (if maybe a bit weird looking) way of turning a statement into an expression. In other words, `return 1` instead of `foo = 1; break` for a trivial example.
hn_go_brrrrr 24 hours ago [-]
Yes, this is works really well even outside of JS.
ackfoobar 24 hours ago [-]
In languages where more control flow constructs are expressions (if, match, try-catch) I don't need this, except if you count `run` in Kotlin.
What language are you thinking of?
insin 22 hours ago [-]
Missing my favourite when you don't care about a return value, which I personally find less fussy to type and look at (good for confusing Java developers who don't share the fullness of the stack, too):
void function() {
…
}()
Escpecially when I can't be bothered to stop and extract an async function out when there's a sudden need to wait in a non-async context, handy when in the middle of adding features to browser extensions for apps:
let $el = document.querySelector(…) // oops, not available yet
void async function() {
let $el = await waitForElement(…)
}()
One of the things I hated most about using JavaScript in that era was the proliferation of long chains of }); or whatever the order was. IIFEs were a major contributor to that.
It's okay to name your functions. Flat is better than nested.
apothegm 4 days ago [-]
Those infuriate me so much when I need a slight modification to the behavior of a third party library. Leaves no option but forking. There are such better ways to achieve encapsulation in modern JS.
austin-cheney 1 days ago [-]
It's not so much about the encapsulation. Since ES6 you can achieve encapsulation more directly through an arbitrary block, such use of curly braces not associated with a loop, condition, or object. This is what older languages like C and SQL call a procedure.
The primary value of IIFE is that it is encapsulation that outputs to a value and data type. For example if an IIFE returns a string then it looks like a function, behaves like a function, but it is a primitive string type.
motorest 4 days ago [-]
> There are such better ways to achieve encapsulation in modern JS.
There aren't that many options even in modern JavaScript. You have ES6 modules, store state in a global map, what else?
apothegm 3 days ago [-]
Classes?
You don’t need a LOT of options. Just at least one that’s better and more extensible than this pattern.
recursive 1 days ago [-]
Closure to local variables
webstrand 1 days ago [-]
Yarn and pnpm have a `patch` utility and apply patches on install. It's how I fix pain points like this without a full on fork.
Rendered at 22:14:10 GMT+0000 (Coordinated Universal Time) with Vercel.
I now reach for this a lot to allow me to write expression oriented programs in JS
Usually I use it to encapsulate a complicated initialisation of a variable, where some mutation is needed/easier. I still want colocation for readability, but I dont want intermediate variables in the scope or to declare the variable as mutable
https://developer.mozilla.org/en-US/docs/Glossary/IIFE
What language are you thinking of?
It's okay to name your functions. Flat is better than nested.
The primary value of IIFE is that it is encapsulation that outputs to a value and data type. For example if an IIFE returns a string then it looks like a function, behaves like a function, but it is a primitive string type.
There aren't that many options even in modern JavaScript. You have ES6 modules, store state in a global map, what else?
You don’t need a LOT of options. Just at least one that’s better and more extensible than this pattern.