Blazor JSImport JSObject identity

[lskyum]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

This is a bit of a strange and niche issue.

When using JSImport/JSExport for WASM Blazor, the identity of returned JSObject's are synchronized between the .NET (WASM) engine and the JavaScript engine. Meaning the same .NET JSObject is returned for the same JavaScript object. (Unless it has already been disposed or garbage collected).

This is a really nice feature, because it allows you to synchronize various things between the two worlds.

But this doesn't seem to work when the JavaScript object is a constructor, for example:

export function getDivElement() {
    return HTMLDivElement;
}

This means that code like:

element.constructor == HTMLDivElement

Doesn't work inside the .NET engine, because the JSObject from HTMLDivElement doesn't maintain it's instance correctly.

It's a bit hard to explain, so please see the attached BlazorJSImportBugReport.zip
BlazorJSImportBugReport.zip

Clicking "Test Regular Objects" shows that the JSObject instances works correctly with regular objects:

Clicking "Test HTMLDivElement Constructor" shows that it doesn't work for constructor objects:

Expected Behavior

I would expact any JavaScript object returned by a JSImport function to maintain it's identity, so the same JSObject is returned for the same JavaScript object. (Unless the JSObject has been disposed or garbage collected)

Steps To Reproduce

Use the attached demo project (See Home.razor, CallJavaScript1.cs and test.js)

Exceptions (if any)

No response

.NET Version

10.0.100 (But the problem is also in .NET 9 and probably also 8)

Anything else?

No response

[javiercn]

@lskyum thanks for contacting us.

I think I understand, but that's not something we have ever supported or are planning to support. We treat modules specially because we need to adjust the path and we cache the results of calling import, but we are not planning to do that in general for any JSInterop object as that will require us to keep an additional map at runtime and check against that.

You can implement this caching yourself if you choose to do so in your own logic.

[lskyum]

@javiercn Thank you for answering!

I have made a workaround by attaching a property "__dotNetId" to the constructor objects that i can then compare.

Other "regular" objects seems to consistently get the same JSObject, so that suggests there is some caching mechanism for them?
I guess that is also why they are disposable, but that is just an assumption.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.