Legitimate uses of IIFEs?

bread at mailed.me.uk bread at mailed.me.uk
Mon Dec 21 17:47:52 UTC 2015


Ok, I'm convinced :)

Whether the solution is to invent new syntax or not is moot. It occurred to me that 'async' could be used as a modifier preceding a block, e.g.

async {
let user = await fetchUser(id);
let scores = user.scores.map(score => score.latest);
let data = await fetchData(scores);
}

...with the caveat (of course) that the body will execute out of order. Or possibly modify the 'do' specification to stipulate that the body of the do {} has the semantics of an async function body, allowing 'await' to be implemented as a keyword. This would seem to fit in better with the OPs observation that do, amongst other constructs, renders IIFEs less necessary than before.

On 20 December 2015 23:48:42 -00:00, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

> But how would you make an async entry point? Say, you have couple of async functions which you imported, they should be ran sequentily, depending on each other:
> 
> let user = await fetchUser(id);
> let scores = user.scores.map(score => score.latest);
> let data = await fetchData(scores);
> 
> What should be an entry point to this async code, if thete is no top-level await?
> Having an async IIFE for the purpose of an entry point seems fits well here. How else would you do this, except an async function declaration, and further its execution?
> 
> function asyncEntryPoint() {
> // await here
> }
> 
> 
> asyncEntryPoint();
> // .then(...); // not needed
> 
> Dmitry
> 
> On Dec 20, 2015 13:57, "Mat At Bread" <<bread at mailed.me.uk>> wrote:
> 
> > 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 <<dmitry.soshnikov at gmail.com>> wrote:
> > 
> > > 
> > > 
> > > On Sunday, December 20, 2015, <<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?
> > > > 
> > > > 
> > > 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 <> 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 <> 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é <> 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, <> 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 <> wrote:
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Saturday, December 19, 2015, Šime 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
> > > > > > > > 
> > > > > > > > <https://mail.mozilla.org/listinfo/es-discuss>
> > > > > > > > 
> > > > > > > > 
> > > > > > _______________________________________________
> > > > > > es-discuss mailing list
> > > > > > 
> > > > > > <https://mail.mozilla.org/listinfo/es-discuss>
> > > > > > 
> > > > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151221/a8a7c7d5/attachment.html>


More information about the es-discuss mailing list