JSImport: Not enough information regarding interop for non-module code

[yugabe]

The page doesn't mention the [JSImport] overload that only takes a single string functionName argument (without the string moduleName second parameter):

This implies there is an alternate way to reference functions, but the page makes no mention of this. The API/source isn't clear either:

As the alternative IJSRuntime-based JS interop takes objects that reside on the global object, it is not straighforward to migrate to the new JSImport-based solution. This can be increasingly troublesome, because bundling the resulting application code in a JavaScript bundle might not support exporting the bundle as an EcmaScript module (webpack support is only experimental). Bundling (with minification, optimizations etc.) is still considered by many a superior solution than loading individual (small) module files over network and can simplify deployment or caching of resources.

The questions unclear are:

• Is there a way to refer to already loaded objects/functions instead of loading different modules?
• How to use the [JSImport(string functionName)] overload of the attribute?

I haven't found an easy way to invoke non-module members with JSImport, but if it is an intentional design choice, there is a simple hack to work around that:

const w = window;
export { w as window };

I'd rather the API supported the window/global object by default.

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 8aab92a0-c05f-ef01-fb74-a0bf525aae69
• Version Independent ID: 8aab92a0-c05f-ef01-fb74-a0bf525aae69
• Content: JavaScript JSImport/JSExport interop with ASP.NET Core Blazor WebAssembly
• Content Source: aspnetcore/blazor/javascript-interoperability/import-export-interop.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @yugabe ... Let's ping @pavelsavara for comment on this.

[pavelsavara]

• module name on JSImport is just a name. It doesn't have to be JS file. You could use setModuleImports to set the exports of virtual "module" and bind it to any function, even things on globalThis. Example
• You can pass globalThis prefix to [JSImport("globalThis.console.log")] Example

[yugabe]

Thanks @pavelsavara, I'll take a look. I tried prefixing with "window", but it didn't work (didn't log an error either, but it's probably an issue elsewhere in my code base). This is enough for me to go on.

This could maybe worth mentioning in the docs, especially as it seems this is just undocumented, but there are test cases that support it is working. @guardrex?

[guardrex]

I'll take look, but it will probably be tomorrow/Friday due to on-going .NET 7 docs work.

[pavelsavara]

didn't log an error either

It could not fail on compile time when the attribute is processed, because we don't know if you provided window module at runtime. It would fail when you call the imported function.

[yugabe]

Yes, I was talking about invoking the method, not compilation. Invoking the imported method does nothing currently for me. But as I said, don't worry about it, the problem is most probably elsewhere. If I can reproduce it in a controlled environment, I'll open an issue.

[yugabe]

The issue was indeed in one of my test projects (Blazor didn't register some event handlers correctly, so the generated interop method wasn't called).

Using it as @pavelsavara described works as intended. Prefixing with "window" in itself does not work, but "globalThis" does. Thanks for the help.