Immediately-Invoked Function Expression (2010)(benalman.com)
benalman.com
Immediately-Invoked Function Expression (2010)
https://benalman.com/news/2010/11/immediately-invoked-function-expression/
6 comments
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
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
This blog post is referenced by Mozilla's page on IIFE.
https://developer.mozilla.org/en-US/docs/Glossary/IIFE
https://developer.mozilla.org/en-US/docs/Glossary/IIFE
Nice one, never seen this
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.
Yes, this is works really well even outside of JS.
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?
What language are you thinking of?
C++
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() {
…
}()
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.
It's okay to name your functions. Flat is better than nested.
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.
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.
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 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?
There aren't that many options even in modern JavaScript. You have ES6 modules, store state in a global map, what else?
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.
I now reach for this a lot to allow me to write expression oriented programs in JS