Legitimate uses of IIFEs?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Legitimate uses of IIFEs?

Šime Vidas
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.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Fabrício Matté
You can use II(A)FE to summon strict mode in sloppy contexts (such as Chrome's DevTools console):

```js
(() => {
  'use strict';
  // ...
})();
```

This is useful as Chrome either does not implement or uses legacy semantics for quite a few ES2015 features in sloppy mode (e.g. let, const).

As for real code you would write, seeing as ECMAScript modules are implicitly strict and we should have do-expressions soon, I don't see much use for IIFEs anymore.

/fm

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Caitlin Potter
Note that currently, you can't set the language mode in a do-expression. Of course that could change, i think they're wanting to change a bunch of other things already.

> On Dec 19, 2015, at 2:54 PM, Fabrício Matté <[hidden email]> wrote:
>
> You can use II(A)FE to summon strict mode in sloppy contexts (such as Chrome's DevTools console):
>
> ```js
> (() => {
>   'use strict';
>   // ...
> })();
> ```
>
> This is useful as Chrome either does not implement or uses legacy semantics for quite a few ES2015 features in sloppy mode (e.g. let, const).
>
> As for real code you would write, seeing as ECMAScript modules are implicitly strict and we should have do-expressions soon, I don't see much use for IIFEs anymore.
>
> /fm
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Dmitry Soshnikov
In reply to this post by Šime Vidas


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Fabrício Matté
Good call, Dmitry. Async IIFEs are also useful to parallelize different sequences of async operations. E.g.:

```js
async function main() {
  await* [
    (async () => await seq1op2(await seq1op1()))(),
    (async () => {
      await seq2op1();
      await seq2op2();
    })(),
  ];
}
```

Here is a more solid example.

/fm

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

bread
In reply to this post by Dmitry Soshnikov
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 <[hidden email]> wrote:


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Fabrício Matté
@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, <[hidden email]> 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 <[hidden email]> wrote:


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

bread

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é <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> wrote:


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

bread
In reply to this post by Fabrício Matté
I believe await* has gone from the spec. The correct form would be (at the top-level):

```js

Promise.all(asyncFn1(...), asyncFn2(...),...).then(...)

```

The mistake in Dimitry's example is that the async body was not resolved, not that anonymous async functions are in some way invalid - they're just fine.

On 19 December 2015 20:47:57 -00:00, Fabrício Matté <[hidden email]> wrote:
Good call, Dmitry. Async IIFEs are also useful to parallelize different sequences of async operations. E.g.:

```js
async function main() {
  await* [
    (async () => await seq1op2(await seq1op1()))(),
    (async () => {
      await seq2op1();
      await seq2op2();
    })(),
  ];
}
```

Here is a more solid example.

/fm


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Fabrício Matté
On Sat, Dec 19, 2015 at 8:10 PM, <[hidden email]> wrote:
I believe await* has gone from the spec. The correct form would be (at the top-level):

True, I guess `await*` never made it to the proposal's formal text. It still worked in Babel the last time I checked, though. FWIW, `await* []` would desugar to `await Promise.all([])`.
 
The mistake in Dimitry's example is that the async body was not resolved, not that anonymous async functions are in some way invalid - they're just fine.

I'm not sure if I understand what you mean. I see that the outer synchronous function would not await until the async function finished—i.e. the outer function would return before the promise was resolved/settled—, but that is still valid syntax—you could be running the async code for side-effects that the caller context does not need to be aware of. You mentioned this was invalid syntax, and that was the initial point I addressed. :)

/fm

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Isiah Meadows-2

One use case is where try-catch statements are required. I've had plenty of these, and it's either declare the variable ahead of time, or wrap in a IIFE.

Another use case: early returns and complex logic. This is pretty nice when you're working with a complex set of conditions for a polyfill. I came across this conditionally spawning a worker with a static implementation, which included complex logic, early returns, and try-catch. Only the return value was needed in the outer scope, so an IIFE simplified it.

```js
;(() => {
  if (window.somethingSimple) {
    return somethingSimple(foo, bar)
  }

  let res

  // super complex workaround by necessity

  return res
})()
```


On Sat, Dec 19, 2015, 17:46 Fabrício Matté <[hidden email]> wrote:
On Sat, Dec 19, 2015 at 8:10 PM, <[hidden email]> wrote:
I believe await* has gone from the spec. The correct form would be (at the top-level):

True, I guess `await*` never made it to the proposal's formal text. It still worked in Babel the last time I checked, though. FWIW, `await* []` would desugar to `await Promise.all([])`.
 
The mistake in Dimitry's example is that the async body was not resolved, not that anonymous async functions are in some way invalid - they're just fine.

I'm not sure if I understand what you mean. I see that the outer synchronous function would not await until the async function finished—i.e. the outer function would return before the promise was resolved/settled—, but that is still valid syntax—you could be running the async code for side-effects that the caller context does not need to be aware of. You mentioned this was invalid syntax, and that was the initial point I addressed. :)

/fm
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Forbes Lindesay
In reply to this post by bread
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 <[hidden email]> 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é <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> wrote:


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

bread
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 <[hidden email]> 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 <[hidden email]> 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é <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> wrote:


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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 mailing list


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Andrea Giammarchi-2
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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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é <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> wrote:


On Saturday, December 19, 2015, Šime Vidas <[hidden email]> 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 mailing list


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Bergi
Andrea Giammarchi schrieb:

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

I think a top-level (read: module-level) `await` could solve this quite
elegantly.

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

That would be up to the loader. But I don't think a module loader should
mess with these things, for various reasons. Error (=rejection) handling
would be obscure. Sometimes I *want* to export promises without anyone
awaiting them. And of course, exports do resolve to variable bindings,
not to values, so this would be hard to align with the current spec.

Regards,
  Bergi
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Dmitry Soshnikov
In reply to this post by bread


On Sunday, December 20, 2015, <[hidden email]> 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?


The use case is valid, there was no mistakes. We use async IIFEs as an "entry point" to async code: you can await there, do intermediate calculations with temporary variables, again awai, etc (Promise.all has a different use case).

Dmitry 

 

On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;forbes@lindesay.co.uk&#39;);" target="_blank">forbes@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bread@mailed.me.uk&#39;);" target="_blank">bread@...> 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é <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ultcombo@gmail.com&#39;);" target="_blank">ultcombo@...> 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, <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bread@mailed.me.uk&#39;);" target="_blank">bread@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;dmitry.soshnikov@gmail.com&#39;);" target="_blank">dmitry.soshnikov@...> wrote:


On Saturday, December 19, 2015, Šime Vidas <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;sime.vidas@gmail.com&#39;);" target="_blank">sime.vidas@...> 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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;es-discuss@mozilla.org&#39;);" target="_blank">es-discuss@...

_______________________________________________
es-discuss mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;es-discuss@mozilla.org&#39;);" target="_blank">es-discuss@...


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

bread

I don't dispute you can do it, I just don't see it as necessary, or at least any more necessary than using an IIFE to collect together synchronous logic. The creation of the scope is not a factor here.

On 20 December 2015 9:54:59 pm Dmitry Soshnikov <[hidden email]> wrote:



On Sunday, December 20, 2015, <[hidden email]> 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?


The use case is valid, there was no mistakes. We use async IIFEs as an "entry point" to async code: you can await there, do intermediate calculations with temporary variables, again awai, etc (Promise.all has a different use case).

Dmitry 

 

On 20 December 2015 13:40:30 -00:00, Forbes Lindesay <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;forbes@lindesay.co.uk&#39;);" target="_blank">forbes@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bread@mailed.me.uk&#39;);" target="_blank">bread@...> 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é <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ultcombo@gmail.com&#39;);" target="_blank">ultcombo@...> 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, <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bread@mailed.me.uk&#39;);" target="_blank">bread@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;dmitry.soshnikov@gmail.com&#39;);" target="_blank">dmitry.soshnikov@...> wrote:


On Saturday, December 19, 2015, Šime Vidas <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;sime.vidas@gmail.com&#39;);" target="_blank">sime.vidas@...> 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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;es-discuss@mozilla.org&#39;);" target="_blank">es-discuss@...

_______________________________________________
es-discuss mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;es-discuss@mozilla.org&#39;);" target="_blank">es-discuss@...


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Fabrício Matté
In reply to this post by Andrea Giammarchi-2
On Sun, Dec 20, 2015 at 7:32 PM, <[hidden email]> wrote:
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?
 
I believe the advantage is that you can then replace the `.then(onFulfilled, onRejected)` constructs with `await/try/catch`, thus simplifying the code and improving readability. I recognize this may be an uncommon pattern though, as most often the caller of an async function will be an async function as well. Note that I say "uncommon" referring to async IIFEs inside non-async functions; async IIFEs are still very useful to parallelize sequences of async operations as I've mentioned before.

Btw, the term "IIAFE" should probably be avoided, as the "A" can ambiguously mean "Arrow" or "Async".

/fm

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Bergi
Fabrício Matté schrieb:

> Btw, the term "IIAFE" should probably be avoided, as the "A" can
> ambiguously mean "Arrow" or "Async".

I've never heard of an "Arrow function expression" - it's just "arrow
function" :-)
I think it would always be clear from the context anyway.

Regards,
  Bergi
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Legitimate uses of IIFEs?

Andrea Giammarchi-2
In reply to this post by Fabrício Matté
I'm trying to figure out how worlds based on current modules ecosystem would work ...

```js
let
  path = require('path'),
  lib = require(path.join(__dirname, 'lib/index.js'))
;
```

How even in an ES2015 world would that look like?

Putting async/await everywhere doesn't seem like a real answer ... or does it?




On Sun, Dec 20, 2015 at 10:07 PM, Fabrício Matté <[hidden email]> wrote:
On Sun, Dec 20, 2015 at 7:32 PM, <[hidden email]> wrote:
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?
 
I believe the advantage is that you can then replace the `.then(onFulfilled, onRejected)` constructs with `await/try/catch`, thus simplifying the code and improving readability. I recognize this may be an uncommon pattern though, as most often the caller of an async function will be an async function as well. Note that I say "uncommon" referring to async IIFEs inside non-async functions; async IIFEs are still very useful to parallelize sequences of async operations as I've mentioned before.

Btw, the term "IIAFE" should probably be avoided, as the "A" can ambiguously mean "Arrow" or "Async".

/fm


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12