Blazor le brinda un modelo de componentes y un bucle de renderizado que no se preocupa mucho por JavaScript de terceros. Doconut funciona con eso en lugar de contra él: el renderizado ocurre en el servidor en su propio proceso, y el widget se monta en un elemento sencillo que controla a través del ciclo de vida normal de interop.
El problema
La ruta del lado del cliente implica enviar un motor de renderizado al navegador. En Blazor WebAssembly eso impacta directamente en el tamaño de descarga, y solo cubre PDF — en el momento en que alguien sube un DOCX o un XLSX vuelves al punto de partida.
La ruta iframe-a-Office significa que sus documentos viajan a través de la infraestructura de terceros, lo cual implica una conversación con su equipo de seguridad que probablemente no quiera repetir.
Doconut toma la tercera ruta. El archivo se rasteriza a imágenes de página por su propio servidor, y Blazor solo necesita alojar un div. Su árbol de componentes nunca vuelve a renderizar un visor que no posee, y el motor de diferencias no tiene con qué luchar.
Capacidades
El renderizado es del lado del servidor en ambos casos. En Server la llamada es directa; en WebAssembly expone la llamada de apertura como un endpoint de API mínima y entrega el token devuelto al widget. Ambos son unas pocas líneas.
Inicialice el widget una vez, después del primer renderizado, mediante el hook estándar de interop JS. Debido a que Blazor nunca posee el DOM interno del visor, los renderizados posteriores lo dejan intacto.
Server interactivo, WebAssembly interactivo o Auto. El visor se controla mediante un token opaco en lugar del estado del componente, por lo que cambiar el modo de renderizado no altera la integración.
El mismo componente abre PDF, DOCX, XLSX, PPTX, DWG, MSG y el resto del catálogo. Usted escribe una página de visor, no una por familia de archivos.
La UI de navegación viene con el widget. Está conectando un visor, no construyendo uno a partir de un lienzo y una entrada de número de página.
Nada se transmite al navegador excepto imágenes de página renderizadas, lo cual es más importante en WebAssembly de lo que la gente espera — el cliente, después de todo, es totalmente inspeccionable.
Integración
doconutHost.mount es unas pocas líneas de su propio JavaScript que llama a $('#div_ctlDoc').docViewer({ ... }) y luego .View(token). Mantenerlo fuera de Blazor es deliberado — el DOM del widget no debe ser algo que el renderizador intente reconciliar.
Plataformas compatibles
// 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);
}
}Detalles
Ambos. El renderizado siempre ocurre del lado del servidor, por lo que en WebAssembly agrega un endpoint que llama a OpenDocumentAsync y devuelve el token. El cliente nunca analiza un documento, lo que explica exactamente por qué la carga WASM permanece sin cambios.
No, siempre que monte en un elemento que Blazor trata como una hoja. Renderice un div vacío y permita que el widget lo llene mediante interop — el motor de diferencias no tiene hijos que reconciliar.
No. Una página maneja todo el catálogo. El formato se detecta del documento que abre, no seleccionado por usted de antemano.
ASP.NET Core
Se registra como DI ordinario más middleware. Hereda la autenticación, el registro y el hosting que ya tienes.
ASP.NET CoreRenderizado de PDF del lado del servidor en imágenes de página — el usuario lee el documento sin recibir nunca el archivo.
PDFUna licencia temporal tarda unos minutos en solicitarse y se ejecuta completamente en tu propia máquina. Los archivos que importan son los que ya están rompiendo tu visor actual.