You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR refactored the old tsfn impl. The original impl has a few problems as follows:
Type definition It's hard to read whether the original JS function returned Promise<T> or T. This is originally designed for loader, since JS Loaders can be called both synchronously and asynchronously. This usage has been spread to most of JS functions and each signature should be defined explicitly.
In this new tsfn impl, the improvements are as follows:
Type definition Type should be explicitly defined, such as ThreadsafeFunction<(A, B), Either<A, Promise<T>>>.
Tuple type auto conversionThreadsafeFunction<(A, B), ...> would be converted to the two parameters for JS functions. In this example: it's (a: A, b: B) => ...
Auto FromNapiValue It's not necessary to convert JSFunction to ThreadsafeFunction on your own, just apply derive#[napi(object, object_to_js = false)] and replace JSFunction with ThreadsafeFunction<T, R>
Builtin sync and async call For threadsafe functions returning Promise<T>, it's up to your choice to either call with call_with_promise to resolve to it's original value with error being carefully converted to JS and call_with_sync with the original Promise<T> being returned. If Either<T, Promise<T>> is returned, you may also call_with_auto to extract the value T.
Escape hatch For old functions that haven't been migrated to the new implementation, method call is still provided for you to extract the value behind Promise<T> | T by calling method call, you may keep the threadsafe function's type signature as-is, such as ThreadsafeFunction<(A, B), T>. This is highly NOT recommended tho.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
h-a-n-a
changed the title
Summary
This PR refactored the old tsfn impl. The original impl has a few problems as follows:
Promise<T>orT. This is originally designed for loader, since JS Loaders can be called both synchronously and asynchronously. This usage has been spread to most of JS functions and each signature should be defined explicitly.In this new tsfn impl, the improvements are as follows:
ThreadsafeFunction<(A, B), Either<A, Promise<T>>>.ThreadsafeFunction<(A, B), ...>would be converted to the two parameters for JS functions. In this example: it's(a: A, b: B) => ...FromNapiValueIt's not necessary to convertJSFunctiontoThreadsafeFunctionon your own, just apply derive#[napi(object, object_to_js = false)]and replaceJSFunctionwithThreadsafeFunction<T, R>Promise<T>, it's up to your choice to either call withcall_with_promiseto resolve to it's original value with error being carefully converted to JS andcall_with_syncwith the originalPromise<T>being returned. IfEither<T, Promise<T>>is returned, you may alsocall_with_autoto extract the valueT.callis still provided for you to extract the value behindPromise<T> | Tby calling methodcall, you may keep the threadsafe function's type signature as-is, such asThreadsafeFunction<(A, B), T>. This is highly NOT recommended tho.NAPI Refs:
Require Documentation?