Bewährte Methoden für ASP.NET Core Blazor JavaScript-Interoperabilität (JS Interoperabilität) Performance

Aufrufe zwischen .NET und JavaScript erfordern zusätzlichen Aufwand, da:

• Aufrufe sind asynchron.
• Parameter und Rückgabewerte werden JSON-serialisiert, um einen leicht verständlichen Konvertierungsmechanismus zwischen .NET- und JavaScript-Typen bereitzustellen.

Darüber hinaus werden diese Aufrufe für serverseitige Blazor Apps über das Netzwerk weitergegeben.

Vermeiden Sie übermäßige feingliedrige Anfragen

Da jeder Anruf einen gewissen Aufwand erfordert, kann es hilfreich sein, die Anzahl der Anrufe zu reduzieren. Beachten Sie den folgenden Code, der eine Sammlung von Elementen im Browser localStoragespeichert:

private async Task StoreAllInLocalStorage(IEnumerable<TodoItem> items)
{
    foreach (var item in items)
    {
        await JS.InvokeVoidAsync("localStorage.setItem", item.Id, 
            JsonSerializer.Serialize(item));
    }
}

Im vorherigen Beispiel wird für jedes Element ein separater JS Interoperabilitätsaufruf ausgeführt. Stattdessen wird der JS-Interop durch den folgenden Ansatz auf nur einen einzigen Aufruf reduziert:

private async Task StoreAllInLocalStorage(IEnumerable<TodoItem> items)
{
    await JS.InvokeVoidAsync("storeAllInLocalStorage", items);
}

Die entsprechende JavaScript-Funktion speichert die gesamte Sammlung von Elementen auf dem Client:

function storeAllInLocalStorage(items) {
  items.forEach(item => {
    localStorage.setItem(item.id, JSON.stringify(item));
  });
}

Bei Blazor WebAssembly Apps verbessert das Zusammenfassen einzelner JS Interoperabilitätsaufrufe zu einem einzigen Aufruf die Leistung in der Regel nur dann erheblich, wenn die Komponente eine große Anzahl von JS Interopaufrufen vornimmt.

Berücksichtigen Sie die Verwendung synchroner Aufrufe.

Aufruf von JavaScript in .NET

Dieser Abschnitt gilt nur für clientseitige Komponenten.

JS Interoperabilitätsaufrufe sind asynchron, unabhängig davon, ob der aufgerufene Code synchron oder asynchron ist. Die Aufrufe sind asynchron, um sicherzustellen, dass die Komponenten mit den serverseitigen und clientseitigen Rendermodi kompatibel sind. Auf dem Server müssen alle JS-Interop-Aufrufe asynchron sein, da sie über eine Netzwerkverbindung gesendet werden.

Wenn Ihre Komponente ausschließlich in WebAssembly ausgeführt wird, können Sie sich für synchrone JS-Interop-Aufrufe entscheiden. Dies ist mit etwas weniger Mehraufwand verbunden als asynchrone Aufrufe und kann zu weniger Renderingzyklen führen, da es keinen Zwischenzustand gibt, während auf die Ergebnisse gewartet wird.

Um in einer clientseitigen Komponente einen synchronen Aufruf von .NET an JavaScript zu richten, wandeln Sie IJSRuntime in IJSInProcessRuntime um, um den JS-Interop-Aufruf auszuführen:

@inject IJSRuntime JS

...

@code {
    protected override void HandleSomeEvent()
    {
        var jsInProcess = (IJSInProcessRuntime)JS;
        var value = jsInProcess.Invoke<string>("javascriptFunctionIdentifier");
    }
}

Mit IJSObjectReference in .NET 5 oder späteren clientseitigen Komponenten können Sie stattdessen IJSInProcessObjectReference synchron verwenden. IJSInProcessObjectReference implementiert IAsyncDisposable/IDisposable und sollte für die Garbage Collection entsorgt werden, um ein Speicherleck zu vermeiden, wie das folgende Beispiel zeigt:

@inject IJSRuntime JS
@implements IDisposable

...

@code {
    ...
    private IJSInProcessObjectReference? module;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            var jsInProcess = (IJSInProcessRuntime)JS;
            module = await jsInProcess.Invoke<IJSInProcessObjectReference>("import", 
                "./scripts.js");
            var value = module.Invoke<string>("javascriptFunctionIdentifier");
        }
    }

    ...

    void IDisposable.Dispose()
    {
        if (module is not null)
        {
            await module.Dispose();
        }
    }
}

Im vorangegangenen Beispiel ist ein JSDisconnectedException bei der Modulentsorgung nicht gefangen, weil es keine Blazor-SignalR -Schaltung in einer Blazor WebAssembly -App zu verlieren gibt. Weitere Informationen finden Sie unter ASP.NET Core Blazor JavaScript-Interoperabilität (JS Interop).

Aufrufen von .NET aus JavaScript

Dieser Abschnitt gilt nur für clientseitige Komponenten.

JS Interoperabilitätsaufrufe sind asynchron, unabhängig davon, ob der aufgerufene Code synchron oder asynchron ist. Die Aufrufe sind asynchron, um sicherzustellen, dass die Komponenten mit den serverseitigen und clientseitigen Rendermodi kompatibel sind. Auf dem Server müssen alle JS-Interop-Aufrufe asynchron sein, da sie über eine Netzwerkverbindung gesendet werden.

Wenn Ihre Komponente ausschließlich in WebAssembly ausgeführt wird, können Sie sich für synchrone JS-Interop-Aufrufe entscheiden. Dies ist mit etwas weniger Mehraufwand verbunden als asynchrone Aufrufe und kann zu weniger Renderingzyklen führen, da es keinen Zwischenzustand gibt, während auf die Ergebnisse gewartet wird.

Um einen synchronen Aufruf von JavaScript zu .NET in einer clientseitigen Komponente auszuführen, verwenden Sie DotNet.invokeMethod anstelle von DotNet.invokeMethodAsync.

Synchrone Aufrufe funktionieren, wenn:

• Die Komponente wird nur für die Ausführung in WebAssembly gerendert.
• Die aufgerufene Funktion gibt einen Wert synchron zurück. Die Funktion ist keine async Methode und gibt keine .NET Task - oder JavaScript-Eigenschaft Promisezurück.

Verwenden Sie JavaScript-Interop [JSImport]/[JSExport]

JavaScript-Interop [JSImport]/[JSExport] für Blazor WebAssembly-Apps bietet verbesserte Leistung und Stabilität gegenüber der JS-Interop-API in Framework-Versionen vor ASP.NET Core in .NET 7.

Weitere Informationen finden Sie unter JavaScript-Interoperabilität durch JSImport/JSExport mit ASP.NET Core-Blazor.