ImportMap Tag in Oqtane

[Sharafudeen]

Hi,

Can Oqtane incorporate an <ImportMap /> tag feature, similar to what is available in the Blazor Web App project template in .NET 9?

Blazor Web App -> App.razor file:

Browser Rendered Scripts:

[sbwalker]

@Sharafudeen no Oqtane does not support the new ImportMap as it uses its own method for defining Resources in modules/themes.

[Sharafudeen]

@sbwalker Understood. However, why is it necessary to define all dependent JavaScript files in the resources when we’ve already referenced the dependent DLLs in the Dependencies property?

Since we are using Blazor, minimizing JavaScript dependencies is a key objective, which is why we are opting for MudBlazor and MudBlazor.Extensions. In the Blazor Web App project template, when adding MudBlazor and MudBlazor.Extensions, the CSS and JavaScript files are automatically loaded with their dependencies.

Is there a way to implement this functionality in Oqtane?

[Sharafudeen]

@sbwalker Could you also explain how to use the Bundle property within the Resources?

[Sharafudeen]

@sbwalker I’ve encountered another issue while adding versioning to the JavaScript/CSS files in the resources. When versioning is applied, it results in duplication in the browser rendering.

Edit: The duplication occurs because I have another module's JavaScript file with references.

Resources Definition:

Browser Rendered:

[sbwalker]

@Sharafudeen

Understood. However, why is it necessary to define all dependent JavaScript files in the resources when we’ve already referenced the dependent DLLs in the Dependencies property?

Referencing the dependent DLLs in the Dependencies property does not provide Oqtane any information about the static resources which those DLLs rely upon. All of the information about static resources are stored in the Nuget package - which is not an artifact which Oqtane can interogate at run-time to obtain the dependency information. Therefore, the static resources need to be declared in the component.

Standard Blazor avoids this problem because it is not modular - it assumes that all of an application's dependencies are tightly coupled and linked to the main Blazor project via Nuget references. It uses these references during BUILD to extract the static resources to the appropriate locations so that the application is able to reference them. This monolithic approach simplifies the management of static resources from a development perspective, however it comes at the expense of modularity, granular deployment, etc... If you want to use a modular approach then you need to take responsibility for understanding for the entire life cycle of your static assets.

Since we are using Blazor, minimizing JavaScript dependencies is a key objective, which is why we are opting for MudBlazor and MudBlazor.Extensions. In the Blazor Web App project template, when adding MudBlazor and MudBlazor.Extensions, the CSS and JavaScript files are automatically loaded with their dependencies.

Please note that by using MudBlazor or almost any third party UI component library, you are NOT minimizing JavaScript dependencies. These UI component libraries are usually just wrappers around tons of JavaScript - so by using them you are in fact MAXIMIZING your JavaScript dependencies. This fact is hidden from developers in standard Blazor because they are embedded in Nuget packages and magically extracted during BUILD time to your system so that you do not even know they exist - and you write your components against a strongly typed C# wrapper - which provides a native facade when you are actually executing a ton of JavaScript.

Is there a way to implement this functionality in Oqtane?

The short answer is NO.... as I explained above the development experience in standard Blazor focuses on monolithic, tightly coupled, static applications which rely on BUILD magic to orchestrate resources, and full-scale monolithic application deployments. Oqtane uses a totally different approach based on micro-frontends/services, loose coupling, dynamic applications which rely on RUNTIME orchestration and micro deployments.

Could you also explain how to use the Bundle property within the Resources?

The Bundle property on the Resource class is only used in Interactive render mode and provides a way for you to group together static JavaScript assets so that they are injected in a specific order. The Oqtane.Client\Modules\Controls\QuillJSTextEditor.razor is an example of an interactive component which has 3 JavaScript resources that must be declared in a specific order and use the Bundle property to achieve this. Technically, the Bundle concept is a feature of the LoadJS library which Oqtane uses for dynamically loading scripts.

I’ve encountered another issue while adding versioning to the JavaScript/CSS files in the resources. When versioning is applied, it results in duplication in the browser rendering.

I fixed this issue today and it will be included in the next release (#5188)

[Sharafudeen]

@sbwalker Thank you! As you pointed out, referencing all the dependent DLLs in Dependencies, along with the Stylesheets and JavaScript files in the Resources, resolves the issue.

Is there a way to include all wwwroot/_content files in the Resources without specifying them individually?

Static Assets:

Manually Added Static Assets:

[Sharafudeen]

@sbwalker Any idea on this..?

[sbwalker]

@Sharafudeen I believe I already answered this question previously. Even if Oqtane allowed you to specify a path to a folder, at run-time it would need to iterate through the contents of that folder to determine what it contains. It would be able to identify the *.js files however it would have no idea if they are traditional JS files or JS modules, whether they need to be injected in the head or body, whether they are applicable to interactive or static scenarios, or basically anything about their expected behavior. This is the purpose of the Resources property - to provide Oqtane with this meta data... which means it needs to be explicitly defined.