Add support for JSObjectReference/IJSObjectReference

[egil]

The new way of loading JavaScript modules into a Blazor app and then receiving a JSObjectReference after the call should be eksplicit supported by the mock js runtime in bUnit, such that the resulting JSObjectReference just works.

More info here: https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-5-release-candidate-1/#blazor-javascript-isolation-and-object-references

Related: dotnet/aspnetcore#26981

[KristofferStrube]

Hey Egil,
As I see it, the MockJSObjectReference that would implement IJSObjectReference would look very similar to the MockJSRuntime which uses the MockJSRuntimeInvokeHandler, but it seems like a lot of duplicated code if we were to make a MockJSObjectReferenceInvokeHandler as well so maybe the MockJSObjectReference should just get parsed the same InvokeHandler, but then the name should maybe change to something more general like MockJSInvokeHandler. This would of cause require some refactoring since we have the JSRuntime specific method ToJSRuntime() in that class as well. What do you think or have you already thought about the design?

A problem that I'm facing (that is not directly related) is that I can't reference IJSObjectReference in the MockJSRuntimeInvokeHandler when I've tried sketching a solution. But I can inherit from JSObjectReference. I guess that it might not have been added to netstandard 2.1 yet, but I don't know. I suppose some of the people from the dotnet foundation who are working on Blazor would argue that you indeed should extend JSObjectReference not IJSObjectReference, but that leaves us with a constructor that can't take e.g. a MockJSInvokeHandler. Any thoughts on this?

[egil]

Hey Kristoffer

My initial design thoughts on this are as follows (assuming users have called var mockJs = Services.AddMockJSRuntime()):

1. Two new "setup" methods should be added to MockJSRuntimeInvokeHandler:

   • SetupModule(string moduleUrl, JSRuntimeMockMode? mode = null)
   • Setup<IJSObjectReference>(string identifier, string moduleUrl, JSRuntimeMockMode? mode = null)

2. Both new setup methods does the same thing:

   • return a MockJSObjectReferenceInvokeHandler
   • add a planned invocation to the MockJSRuntimeInvokeHandler planned invocations list, that will return the MockJSObjectReferenceInvokeHandler's mock IJSRuntime to the caller.
   • set the JSRuntimeMockMode on the MockJSObjectReferenceInvokeHandler if one is provided, otherwise use the one from the MockJSRuntimeInvokeHandler. This allows users to have different modes for different modules, something that could be useful for 3rd party libraries that want to provide a fake JSInterop experience.

3. These new setup methods are only available when targeting .NET 5.

4. MockJSObjectReferenceInvokeHandler could inherits from MockJSRuntimeInvokeHandler or a common base class, with the addition of a property called Module, that is set to the name of the module provided in the setup methods.

5. MockJSObjectReferenceInvokeHandler should add any invocations it handles to the "root" mockJs's Invocations list, the MockJSRuntimeInvokeHandler that created it, as well as its own, such that users can query both invocations list to verify invocations.

6. There should be a special JSRuntimePlannedInvocationBase type for planned invocations for modules, that also contains the Module property for the invocation, to avoid conflicts with modules that have the same functions.

What do you think?

Btw. in addition to this, I plan to change how bUnit's JSInterop/mock JSRuntime is surfaced to the user. I want to add a property public MockJSRuntimeInvokeHandler JSInterop { get; } to the TestContext type. This will also mean that JSInterop will be registered in the services collection by default in strict mode. This is because .NET5 will bring 1st party components with Blazor that uses JSInterop, and bUnit should support those out of the box. But that discussion is for a different issue (#237) and doesn't really influence this.

[KristofferStrube]

Hey again,

Nice to see that you've already had a lot of ideas. 👍

1. Looks good. Like the idea of using the JSRuntimeMockMode again. Apropos, should setting the MockJSRuntimeInvokeHandler's JSRuntimeMockMode to Loose make all InvokeAsync<IJSObjectReference>("import", someUrl) calls return a MockJSObjectReference by default or should you have to call SetupModule explicitly to use modules in a test? Some might not be interested in having to call SetupModule for all their modules if they have a lot.

2. Sounds good.

3. Makes sense.

4. It should probably not inherit from MockJSRuntimeInvokeHandler since that would mean that a module could load another module, which I don't think is possible. A common base class like MockJSInvokeHandler sounds like the way to go.

5. You won't be able to have multiple layers of MockJSRuntimeInvokeHandlers so just two Invocation lists or is "root" something else than a MockJSRuntimeInvokeHandler? But sounds like a good idea to be able to check it in both places.

6. Good idea. Keeping the modules separate matches the actual behaviour well.

In total it seems like a good plan.

If there were to be added an on-by-default result for an invoked import then that might be the easiest to add by simply checking in the MockJSRuntime.TryHandlePlannedInvocation method: If JSRuntimeMockMode is loose, the TValue equals IJSObjectReference, and the identifier equals "import" and then returning a new MockJSObjectReference with a new loose MockJSObjectReferenceInvokeHandler parsed. This would though open up the question of what the Module property should be set to. "default" or does it even matter when it is loose anyway? There probably exists a more elegant solution than this.

Sounds interesting to add JSRuntime to the TestContext. Will that mean that the ToJSRuntime() method will be removed?

[egil]

Thanks for the input Kristoffer.

Regarding 1: As part of the "always on" issue #237, planned invocations for InvokeAsync<IJSObjectReference>("import", someUrl) will be added to handle that invocation type out of the box.

Regarding 4: Agreed, some base type/interface is probably needed. But are we sure that IJSObjectReference modules are not allowed to load other IJSObjectReference modules?

Regarding 5: I see two layers, the "root" jsruntime mock that can return zero or more child IJSObjectReference mock jsruntimes. The idea of having the childs add their recorded invocations to the root invocationslist, is the same as with planned invocations, that also share their received invocations with the root invocation list.

If there were to be added an on-by-default result for an invoked import then that might be the easiest to add by simply checking in the MockJSRuntime.TryHandlePlannedInvocation method: If JSRuntimeMockMode is loose, the TValue equals IJSObjectReference, and the identifier equals "import" and then returning a new MockJSObjectReference with a new loose MockJSObjectReferenceInvokeHandler parsed. This would though open up the question of what the Module property should be set to. "default" or does it even matter when it is loose anyway? There probably exists a more elegant solution than this.

With the always on, we will just register planned handlers for that case. I do not think an special override is needed.

Sounds interesting to add JSRuntime to the TestContext. Will that mean that the ToJSRuntime() method will be removed?

Probably some tweaks to the public API, but lets keep those discussions in that issue.

[KristofferStrube]

Hey again,
I've made a project that shows how modules can be imported in Blazor: github.com/KristofferStrube/MinimalIJSObjectReferenceExample
You can't call top-level functions like import from a module, but you can let a javascript function that is exported call import and return that. That's pretty much the take away from the project.

[egil]

@KristofferStrube if you want to take a crack at this issue, feel free to go ahead. Do check out the contributor guidelines first thought.

[KristofferStrube]

I will try putting something together. I haven't done any pull requests before, so might need some help through the process, but I'm up for the challenge.
I'm still facing the problem that I can't reference IJSObjectReference, but that might be fixed when we set it so that it can only be used when using .NET5.0.

[egil]

That's fair. This is a pretty complex one. If you want to get your feet wet first then there are also other issues with the good first issue label that you can look at.

[egil]

Hey @KristofferStrube, you can check out the PR #247 to see what I am planned to change in bUnit s JSInterop.