Blazor: JSObjectReference ctor should take a IJSRuntime as input

[egil]

Hey Blazor team,

I have started to look at making the fake/mock IJSRuntime in bUnit work seamlessly the new JSObjectReference in .net5.

If devs have a component with code like this in it (from blog post),

var module = await jsRuntime.InvokeAsync<JSObjectReference>("import", "./_content/MyComponents/exampleJsInterop.js");
return await module.InvokeAsync<string>("showPrompt", message);

... I will be hard pressed to return a JSObjectReference to user through bUnits mock IJSRuntime, because JSObjectReference ctor takes a JSRuntime as input, and not IJSRuntime, and thus I cannot pass it bUnit's IJSRuntime.

In addition to that, the public methods on JSObjectReference would ideally also be virtual, making it possible to override those in a derived class, BunitJSObjectReference, making it possible to customize the experience even more.

A better solution would be to not allow users to specify JSObjectReference (making the type internal) in calls to jsRuntime.InvokeAsync<JSObjectReference>(...), and instead make them use IJSObjectReference.

I know we are already a RC2, but I hope there are still time to sneak in a little tweak.

Best, Egil

cc. @captainsafia / @SteveSandersonMS / @danroth27

Related: bUnit-dev/bUnit#233

[danroth27]

It's IJSObjectReference in RC2. Does that help?

[SteveSandersonMS]

BTW we made that change specifically for testability.

[egil]

@danroth27 IJSObjectReference is indeed in there.

But I think the challenge is that JSObjectReference is also public, and it is thus possible for users to request that type in a jsRuntime.InvokeAsync<JSObjectReference>(...) call, like you show in the RC1 blog post.

bUnits IJSRuntime mock cannot return a JSObjectReference to the user, as far as I can see, unless the ctor changes, and that is the concern I am trying to address.

Either the JSObjectReference ctor should take IJSRuntime as input, making it possible for bUnit to new it up and still influence any calls it received to it's Invoke methods, or it should be internal, such that users have to request the IJSObjectReference type.

Please correct me if I'm wrong.

[SteveSandersonMS]

Even though JSObjectReference is public, developers must use IJSObjectReference in order to get an object reference. That is:

jsRuntime.InvokeAsync<IJSObjectReference>(...); // Works
jsRuntime.InvokeAsync<JSObjectReference>(...); // Will not work (doesn't create an object reference)

The reason for this is in the implementation at https://github.com/dotnet/aspnetcore/blob/master/src/Shared/JSInterop/JSCallResultTypeHelper.cs. As you can see in the code there, we are looking for the interface type, not any other type (not even ones that implement the interface). Additionally, all the docs will only refer to IJSObjectReference, so developers don't have any reason to consider trying the concrete type (which won't work even if they do).

So I believe things will work fine for bUnit. And again, we made these specific choices to ensure testability :)

In case you're wondering why JSObjectReference has to be public, it's because of how the framework is layered, and the fact that we want it to be possible to implement Blazor renderers for alternate platforms (such as Mobile Blazor Bindings). Regular application developers don't need to use JSObjectReference directly, but platform authors do. That's why JSObjectReference is in a namespace with .Implementation at the end.

[egil]

Thanks for clearing this up @SteveSandersonMS. Appreciate that you considered testability. My concern was based on Dans blog post (I guess from rc1), where he does use JSObjectReference.

bUnits JSInterop can then reasonable disallow the use of JSObjectReference as well.

Speaking of design choices, why did you decide to have the ctor of JSObjectReference take JSRuntime and not IJSRuntime? Would that not limit other Blazor renderers to only use the "web"-based JSInterop?

[SteveSandersonMS]

JSRuntime is the base class for all JS runtime implementations. All implementors need to derive from that. Additionally, JS interop itself is a "web"-specific concept so there's no loss of generality. For example on Mobile Blazor Bindings, JS interop only exists for components that are being rendered into a webview.

[egil]

OK, that makes sense in that case. With Blazor now shipping with components (e.g. Virtualize) that rely JSInterop I am planning to revamp bUnits mock of IJSRuntime and integrate it more direct with its TestContext, so its always on by default, with fake responses built-in for the standard bits in Blazor.

After a quick view of JSRuntime it does seem that most in there is not relevant in bUnits use case though. Do you agree?