Blazor

En dokumentvisare som fungerar i Blazor

Blazor ger dig en komponentmodell och en renderingsloop som inte bryr sig så mycket om tredjeparts-JavaScript. Doconut fungerar med det snarare än emot det: rendering sker på servern i din egen process, och widgeten monteras i ett enkelt element som du kontrollerar genom den vanliga interop‑livscykeln.

Begär utvärderingsåtkomstVisa priser
75
filändelser, ingen klientparsing
2
värdmodeller som stöds
0
WASM‑payload för rendering

Problemet

Varför de vanliga metoderna är problematiska i Blazor

Klientsidan innebär att skicka en renderingsmotor till webbläsaren. I Blazor WebAssembly påverkar det direkt din nedladdningsstorlek, och den täcker bara PDF — så snart någon laddar upp en DOCX eller en XLSX är du tillbaka på ruta ett.

Iframe‑till‑Office‑vägen innebär att dina dokument tar en resa genom någon annans infrastruktur, vilket är ett samtal med ditt säkerhetsteam du förmodligen inte vill ha två gånger.

Doconut tar den tredje vägen. Filen rasteriseras till sidbilder av din egen server, och Blazor behöver bara vara värd för en div. Ditt komponentträd renderar aldrig om en visare som den inte äger, och diff‑motorn har inget att kämpa med.

Funktioner

Vad du får i en Blazor‑app

Blazor Server och WebAssembly

Rendering sker på servern i båda fallen. I Server är anropet direkt; i WebAssembly exponerar du öppningsanropet som en minimal API‑endpoint och ger den returnerade token till widgeten. Båda kräver bara ett fåtal rader.

Monteras via OnAfterRenderAsync

Initiera widgeten en gång, efter den första renderingen, via den standardiserade JS‑interop‑hooken. Eftersom Blazor aldrig äger visarens interna DOM, lämnar efterföljande renderingar den orörd.

Fungerar med det renderingsläge du valt

Interactive Server, Interactive WebAssembly eller Auto. Visaren drivs av en opak token snarare än komponenttillstånd, så byte av renderingsläge ändrar inte integrationen.

Inga formatluckor

Samma komponent öppnar PDF, DOCX, XLSX, PPTX, DWG, MSG och resten av katalogen. Du skriver en visningssida, inte en per filfamilj.

Miniatyrer, sökning och utskrift

Navigations‑UI följer med widgeten. Du kopplar in en visare, inte bygger en från en canvas och ett sidnummer‑fält.

Dokumenten stannar på din server

Ingenting strömmas till webbläsaren förutom renderade sidbilder, vilket är viktigare i WebAssembly än vad folk förväntar sig — klienten är trots allt fullt inspekterbar.

Integration

Program.cs och en Blazor‑sida

doconutHost.mount är några rader av din egen JavaScript som anropar $('#div_ctlDoc').docViewer({ ... }) och sedan .View(token). Att hålla det utanför Blazor är avsiktligt — widgetens DOM bör inte vara något som renderaren försöker förena.

Stödda plattformar

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);
    }
}

Detaljer

Värt att veta innan du börjar

  • Widgeten är ett jQuery‑plugin, så jQuery måste laddas innan visarskriptet.
  • UseSession() och UseDoconutResources() måste båda registreras innan UseDoconut().
  • I WebAssembly hör öppningsanropet på servern — exponera det som en minimal API‑endpoint och returnera endast token.
  • Token är opak. Lägg inte in den i en query‑string du loggar, och cachea den inte i komponenttillstånd längre än sidan lever.

Vanliga frågor

Fungerar detta i Blazor WebAssembly, eller bara Server?

Båda. Rendering sker alltid på servern, så i WebAssembly lägger du till en endpoint som anropar OpenDocumentAsync och returnerar token. Klienten parsar aldrig ett dokument, vilket är exakt varför WASM‑payloaden förblir opåverkad.

Kommer Blazors renderare att kämpa med visarens DOM?

Nej, förutsatt att du monterar i ett element som Blazor behandlar som ett löv. Rendera en tom div och låt widgeten fylla den via interop — diff‑motorn har inga barn att förena.

Behöver jag en separat visningssida per filtyp?

Nej. En sida hanterar hela katalogen. Formatet upptäcks från dokumentet du öppnar, inte valt av dig i förväg.

Relaterade lösningar

ASP.NET Core

Tre middleware-anrop, ingen omskrivning

Registreras som vanlig DI plus middleware. Ärver den autentisering, loggning och hosting du redan har.

ASP.NET Core

PDF

En PDF‑visare som inte överlämnar PDF‑filen

Server‑sidig PDF‑rendering till sidbilder — användaren läser dokumentet utan att någonsin ta emot filen.

PDF

Prova det med dina egna dokument

En tillfällig licens tar några minuter att begära och körs helt på din egen maskin. De filer som är viktiga är de som redan stör din nuvarande visare.

Begär utvärderingsåtkomstLäs dokumentationen