Implementing `Promise.resolve`/`Promise.reject` and `then(good, err)`

[brettz9]

Hi,

In your library, it is nice to see there is already a solution for the problem with promises for IndexedDB!

I would just suggest though that there are a few good reasons to support a couple of the features you rejected (no pun intended).

then(good, err) may be an anti-pattern, but I believe part of the appeal of your library is that it pretty much can work out of the box with existing promises however they are being used, and with a familiar syntax. The fewer the differences, the better, imo.

Implementing Promise.resolve and Promise.reject which simply adds a 0 second timeout (or animation frame perhaps) would seem to me to be in the spirit of these "immediately" returning. Besides allowing for existing Promises code to avoid the need for changes, it is a convenient practical wrapper of use in and of itself.

Thanks!

[brettz9]

I haven't taken a close look yet, but wanted to mention immediate as an interesting sounding option for simulating a microtask...

[zbraniecki]

Slightly shameful plug - I tried to use this library for a sync drop-in replacement of Promise and it failed. I created my own SyncPromise implementation, much less complete, intended to be a drop-in replacement - https://github.com/zbraniecki/syncpromise .

Hope that helps!

[brettz9]

@zbraniecki, what failed for you exactly?

[zbraniecki]

@brettz9 - all Promise.resolve, and Promise.reject and the fact that this library throws on then when used on synchronously resolved promise, and that Promise.all requires there to be at least one promise in the list.

I needed something as close to "drop-in" replacement as possible and that's what I wrote. I guess my goals are just different :)

[brettz9]

Gotcha--I haven't looked at your code, but as an FYI, I also have worked around these issues within my fork at https://github.com/brettz9/sync-promise/tree/full-sync-missing-promise-features , but it also violates the principle of paldepind's library in sometimes working sync and sometimes not. However, I felt I had to do that because even with using immediate, the simulated microtask duration was not short enough for multiple promises to be chained within a transaction.

I wonder whether the transaction time is extended as long as a new operation takes place within a certain time window? And if so, I wonder whether there are any other options to simulating microtasks...

[zbraniecki]

I needed a fully Sync Promise. Not a sync+async combo :)

[brettz9]

Actually, I think I misremembered--I believe mine is fully sync too :)

[zbraniecki]

Cool! Did you also remove the limitation on not allowing to chain synchronous thens?

[brettz9]

Yes--including allowing catching synchronously thrown errors...

[zbraniecki]

great! then you can remove the limitation from your README.md ;)