So here’s an oxymoron: I want to create an asynchronous blocking queue in javascript/typescript (if you can implement it without typescript, that’s fine). Basically I want to implement something like Java’s BlockingQueue expect instead of it actually being blocking, it would be async and I can await dequeues. Here’s the interface I want to implement: And I’d use it like
Tag: asynchronous
Async function without await in JavaScript
I have two functions, a and b, that are asynchronous, the former without await and the latter with await. They both log something to the console and return undefined. After calling either of the function, I log another message and look if the message is written before or after executing the body of the function. If you launch test without
Using await within a Promise
There seems something inherently wrong with having to define a Promise’s callback as asynchronous: This is apparently an antipattern and there are coding problems which can arise from it. I understand that it becomes easier to fail to catch errors here, even when placing await statements inside try/catch blocks. My first question is, what’s the best way to code something
When to mark function as async
Basically, function must be prefixed with async keyword if await used inside it. But if some function just returns Promise and doesn’t awaiting for anything, should I mark the function as async? Seems like both correct or not? Answer if some function just returns Promise and doesn’t awaiting for anything, should I mark the function as async? I would say
Rendering a React component using ES generator
I have a very basic implementation of a sleep function which resolves a promise after x miliseconds: I then need to render a React component in an ES6 Stateful Class Component after the sleep, but this sadly throws the error: Objects are not valid as a React child. Is there something wrong with this generator implementation? I can not use
javascript/browser: when does event dispatching exactly happen?
This SO question & answers and DOM level3 docs states that manual events are dispatched synchronously in browsers. My question, however, relates to user-related events (real clicks), not manually triggered ones. I created a small jsfiddle demo with a button + onclick handler, the handler does some synchronous work for 2 seconds (blocking sync wait, long enough for my eye
Is it an anti-pattern to use async/await inside of a new Promise() constructor?
I’m using the async.eachLimit function to control the maximum number of operations at a time. As you can see, I can’t declare the myFunction function as async because I don’t have access to the value inside the second callback of the eachLimit function. Answer You’re effectively using promises inside the promise constructor executor function, so this the Promise constructor anti-pattern.
Catching ‘Origin is not allowed by Access-Control-Allow-Origin’ error
So, i want to detect/catch Cross-Domain access blocked error. After some thought i found out that it src loading is async & thus the catch block wont work. Is there any way to detect the error so i can handle it efficiently? Answer As @TamasHegedus commented, the image can still be loaded with the CORS error, but it doesn’t allow
Why does .json() return a promise?
I’ve been messing around with the fetch() api recently, and noticed something which was a bit quirky. post.data returns a Promise object. http://jsbin.com/wofulo/2/edit?js,output However if it is written as: post here is a standard Object which you can access the title attribute. http://jsbin.com/wofulo/edit?js,output So my question is: why does response.json return a promise in an object literal, but return the
Why couldn’t popular JavaScript runtimes handle synchronous-looking asynchronous script?
As cowboy says down in the comments here, we all want to “write [non-blocking JavaScript] asynchronous code in a style similar to this: ” So people have come up solutions to this problem like callback libraries (eg async) promises event patterns streamline domains and generators. But none of these lead to code as simple and easy to understand as the