Ability to check for JavaScript runtime support

[yugabe]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

In .NET 8, an internal type named UnsupportedJavaScriptRuntime was moved from the namespace Microsoft.AspNetCore.Mvc.ViewFeatures to Microsoft.AspNetCore.Components.Endpoints, and an exception message text was changed. The latter led to a downstream bug surfacing in MudBlazor.

Library authors, but not only them, should be able to decide at runtime if a given IJSRuntime instance is able to run interop requests or not. Currently, the only recommended way to safely run JavaScript code in both Blazor Server and WebAssembly is to run it in the component's overridden OnAfterRender(bool firstRender) method. This is in many cases undesirable (service calls, timers, library authoring etc.).

It is very difficult and error-prone to decide if JavaScript should be called in some cases. Especially during prerendering, JavaScript operations are not available. For this reason, it should be possible to decide if JavaScript operations are supported in a given context.

Describe the solution you'd like

The IJSRuntime interface could be extended with a bool IsSupported property, and all implementations could simply return a constant true, except for the UnsupportedJavaScriptRuntime, which would return false.

Additional context

To check if user code should call JavaScript at all, users have a few options:

• Check if IJSRuntime.GetType().Name == "UnsupportedJavaScriptRuntime". This is extremely error prone, given the type is internal and could change at any time, or even if there are other runtimes that could implement IJSRuntime.
• Simply try calling into JavaScript and catch the resulting InvalidOperationException. However, it is not definite an exception of this type would only surface from the expected call and nothing else downstream. A custom Exception type would probably solve this issue as well (but a simple flag check should be more explicit, cleaner and more performant/efficient than an exception-driven solution). One could also check for the exception's Message, but that is exactly what made the above bug appear in MudBlazor as well.
• Only call JavaScript in OnAfterRenderAsync. This only works in component code, thus services or library authors have a hard time.
• Check if running in a browser: checking for System.OperatingSystem.IsBrowser() (or a compile time equivalent) is not correct because Blazor Server has its own implementation as well. This won't produce false positives, but will produce false negatives. Nor is it enough to check if currently running in Blazor Server, because Microsoft.Extensions.DependencyInjection.ComponentServiceCollectionExtensions.AddServerSideBlazor will add a scoped RemoteJSRuntime (internal as well) on top of UnsupportedJSRuntime (to shadow it in DI).

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ScarletKuro]

For this reason, it should be possible to decide if JavaScript operations are supported in a given context (especially during prerendering).

Similar issue #49497 but offers alternative design by adding lifecycle method instead of some property, but with help of it you would be able to understand when you are attached to the browser as well.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

This is likely covered by #49401

[yugabe]

@javiercn yes, maybe. But maybe it's worth considering to allow the IJSRuntime and related symbols to be agnostic from rendering concepts? Web workers, alternative (to Blazor) frameworks, rendering-agnostic features etc.

[mkArtakMSFT]

Closing this as we think the API we've added as part of #49401 is good enough. If not, we'll find out in the future and react accordingly.