Simplify JSPromise API

[kateinoigakukun]

Changes

Remove generic type parameters from JSPromise

These type parameters are type-safe only when it's produced by JSPromise.then and in other cases, it's always not type-safe. So I removed those type parameters.

Remove then and catch overloads

Those overloads made it difficult to solve compile errors 😢

Add Promise.resolve and Promise.reject

[github-actions]

Time Change: +590ms (6%) 🔍

Total Time: 8,978.5ms

Test name	Duration	Change
Serialization/Swift Int to JavaScript	2,882.25ms	+191.5ms (6%)	🔍
Serialization/Swift String to JavaScript	2,945.25ms	+208.5ms (7%)	🔍
Object heap/Increment and decrement RC	2,818ms	+190.25ms (6%)	🔍

ℹ️ View Unchanged

Test name	Duration	Change
Serialization/Write JavaScript number directly	167ms	+3.5ms (2%)
Serialization/Write JavaScript string directly	166ms	-3.75ms (2%)

_{performance-action}

[MaxDesiatov]

While it's true that arbitrary user code returning a promise may not be type-safe, we know that most if not all promise-returning Web APIs can only fail with JSError and only resolve to a single type. If a user doesn't know what type to expect they can specify their expected type as JSPromise<JSValue, JSValue>.

While it could make sense to shift the reponsibility for dynamic casts to users, I'm not sure if it's an improvement on balance from the ergonomics perspective. This change would break a lot of things in OpenCombineJS and make Publisher conformance on promise-returning APIs harder to implement. For example, how would DOMKit promise-returning APIs like fetch look in DOMKit if this change is merged? I'm also interested to look what impact this has on async/await APIs in the end?

I don't have a strong opinion here to reject the change outright though. I'm interested to hear opinions on this from other people in the meantime.

[kateinoigakukun]

My explanation was too short, sorry.

My opinion is that JSPromise should be as primitive as possible. The current JSPromise has two responsibilities as a bridge to the Promise API and as a continuation monad.

Promise API: The responsibility for bridging Promise API is to provide an ability to register asynchronous tasks in the JavaScript event loop.

Continuation monad: The responsibility for continuation monad is to provide map and flatMap.

There are some problems when these two responsibilities are implemented on top of the Promise API.

1. For example, users usually want to use Promise as a continuation monad, but every time they chain in then (map), they need to interact with JavaScript world.
2. And also, the constraint of single type resolution is not something that Promise has, but is a convention of the individual JavaScript APIs. Therefore, JSPromise is more strongly constrained than JavaScript's Promise.

The main purpose of my change is to make JSPromise's responsibility only to bridge the Promise API, and to delegate the responsibility as a type-safe continuation monad to another type like Combine.Future.

In this way, the user doesn't need to interact with JavaScript to map. This separation of the two responsibilities results in removing generic type parameters.

For example, how would DOMKit promise-returning APIs like fetch look in DOMKit if this change is merged?

Libraries that provide type-safe APIs, such as DOMKit, should not return JSPromise directly to the user, but convert it to a type that provides type-safe continuation monad like Combine.Future.

I'm also interested to look what impact this has on async/await APIs in the end?

This doesn't directly affect the async/await APIs, it's just a point I noticed while implementing the Concurrency feature.

[MaxDesiatov]

Thanks for the explanation. This makes sense 👍

[j-f1]

Could these be JSValueConvertible so users can do something like resolve(.success("Hello, world!"))?

Suggested change

	public convenience init(resolver: @escaping (@escaping (Result<JSValue, JSValue>) -> ()) -> ()) {
	public convenience init(resolver: @escaping (@escaping (Result< JSValueConvertible, JSValueConvertible >) -> ()) -> ()) {

[kateinoigakukun]

ConvertibleToJSValue is not conforming to Error, so Result can't have Failure as ConvertibleToJSValue 😢

[j-f1]

Nice!

[kateinoigakukun]

@j-f1 Could you take a look again?

[j-f1]

Sorry for the delay!