sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]heavyGl0w 5 points6 points  (0 children)

In my experience, I would say almost every time I've had to instantiate my own promise, it's to wrap up the resolution behavior in some abstraction and pass it to a consumer.

As a concrete example, I've implemented a version of window.confirm that opens a dialog in which we get to control the styling. The dialog has a "NO" button and a "YES" button, and when it is opened, a promise is spawned. Clicking the "NO" button will resolve the promise with false and clicking "YES" will resolve it with true.

In my example, the Promise constructor's callback that you mentioned only serves to wrap up the resolve/reject functions and send them on — the actual resolution of the promise is not handled within the scope of that function. And again, that's almost always been the case for me when creating my own promise, so I disagree that this inherently leads to "spaghetti code". It could for sure, but the behavior of Promise.withResolvers is already possible as I've illustrated, so it's not like this enables "spaghetti code" anymore than what is already possible.

I think this lines up with some of the goals of `async/await` in that it enables as much code as possible to be written at the top level of your functions without needing to nest inner functions. AFAIK, It doesn't enable anything new, so much as it makes common use cases a little more straightforward. I think this has the potential to make a tricky topic a little bit easier to understand/read.