-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Add reflection-based support for wrapping JS interop calls as C# delegates #61673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
5cdd2a7
to
50fb6ee
Compare
@javiercn Please discuss with @pavelsavara and @maraf what should be done with this feature. We can:
Personally, I am for 2 or 3 for the reasons we already went through. However, I want to go ahead with the consensus in the wider team. |
|
Can you clarify what you mean about this impacting the public API? I'm not sue what you mean about the comment on trimmability/NAOT. What's the specific issue with the pattern (note we do the same thing all over the place). If the solution to address this were to use a source generator instead,
That's fine, sometimes we can change the approach our customers take, but others we can't.
As for demand, this is covered as part of #31151. There are common patterns that make this very useful, like being able to import a JSModule and taking a reference to one of its exported functions for use later on, and being able to pass that around as a BCL type as opposed to taking a dependency on JS interop types. |
This is a work-in-progress implementation of
AsAsyncFunction
extension method forIJSObjectReference
. The method creates an asynchronousFunc<...>
delegate that serves as a C#-native typed wrapper that invokes the referenced JS function via interop.Sync variant and the full PR description can be added after we finalize implementation design.
This is the reflection-based alternative to #61721.