Blazor Server e WebAssembly
Il rendering è lato server in entrambi i casi. In Server la chiamata è diretta; in WebAssembly esponi la chiamata open come endpoint API minimale e passi il token restituito al widget. Entrambi richiedono poche righe.
Blazor
Un visualizzatore di documenti che si comporta all'interno di Blazor
Blazor ti offre un modello di componenti e un ciclo di rendering che non si preoccupa molto del JavaScript di terze parti. Doconut lavora con questo piuttosto che contro di esso: il rendering avviene lato server nel tuo processo, e il widget si monta in un semplice elemento che controlli attraverso il normale ciclo di vita dell'interoperabilità.
- 75
- estensioni file, nessun parsing client
- 2
- modelli di hosting supportati
- 0
- payload WASM per il rendering
Il problema
Perché gli approcci tradizionali sono problematici in Blazor
Il percorso client-side significa inviare un motore di rendering nel browser. In Blazor WebAssembly ciò incide direttamente sulla dimensione del download, e copre solo PDF — nel momento in cui qualcuno carica un DOCX o un XLSX torni al punto di partenza.
Il percorso iframe-to-Office significa che i tuoi documenti attraversano l'infrastruttura di qualcun altro, il che comporta una discussione con il tuo team di sicurezza che probabilmente non vuoi avere due volte.
Doconut prende la terza via. Il file viene rasterizzato in immagini di pagina dal tuo server, e Blazor deve solo ospitare un div. Il tuo albero di componenti non re-renderizza mai un visualizzatore che non possiede, e il motore di diff non ha nulla con cui combattere.
Funzionalità
Cosa ottieni in un'app Blazor
Montaggi tramite OnAfterRenderAsync
Inizializza il widget una volta, dopo il primo render, tramite l'hook standard di interop JS. Poiché Blazor non possiede mai il DOM interno del visualizzatore, i render successivi lo lasciano intatto.
Funziona con la modalità di rendering scelta
Interactive Server, Interactive WebAssembly o Auto. Il visualizzatore è guidato da un token opaco piuttosto che dallo stato del componente, quindi cambiare modalità di rendering non altera l'integrazione.
Nessuna lacuna di formato
Lo stesso componente apre PDF, DOCX, XLSX, PPTX, DWG, MSG e il resto del catalogo. Scrivi una pagina visualizzatore, non una per ogni famiglia di file.
Miniature, ricerca e stampa
L'interfaccia di navigazione è fornita con il widget. Stai collegando un visualizzatore, non costruendone uno da una tela e un input per il numero di pagina.
I documenti rimangono sul tuo server
Nulla viene trasmesso al browser se non le immagini delle pagine renderizzate, il che è più importante in WebAssembly di quanto la gente si aspetti — il client è, dopotutto, completamente ispezionabile.
Integrazione
Program.cs e una pagina Blazor
doconutHost.mount è qualche riga del tuo JavaScript che chiama $('#div_ctlDoc').docViewer({ ... }) e poi .View(token). Tenerlo fuori da Blazor è deliberato — il DOM del widget non dovrebbe essere qualcosa che il renderer tenta di riconciliare.
Piattaforme supportate
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);
}
}Dettagli
Vale la pena sapere prima di iniziare
- Il widget è un plugin jQuery, quindi jQuery deve caricarsi prima degli script del visualizzatore.
- UseSession() e UseDoconutResources() devono entrambi essere registrati prima di UseDoconut().
- In WebAssembly la chiamata open appartiene al server — esponila come endpoint API minimale e restituisci solo il token.
- Il token è opaco. Non inserirlo in una stringa di query che registri, e non memorizzarlo nella stato del componente più a lungo della vita della pagina.
Domande frequenti
Funziona in Blazor WebAssembly o solo in Server?
Entrambi. Il rendering avviene sempre lato server, quindi in WebAssembly aggiungi un endpoint che chiama OpenDocumentAsync e restituisce il token. Il client non analizza mai un documento, ed è proprio per questo che il payload WASM rimane inalterato.
Il renderer di Blazor combatterà con il DOM del visualizzatore?
No, a condizione che tu lo monti in un elemento che Blazor tratta come foglia. Renderizza un div vuoto e lascia che il widget lo popoli tramite interop — il motore di diff non ha figli da riconciliare.
Ho bisogno di una pagina visualizzatore separata per tipo di file?
No. Una pagina gestisce l'intero catalogo. Il formato viene rilevato dal documento che apri, non selezionato da te in anticipo.
Soluzioni correlate
ASP.NET Core
Tre chiamate middleware, non una riscrittura
Si registra come DI ordinario più middleware. Eredita l'autenticazione, il logging e l'hosting che hai già.
ASP.NET CoreUn visualizzatore PDF che non consegna il PDF
Rendering PDF lato server in immagini di pagina — l'utente legge il documento senza mai ricevere il file.
PDFProvalo con i tuoi documenti
Una licenza temporanea richiede pochi minuti per essere richiesta e funziona interamente sul tuo computer. I file che contano sono quelli che già interrompono il tuo visualizzatore corrente.