4 ms·

Suppose the events in question are network messages arriving via DOM callback. You call getNextEvent() and then what? You're not inside the event callback, so t

by ThJ 8y ago

Suppose the events in question are network messages arriving via DOM callback. You call getNextEvent() and then what? You're not inside the event callback, so there's no event to hand back. You could push events onto an array as they arrive in the event callback and pop them off from getNextEvent(), but how? You can't await an array. Iterators won't help you either, because they are for pulling multiple results out of a function synchronously, not having multiple results pushed to the caller asynchronously. That's what asynchronous iterators / generators are for. Think of it like looping through an array, except the loop will halt to wait for elements that aren't populated yet.

ThJ 8y ago
Now, on top of that, add the ability to run map(), reduxe() and filter() on a series of events. Instead of having to wait for all the elements in an array to be available, you can process it as you're receiving it, yet treat it as an already complete array in terms of being able to filter and transform it. It's a very powerful concept and I suggest you read about Observables in the RXJS docs. It took a while before it clicked for me.
- jack9 8y ago
  > run map(), reduxe() and filter() on a series of events. Can't you do that with a btree already?
tzahola 8y ago
Yeah... Well, I'm pretty sure you're wrong: 'use strict'; function getNextEvent() { return new Promise(resolve => { document.getElementById('button').onclick = event => resolve(event); }) } async function enterEventLoop() { let event = null; while (event = await getNextEvent()) { alert(event); } } enterEventLoop(); And thanks for recommending RxJS, but I've been using reactive programming on various platforms for the past 6 years, so I'm pretty sure it already had "clicked" for me.
- lmeyerov 8y ago
  Neat, I'd think the same example applies to Rx! Likewise, their library (seems to) do modular imports, which gives pay-as-you-go tree shaking. This is a good push to clarify that!
- ThJ 8y ago
  Reassigning the event handler? That doesn't count. What if that was a WebSocket connection? Would you keep removing and adding event handlers? What if the JS engine decided to invoke the 'message' event handler 3 times in a row before invoking the next iteration of that loop? Or alternatively, what if your event loop needed to call an async function before it could process the next message, and another event fired in the meanwhile? You'd only receive the first message.

by ThJ 8y ago

ThJ 8y ago

Now, on top of that, add the ability to run map(), reduxe() and filter() on a series of events. Instead of having to wait for all the elements in an array to be available, you can process it as you're receiving it, yet treat it as an already complete array in terms of being able to filter and transform it. It's a very powerful concept and I suggest you read about Observables in the RXJS docs. It took a while before it clicked for me.

jack9 8y ago
> run map(), reduxe() and filter() on a series of events. Can't you do that with a btree already?

tzahola 8y ago

Yeah... Well, I'm pretty sure you're wrong: 'use strict'; function getNextEvent() { return new Promise(resolve => { document.getElementById('button').onclick = event => resolve(event); }) } async function enterEventLoop() { let event = null; while (event = await getNextEvent()) { alert(event); } } enterEventLoop(); And thanks for recommending RxJS, but I've been using reactive programming on various platforms for the past 6 years, so I'm pretty sure it already had "clicked" for me.

lmeyerov 8y ago
Neat, I'd think the same example applies to Rx! Likewise, their library (seems to) do modular imports, which gives pay-as-you-go tree shaking. This is a good push to clarify that!
ThJ 8y ago
Reassigning the event handler? That doesn't count. What if that was a WebSocket connection? Would you keep removing and adding event handlers? What if the JS engine decided to invoke the 'message' event handler 3 times in a row before invoking the next iteration of that loop? Or alternatively, what if your event loop needed to call an async function before it could process the next message, and another event fired in the meanwhile? You'd only receive the first message.