JSInterop support for invoking constructors, properties, and supplying callbacks

[javiercn]

• Support invoking constructor functions either detecting them automatically or with a new method.
• Support invoking callback objects (maybe this works already), either with a new JS/Dotnet callback.
• Support accessing object properties directly (automatically or via a new method).

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

We had several reports of these things in this area and some of them block using basic JS functionality without having to write a wrapper.

[campersau]

For wasm only apps there is https://github.com/dotnet/runtime/tree/main/src/libraries/System.Private.Runtime.InteropServices.JavaScript if you aren't afraid of the Private part.

[javiercn]

We don't recommend using those directly, since they are wasm specific and I believe might change in the future

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[gerneio]

100% needed in order to develop JS interop w/o having to develop a custom JS wrapper module for nearly every JS library. As it stands, pretty much any moderately complex/large JS lib that you want to call via JS interop is not possible without a JS wrapper. IIRC, a big pitch of Blazor was the goal of writing C#, HTML, CSS w/o JS. But pretty much any JS lib requires us to write JS to make it work with C#.

So really hope these features don't keep get being pushed back after 2+ years.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[trungnt2910]

Raising my support for this issue. With the current IJSRuntime mechanism, even for simple properties like document.title, if eval is blocked, there's no way other than a wrapper function (a certain bug in .NET's implementation prevents the usage of valueOf for primitive types).

Something like giving IJSObjectReference functions like GetProperty[...]Async and SetProperty[...]Async similar to what JSObject already has would be highly desirable.