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: promise
Struggle with chaining of promises in react application
JavaScript, React – sending multiple simultaneous ajax calls struggling with promises. Basically I want to chain the calls, if one server call completes then only do next call, and collect the successful response of calls from endpoint /pqr made inside makeServerCalls. Error: expected to return a value in arrow function. What am I doing wrong here? Is this a right
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
Await equivalent of ‘Promise.resolve().then()’?
I’m familiar with Promises, but have inherited some rather unusual code that, rather than making a new Promise(), uses the following: From my research, this is a weird version of setImmediate – ie, run the following function on the next tick. What would be the await version of this? Answer There may be two different reasons for the Promise.resolve(). You
Correct Try…Catch Syntax Using Async/Await
I like the flatness of the new Async/Await feature available in Typescript, etc. However, I’m not sure I like the fact that I have to declare the variable I’m awaiting on the outside of a try…catch block in order to use it later. Like so: Please correct me if I’m wrong, but it seems to be best practice not to
Why does TypeScript use “Like” types?
Why does TypeScript have a type and then a “like type”? An example of this is Promise<T> and PromiseLike<T>. What are the differences between these two types? When should I use them? In this case why not just have one Promise type? Answer If you look at the definition files (let’s take lib.es6.d.ts) then it’s pretty straight forward. For example
Why would you try-catch around a promise? Does that catch the promise’s error?
I stumbled upon some code that looked off to me: If some somePromise() fails, would this not get caught, and the app would crash? Does this try-catch even do anything? Should be this, correct?: Answer TL;DR – If a function that returns a promise throws an exception before returning the promise then that exception would have to be caught in
fetch response.text() returns pending promise
I test the fetch API with jsonplaceholder URL, but my function returns “Promise State: Pending”, and I don’t understand why : I think the problem is because of asynchronous/synchronous methods? Answer I think the problem become asynchrone/synchrone method ? Yes. You’ve (mostly) correctly consumed the original fetch() promise, but text() also returns a promise. So: At #1 above, we respond
Rethrowing error in promise catch
I found the following code in a tutorial: I’m a bit confused: does the catch call accomplish anything? It seems to me that it doesn’t have any effect, since it simply throws the same error that was caught. I base this on how a regular try/catch works. Answer There is no point to a naked catch and throw as you
JavaScript array .reduce with async/await
Seem to be having some issues incorporating async/await with .reduce(), like so: The data object is logged before the this.store completes… I know you can utilise Promise.all with async loops, but does that apply to .reduce()? Answer The problem is that your accumulator values are promises – they’re return values of async functions. To get sequential evaluation (and all but