Blazor

Przeglądarka dokumentów, która działa wewnątrz Blazor

Blazor zapewnia model komponentów i pętlę renderowania, które nie przywiązują dużej wagi do zewnętrznego JavaScriptu. Doconut współpracuje z tym, a nie przeciwko niemu: renderowanie odbywa się po stronie serwera w Twoim własnym procesie, a widżet montuje się w zwykłym elemencie, którym sterujesz poprzez standardowy cykl życia interop.

75
rozszerzenia plików, brak parsowania po stronie klienta
2
obsługiwane modele hostingu
0
payload WASM do renderowania

Problem

Dlaczego tradycyjne podejścia szkodzą w Blazor

Ścieżka po stronie klienta oznacza dostarczenie silnika renderującego do przeglądarki. W Blazor WebAssembly zwiększa to bezpośrednio rozmiar pobrania i obsługuje jedynie PDF — w momencie, gdy ktoś załaduje DOCX lub XLSX, wracasz do punktu wyjścia.

Ścieżka iframe-do-Office oznacza, że Twoje dokumenty przechodzą przez infrastrukturę osób trzecich, co wymaga rozmowy z zespołem bezpieczeństwa, której prawdopodobnie nie chcesz prowadzić dwa razy.

Doconut przyjmuje trzecią ścieżkę. Plik jest rasteryzowany do obrazów stron przez Twój własny serwer, a Blazor musi jedynie hostować element div. Drzewo komponentów nigdy nie renderuje ponownie przeglądarki, której nie posiada, a silnik różnicowy nie ma z czym walczyć.

Możliwości

Co otrzymujesz w aplikacji Blazor

Blazor Server i WebAssembly

Renderowanie odbywa się po stronie serwera w obu przypadkach. W Server wywołanie jest bezpośrednie; w WebAssembly udostępniasz wywołanie otwarcia jako minimalny punkt API i przekazujesz zwrócony token widżetowi. Oba rozwiązania mieszczą się w kilku linijkach.

Montuje się przez OnAfterRenderAsync

Zainicjalizuj widżet raz, po pierwszym renderze, za pomocą standardowego hooka JS interop. Ponieważ Blazor nigdy nie posiada wewnętrznego DOM przeglądarki, kolejne renderowania pozostawiają go nietkniętym.

Działa w wybranym trybie renderowania

Interactive Server, Interactive WebAssembly lub Auto. Przeglądarka jest sterowana nieprzezroczystym tokenem, a nie stanem komponentu, więc zmiana trybu renderowania nie wpływa na integrację.

Brak luk w formatach

Ten sam komponent otwiera PDF, DOCX, XLSX, PPTX, DWG, MSG oraz pozostałe formaty katalogu. Tworzysz jedną stronę przeglądarki, a nie po jedną dla każdej rodziny plików.

Miniatury, wyszukiwanie i drukowanie

Interfejs nawigacji jest wbudowany w widżet. Łączysz przeglądarkę, a nie budujesz jej od podstaw przy użyciu płótna i pola numeru strony.

Dokumenty pozostają na Twoim serwerze

Do przeglądarki nie jest przesyłane nic poza renderowanymi obrazami stron, co ma większe znaczenie w WebAssembly niż się spodziewano — klient jest w końcu w pełni podglądany.

Integracja

Program.cs i strona Blazor

doconutHost.mount to kilka linijek Twojego własnego JavaScriptu, które wywołuje $('#div_ctlDoc').docViewer({ ... }) a następnie .View(token). Trzymanie tego poza Blazor jest celowe — DOM widżetu nie powinien być czymś, co renderer próbuje zredukować.

Obsługiwane platformy

Blazor ServerBlazor WebAssembly.NET 8.NET 6WindowsDocker
csharp
// Program.cs — order matters
builder.Services.AddDoconut(options =>
{
    options.LicensePath = "Doconut.Viewer.lic";
});
builder.Services.AddSession();

app.UseSession();          // before UseDoconut()
app.UseDoconutResources(); // before UseDoconut()
app.UseDoconut();

// Viewer.razor — open server-side, hand the token to the widget
@inject Doconut.Viewer Viewer
@inject IJSRuntime JS

<div id="divDocViewer"><div id="div_ctlDoc"></div></div>

@code {
    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (!firstRender) return;

        // Authorize first — the viewer renders whatever you hand it.
        string token = await Viewer.OpenDocumentAsync("wwwroot/files/Sample.pdf");
        await JS.InvokeVoidAsync("doconutHost.mount", token);
    }
}

Szczegóły

Warto wiedzieć przed rozpoczęciem

  • Widżet jest wtyczką jQuery, więc jQuery musi zostać załadowane przed skryptami przeglądarki.
  • UseSession() i UseDoconutResources() muszą być zarejestrowane przed UseDoconut().
  • W WebAssembly wywołanie otwarcia należy do serwera — udostępnij je jako minimalny punkt API i zwróć jedynie token.
  • Token jest nieprzezroczysty. Nie umieszczaj go w ciągu zapytania, który logujesz, i nie przechowuj w stanie komponentu dłużej niż trwa strona.

Najczęściej zadawane pytania

Czy to działa w Blazor WebAssembly, czy tylko w Server?

Oba. Renderowanie zawsze odbywa się po stronie serwera, więc w WebAssembly dodajesz jeden punkt końcowy, który wywołuje OpenDocumentAsync i zwraca token. Klient nigdy nie parsuje dokumentu, co dokładnie wyjaśnia, dlaczego payload WASM pozostaje niezmieniony.

Czy renderer Blazor będzie walczył z DOM przeglądarki?

Nie, pod warunkiem że montujesz w elemencie, który Blazor traktuje jako liść. Renderuj pusty div i pozwól widżetowi wypełnić go poprzez interop — silnik różnicowy nie ma dzieci do reconciliacji.

Czy potrzebuję osobnej strony przeglądarki dla każdego typu pliku?

Nie. Jedna strona obsługuje cały katalog. Format jest wykrywany na podstawie otwieranego dokumentu, a nie wybrany przez Ciebie wcześniej.

Wypróbuj to na własnych dokumentach

Tymczasowa licencja wymaga kilku minut na zamówienie i działa w pełni na Twoim komputerze. Najważniejsze pliki to te, które już psują Twój obecny podgląd.