-
(hidden) okkVHfNbw #[[(hidden) 14uLM_cGQ]]
-
(hidden) lLU_F9CwA
-
(hidden) 5_jmy0l-t
-
(hidden) f8_qHT9X4
-
(hidden) 8DmEfYuec [[(hidden) UbrBiwJcK]]
-
(hidden) 4z4DfgVHy
-
(hidden) sQII8pg3R
-
(hidden) e77O8u2uC
-
(hidden) WzQlJbbMZ [[(hidden) LG4lGQCJX]] [[(hidden) yYswSgc_q]]
-
(hidden) PxIjsspRb
-
(hidden) BBFlQLQWj
-
(hidden) l8kAZ3dKt
-
{{[[TODO]]}} (hidden) n5tGpmKyc [[(hidden) f6mfe2JRx]] [[(hidden) uPYKVYu7L]] [[(hidden) VfDMEJVlc]] #read
-
(hidden) Tgyetrrx5
-
(hidden) B-WRrbbXL
-
(hidden) m2ueC_8iq
-
(hidden) pWHlXKVKj [[(hidden) ScgBa5etV]]
-
(hidden) 6vKcO04AP
-
(hidden) q_cEXsoOm
-
(hidden) oter2DSd3
-
(hidden) 5tuUTU4O9 [[(hidden) Z1h4_xJMy]] [[(hidden) EjFN4e5Fo]] [[(hidden) nh_fXgniK]] [[(hidden) icIkH5UuK]] [[bs]]
-
(hidden) nW77R_arR
-
(hidden) 8TBiP0uyq
-
(hidden) pCIxG4VdL
-
(hidden) ViUEa6zFD [[(hidden) fDIH_LQD5]]
-
(hidden) gJfJOC-wn
-
(hidden) s8KSJd7jF
-
(hidden) Q8l_FHsyS
-
(hidden) DgQct00RO [[(hidden) RRi4g9_yt]] [[(hidden) dm3CNOZS4]] [[(hidden) DINk-dQac]]
-
(hidden) Jeq4zXDHJ
-
(hidden) AXeB8McUm
-
(hidden) Km5CocJg7
-
#public
-
[[task queues]]
-
{{[[TODO]]}} #read "write your own task queue"
-
https://twitter.com/swyx/status/1569388097095303168
-
https://danpalmer.me/2022-09-10-write-your-own-task-queue/
-
{{[[DONE]]}} #TIL #exploration
-
[[js]] [[js promises]] [[event loop]] [[task queues]]
-
https://twitter.com/erikras/status/1569390163804971010?t=dsqwHmeLikzmIiXU6vkFrw&s=19
-
```javascript const timer = new Timer() timer .call(() => console.log("begin")) .call(() => console.log("should wait 2")) .waitFor(2) .call(() => console.log("should wait 3")) .waitFor(1) .waitFor(1) .waitFor(1) .call(() => console.log("done")) timer .waitFor(1) .call(() => console.log("kek")) ```
-
went thru w/ a ton of experimentation
-
it's so cool actually! so many different possibilities lol, v interesting & u learn a lot
-
e.g. a `lock` w/ [[js promises]] & `setTimeout`, & the effects it has by placing it in different places of the impl, & it's flaws
-
and there's 1 impl that i reached that i think is the optimal (spoilers!)
-
`queueMicrotask`
-
```javascript const timer = new Timer() timer .call(() => console.log("begin")) .call(() => console.log("should wait 2")) .waitFor(2) .call(() => console.log("should wait 3")) .waitFor(1) .waitFor(1) .waitFor(1) .call(() => console.log("done")) timer .waitFor(1) .call(() => console.log("kek")) function Timer() { const Kind = { CB: 0, DELAY: 1, } const queue = [] let first = true // detached from sync loop function initDetachedProcessing() { // // len === 1, because will only happen once - // // when the queue is pushed into initially. // // this will create a micro task, that will only happen // // after more items have been added to the queue // // see: // // - https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide#batching_operations // // instead of len === 1, just use `first` one-time toggle - // intentions clearer & simpler to understand if (first) { first = false // queue microtask, in order to collect all items into the queue // (sync Task processing), and only then to perform the processing (microtask) // // see: // - https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide#tasks_vs_microtasks // > The event loop driving your code handles these tasks one after // > another, in the order in which they were enqueued. The oldest // > runnable task in the task queue will be executed during a single // > iteration of the event loop. After that, microtasks will be // > executed until the microtask queue is empty, and then the // > browser may choose to update rendering. Then the browser moves // > on to the next iteration of event loop. queueMicrotask(() => { processNextQueueItem() }) } } function processNextQueueItem() { if (!queue.length) return const [kind, item] = queue.shift() if (kind === Kind.CB) { item() // cb processNextQueueItem() } else if (kind === Kind.DELAY) { const ms = item * 1000 // s setTimeout(() => { processNextQueueItem() }, ms) } else { throw new Error("never") } } return { call(cb) { queue.push([Kind.CB, cb]) initDetachedProcessing() return this }, waitFor(s) { queue.push([Kind.DELAY, s]) initDetachedProcessing() return this }, } } ```
-
why you need to call `initDetachedProcessing`
-
it's interesting on how you arrive at creating such an fn as well.
-
there was a lot of iteration until you finally see what's optimal. [[you'll know it when it's right / this is the way]]
-
sidenote:: not the first time that i've thought about the following: [[how to teach]] -- a lot of tutorials go from 0 to 100, __without showing the intermediate steps of how you arrive at the conclusion__.
-
related:: [[(hidden) SyV6Uv0YI]]
-
reason: it's the same problem -- you [[inlined/compiled (concept)]] everything into the final result & lost the intermediate steps, whom are the most crucial for learning & deeply understanding
-
it's the same as if you have some derived formula in [[math]], and you just give it to a person, w/o showing __how__ it was derived, & them having to [[memorize]] it, instead of understanding how it works, what were the steps to achieve it, how too manipulate something in between if needed ([[(hidden) 4npmJjA1a]]), etc etc etc
-
-
-
-
-
-
-
-
-
-
-
[[js promises]] [[spec]]
-
#search "javascript promises spec"
-
{{[[DONE]]}} "Understanding the Promises/A+ specification"
-
https://stackoverflow.com/a/36192729/9285308
-
[[monads]] [[haskell]]
-
{{[[DONE]]}} "Would there be any benefit to writing synchronous code using the syntax of promises"
-
https://stackoverflow.com/a/28947696/9285308
-
-
-
{{[[TODO]]}} #read "Promises/A+ -- An open standard for sound, interoperable JavaScript promises—by implementers, for implementers."
-
-
"Promise" [[(hidden) iwluHr09Z]]
-
{{[[DONE]]}} #read "microtask guide"
-
https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide
-
[[event loop behavior]]
-
> The event loop driving your code handles these tasks one after another, in the order in which they were enqueued. The oldest runnable task in the task queue will be executed during a single iteration of the event loop. After that, microtasks will be executed until the microtask queue is empty, and then the browser may choose to update rendering. Then the browser moves on to the next iteration of event loop.
-
-
{{[[TODO]]}} #read [[(hidden) f6mfe2JRx]] "In depth: Microtasks and the JavaScript runtime environment"
-
-
-
-
-
[[js]] [[event loop]]
-
#search "requestAnimationFrame and javascript event loop"
-
"requestAnimationFrame"
-
https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
-
https://github.com/behnammodi/polyfill/blob/master/window.polyfill.js
-
subject:: `requestIdleCallback`
-
https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
-
polyfill
-
https://github.com/behnammodi/polyfill/blob/master/window.polyfill.js
-
"background tasks api"
-
{{[[TODO]]}} #read [[high signal]] [[(hidden) oKl824Qrm]] [[spec]]
-
https://w3c.github.io/requestidlecallback/#[[(hidden) G97ohL3l8]]the-requestidlecallback-method
-

-
#search "javascript event loop and native functions when called"
-
https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop
-
https://html.spec.whatwg.org/multipage/webappapis.html#event-loops
-
{{[[TODO]]}} #read https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/#what-is-the-event-loop
-
"Phases Overview"
-
> **timers**: this phase executes callbacks scheduled by setTimeout() and setInterval(). **pending callbacks**: executes I/O callbacks deferred to the next loop iteration. **idle, prepare**: only used internally. **poll**: retrieve new I/O events; execute I/O related callbacks (almost all with the exception of close callbacks, the ones scheduled by timers, and setImmediate()); node will block here when appropriate. **check**: setImmediate() callbacks are invoked here. **close callbacks**: some close callbacks, e.g. socket.on('close', ...).
-
-
-
-
-
-
-
-
-
-
#search #github "requestIdleCallback org:facebook"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
(hidden) RuK6-BjUF
-
(hidden) ea3ZX6YKh
-
(hidden) Zk9dYOmxL
-
(hidden) kES6Uz6I_
-
(hidden) 6dkBM-j02
-
(hidden) E1E80KG2E [[(hidden) zJw7j5jxr]]
-
(hidden) yH1z3QXBz
-
(hidden) cWgd-Jn-c
-
(hidden) 8mdewd_AQ
-
(hidden) PRlHs-QMi
-
(hidden) kH2mJ0bhJ
-
(hidden) aHlA_8jfi
-
(hidden) OSrWw5zaS
-
(hidden) eICL00gs5
-
(hidden) uxIZJB5Ez