Skip to content
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

IJSInProcessObjectReference can't be imported with SetupModule #484

Open
KristofferStrube opened this issue Aug 16, 2021 · 3 comments
Open
Labels
documentation Improvements or additions to documentation
Projects
Milestone

Comments

@KristofferStrube
Copy link
Contributor

Is the feature request related to a problem? Please elaborate.

The SetupModule extension for setting up an imported JS module only supports IJSObjectReference but you can also import modules of types IJSInProcessObjectReference and IJSUnmarshalledObjectReference.

The suggested solution

IJSInProcessObjectReference and IJSUnmarshalledObjectReference are derived from IJSObjectReference so I think it should be possible to support this with minor changes.

Describe any alternative solutions

If we can not use that they are derived interfaces to IJSObjectReference then it could just be implemented like the module setup feature for IJSObjectReference.

Additional context

I don't think a lot of people use this way of importing modules so might not be a priority.

Currently, I just do the following instead:

TestContext.JSInterop.Setup<IJSInProcessObjectReference>("import", "./_content/MyPath/MyFile.js");

Might also be related to the last bit in this old issue #233 where we quickly mentioned IJSInProcessObjectReference

@egil
Copy link
Member

egil commented Aug 16, 2021

Hi @KristofferStrube

The problem is that you cannot overload based on generic types, so it would mean making SetupModule generic, e.g.: SetupModule<TObjectReference>(...) where TObjectReference : IJSObjectReference to keep using the same name (SetupModule). But that will require users to always specify the IJSObjectReference or a derived type, even in the most common case, e.g. SetupModule<IJSObjectReference>(...).

As you say, its probably not too many that needs this, so I would like to keep things simple for the majority. If your workaround works, then I think I will keep it as is, and instead document this particular use case.

What do you think?

@KristofferStrube
Copy link
Contributor Author

Hey @egil

I think you are right. Let's just keep it as it is and maybe document it in this section:
https://bunit.dev/docs/test-doubles/emulating-ijsruntime.html#support-for-ijsinprocessobjectreference-and-ijsunmarshalledobjectreference

@egil
Copy link
Member

egil commented Aug 16, 2021

Ill add it to the to-do list. If you want, a docs PR is very welcome ;)

@egil egil added the documentation Improvements or additions to documentation label Aug 16, 2021
@egil egil added this to To do in v2 May 21, 2022
@egil egil added this to the 2.0.0 milestone May 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
No open projects
v2
  
To do
Development

No branches or pull requests

2 participants