Add a generic JSPromise implementation#62
Add a generic JSPromise implementation#62
JSPromise implementation#62Conversation
| */ | ||
| public func then(success: @escaping (Success) -> ()) { | ||
| let closure = JSClosure { | ||
| success(Success.construct(from: $0[0])!) |
There was a problem hiding this comment.
If fail to construct, we should throw error or report it with a detailed message. Force unwrapping fatal messages is not quite useful to see the error reason for JavaScriptKit users.
| It's impossible to unify success and failure types from both callbacks in a single returned promise | ||
| without type erasure. You should chain `then` and `catch` in those cases to avoid type erasure. | ||
| */ | ||
| public final class JSPromise<Success, Failure>: JSValueConvertible, JSValueConstructible |
There was a problem hiding this comment.
Please note that this class must have the same lifetime with the actual Promise object in JS environment because callback handlers will be deallocated when JSPromise.deinit.
If the actual Promise object in JS environment lives longer than this JSPromise, it may call deallocated JSClosure.
|
I just had an idea: what if the JSPromise class exposed an |
|
That will require a dependency on OpenCombine unfortunately, and it would be best to keep JavaScriptKit the lowest level library in the stack if we ever hope to achieve #61. What about a separate OpenCombineDOM library that allows any |
This provides three overloads each for
thenandcatch, and I'm not sure if that's good for the type-checker performance and usability. I was thinking of naming the promise-returning callback versionflatMap, but ultimately decided against it.thenoverload with two callbacks is not available, because it's impossible to unify success and failure types from both callbacks in a single returned promise without type erasure. I think users should just chainthenandcatchin those cases so that type erasure is avoided.