JSInitializer.importInitializersAsync doesn't respect initializerArguments

[T-mp]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

"JSInitializer.importInitializersAsync" always loads relative to "document.baseURI" and ignores "initializerArguments".

Expected Behavior

"JSInitializer.importInitializersAsync" uses "initializerArguments.loadBootResource", same as in "Blazor.start", and uses "document.baseURI" only as a fallback.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

7.0.100-rc.2.22477.23

Anything else?

No response

[javiercn]

@T-mp thanks for contacting us.

This is by design. Initializers are not exclusive to Blazor webassembly. There is no generic loadBootResource. In addition to that, initializers can alter loadBootResource in the Blazor Options so they themselves can't (and shouldn't) rely on it.

[T-mp]

My problem is that in the function "adjustPath" (line 16ff) "document.baseURI" is always set before the URL. Due to this behaviour, integration into applications that are located on a different host than the component is not possible.

If "JSInitializers.ts" is supposed to be independent of Blazor, why is "BlazorInitializer" used in line 25 and "typeof Blazor" line 40?

I think, since the file is compiled into "blazor.webassembly.js" and types of Blazor are used, checking if "loadBootResource" is present (and if so, also using it) would be justifiable.

Two gatekeepers would not interfere here but would extend the possibilities of use.

Suggested change (adjustPath start at line 16):

    function adjustPath(path: string): string {
        if (t.length > 0 && t[0].loadBootResource) {
            return t[0].loadBootResource("libraryInitializers","",e,"");
        }
        if (e.startsWith("https://") || e.startsWith("http://")) {
            return e;
        }
        // This is the same we do in JS interop with the import callback
        const base = document.baseURI;
        path = base.endsWith('/') ? `${base}${path}` : `${base}/${path}`;
        return path;
    }

The call to "loadBootResource" probably still needs to be adapted.
And the query for absolute URIs is also untested, created in this comment.

I refer to the version: https://github.com/dotnet/aspnetcore/blob/231cc287ef848dfc90dab9b3a1eeb7bdbf243d57/src/Components/Web.JS/src/JSInitializers/JSInitializers.ts

[javiercn]

If "JSInitializers.ts" is supposed to be independent of Blazor, why is "BlazorInitializer" used in line 25 and "typeof Blazor" line 40?

Independent of the Blazor flavor, not of Blazor itself.

[javiercn]

Due to this behaviour, integration into applications that are located on a different host than the component is not possible.

I am somewhat ok with checking for an absolute URL and returning it directly, I think that is acceptable.

        if (t.length > 0 && t[0].loadBootResource) {
            return t[0].loadBootResource("libraryInitializers","",e,"");
        }

This part I am not, since this is shared source between webassembly, server and webview and we want to avoid differentiation as much as possible.

It would be great if you can include some more details about the scenario you are trying to enable as it will help to prioritize this issue.

Would you not have this same problem when you call import from JS interop?

Hi @T-mp. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[T-mp]

OK, with excluding global URLs in the "aspnetcore/src/Components/Web.JS/src/JSInitializers/JSInitializers.ts" in the "adjustPath" function

    function adjustPath(path: string): string {
        if (e.startsWith("https://") || e.startsWith("http://")) {
            return e;
        }
        // This is the same we do in JS interop with the import callback
        const base = document.baseURI;
        path = base.endsWith('/') ? `${base}${path}` : `${base}/${path}`;
        return path;
    }

And a change in the aspnetcore/src/Components/Web.JS/src/JSInitializers/JSInitializers.WebAssembly.ts which is for WebAssembly. Which does the mapping, the function would be complete.

export async function fetchAndInvokeInitializers(bootConfig: BootJsonData, options: Partial<WebAssemblyStartOptions>): Promise<JSInitializer> {
    const initializers = bootConfig.resources.libraryInitializers;
    const jsInitializer = new JSInitializer();
    if (initializers) {
        var libUrls = Object.keys(initializers);
        if (options && options.loadBootResource) {
            libUrls = libUrls.map(libRelUrl => {
                var urlResult = options.loadBootResource("libraryInitializers", libRelUrl, libRelUrl, "");
                if ("string" == typeof urlResult)
                    return urlResult;
                else if (urlResult)
                    throw new Error(`For a 'libraryInitializers' (${libRelUrl}) resource, custom loaders must supply a URI string.`)
                return libRelUrl;
            });
        }
        await jsInitializer.importInitializersAsync(libUrls, []);
    }

    return jsInitializer;
}

The mapping in the interop is different:

       if (typeof url === "string" && url.startsWith("./")) {
           url = document.baseURI + url.substr(2);
       }

So has the possibility of not being changed.
But it is not needed in our project.

If these changes are acceptable, you don't need to think your way into a medium complex project either, and I'll save myself any potential copyright issues ;-)
If you have any questions, I'm of course happy to help.