Legitimate uses of IIFEs?

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Dec 20 20:36:08 UTC 2015


Funny I've being advocating IIFE mostly for cross platform modules since I
believe the moment you need an IIFE is because your code is where it
shouldn't, within some other code instead of being in a module a part.

At least that's what JS has been for a while before let and const made it
and before nodejs require or ES2015 import existed.

Reading this thread felt like one problem is gone and another is coming ...
and to be honest, a `module.exports = new Promise(myModule);` should most
likely become a new standard for asynchronously defined modules in the
node.js world, and I've no idea how that could be represented through the
current ES2015 specs which seem to assume every module loading could be
asynchronous, but the exported behavior would  be definitively sync.

... or maybe I am missing something, like the fact if a module export a
Promise it's automatically usable no matter if the requester was within a
sync execution or async?

Thanks whoever for clarification!






On Sun, Dec 20, 2015 at 7:32 PM, <bread at mailed.me.uk> wrote:

> You're quite right, which demonstrates the lack of necessity for a
> top-level await (FYI, I find the inconsistency irritating but
> understandable), so I still maintain this is not a _required_ use for an
> IIAFE - there is no reason to create an async function to invoke another
> async function; one can simply invoke it, and if the result/completion is
> required, use it's ,then() member....but there's no need/advantage to
> wrapping such an invocation in an IIAFE, right?
>
>
> On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <
> forbes at lindesay.co.uk> wrote:
>
> Promises are eager.  That is, they do the work and resolve whether you
> await them or not.  If you want to handle exceptions, you need to call
> .then and provide an error handler, but other than that it's totally ok to
> not bother waiting for a promise.
>
> On 19 Dec 2015, at 22:02, Mat At Bread <bread at mailed.me.uk> wrote:
>
> Which is what I said, I hope. Use the .then for top-level invitation.
> Dimitry's example wouldn't resolve the Promise
>
> On 19 December 2015 9:24:04 pm Fabrício Matté <ultcombo at gmail.com> wrote:
>
> @bread I see you are referencing Dmitry's sample, but why do you say it
> won't work? AFAIK async functions return promises, so you don't necessarily
> need a top-level `await`. I believe this (extremely ugly) sample should
> work:
>
> ```js
> function f(cb) {
>   (async function() {
>     // await here
>   })().then(v => cb(null, v), cb);
> }
> ```
>
> /fm
>
> On Sat, Dec 19, 2015 at 7:11 PM, <bread at mailed.me.uk> wrote:
>
> That’s not going to work. The correct form still requires an (illegal)
> top-level await:
>
> await (async function() {
> // await here
> })();
>
> The easiest way to spawn a top-level async function is:
>
> here.then(function(result){},function(error){}) ;
>
> On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov <
> dmitry.soshnikov at gmail.com> wrote:
>
>
>
> On Saturday, December 19, 2015, Šime Vidas <sime.vidas at gmail.com> wrote:
>
> With block statements + let/const, IIFEs are no longer needed to emulate
> block-scoped variables. That got me thinking, are there other uses of
> IIFEs, or are they no longer needed?
> I’ve checked my code and found instances of this pattern:
>
> var foo = (function () {
>     var a, b, c; // helper variables
>     // some computation
>     return /* final value of foo */;
> }());
> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
> pattern.
> Anything else?
>
>
> FWIW, one of the still valid use cases is async IIFE, to spawn an async
> code (since there's no yet top-level async/await)
>
> (async function() {
>   // await here
> })();
>
> Dmitry
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151220/6fb37dd7/attachment.html>


More information about the es-discuss mailing list