Blazor

Um visualizador de documentos que funciona dentro do Blazor

Blazor oferece um modelo de componentes e um loop de renderização que não se preocupa muito com JavaScript de terceiros. Doconut trabalha com isso em vez de contra ele: a renderização ocorre no lado do servidor no seu próprio processo, e o widget é inserido em um elemento simples que você controla através do ciclo de vida normal de interop.

75
extensões de arquivo, sem análise no cliente
2
modelos de hospedagem suportados
0
carga WASM para renderização

O problema

Por que as abordagens usuais são problemáticas no Blazor

A rota do lado do cliente implica enviar um motor de renderização para o navegador. No Blazor WebAssembly isso impacta diretamente o tamanho do download, e ele só cobre PDF — no momento em que alguém envia um DOCX ou um XLSX você volta ao ponto de partida.

A rota iframe‑to‑Office significa que seus documentos passam por uma infraestrutura de terceiros, o que gera uma conversa com sua equipe de segurança que provavelmente você não quer ter duas vezes.

Doconut adota a terceira rota. O arquivo é rasterizado em imagens de página pelo seu próprio servidor, e o Blazor só precisa hospedar um div. Sua árvore de componentes nunca re‑renderiza um visualizador que não possui, e o motor de diff não tem com o que lutar.

Capacidades

O que você obtém em um aplicativo Blazor

Blazor Server e WebAssembly

A renderização é no lado do servidor em ambos os casos. No Server a chamada é direta; no WebAssembly você expõe a chamada de abertura como um endpoint de API mínima e entrega o token retornado ao widget. Ambos requerem apenas algumas linhas.

Montado através de OnAfterRenderAsync

Inicialize o widget uma vez, após a primeira renderização, usando o hook padrão de interop JS. Como o Blazor nunca possui o DOM interno do visualizador, renderizações subsequentes o deixam intocado.

Funciona com o modo de renderização que você escolheu

Interactive Server, Interactive WebAssembly ou Auto. O visualizador é controlado por um token opaco em vez do estado do componente, portanto mudar o modo de renderização não altera a integração.

Sem lacunas de formato

O mesmo componente abre PDF, DOCX, XLSX, PPTX, DWG, MSG e o restante do catálogo. Você cria uma única página de visualizador, não uma por família de arquivos.

Miniaturas, pesquisa e impressão

A UI de navegação vem com o widget. Você está conectando um visualizador, não construindo um a partir de um canvas e um campo de número de página.

Os documentos permanecem no seu servidor

Nada é transmitido ao navegador exceto imagens de página renderizadas, o que importa mais no WebAssembly do que as pessoas esperam — o cliente é, afinal, totalmente inspecionável.

Integração

Program.cs e uma página Blazor

doconutHost.mount são algumas linhas do seu próprio JavaScript que chamam $('#div_ctlDoc').docViewer({ ... }) e então .View(token). Mantê‑lo fora do Blazor é deliberado — o DOM do widget não deve ser algo que o renderizador tente reconciliar.

Plataformas suportadas

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

Detalhes

Vale a pena saber antes de começar

  • O widget é um plugin jQuery, portanto o jQuery deve ser carregado antes dos scripts do visualizador.
  • UseSession() e UseDoconutResources() devem ser registrados antes de UseDoconut().
  • No WebAssembly a chamada de abertura pertence ao servidor — exponha-a como um endpoint de API mínima e retorne apenas o token.
  • O token é opaco. Não o coloque em uma string de consulta que você registre, e não o armazene em cache no estado do componente por mais tempo que a página exista.

Perguntas frequentes

Isso funciona no Blazor WebAssembly ou apenas no Server?

Ambos. A renderização sempre ocorre no lado do servidor, portanto no WebAssembly você adiciona um endpoint que chama OpenDocumentAsync e retorna o token. O cliente nunca analisa um documento, o que explica exatamente por que a carga WASM permanece inalterada.

O renderizador do Blazor vai entrar em conflito com o DOM do visualizador?

Não, desde que você monte em um elemento que o Blazor trata como folha. Renderize um div vazio e deixe o widget preenchê‑lo via interop — o motor de diff não tem filhos para reconciliar.

Preciso de uma página de visualizador separada para cada tipo de arquivo?

Não. Uma única página lida com todo o catálogo. O formato é detectado a partir do documento que você abre, não selecionado por você previamente.

Experimente com seus próprios documentos

Uma licença temporária leva alguns minutos para ser solicitada e funciona totalmente na sua própria máquina. Os arquivos que importam são os que já estão quebrando seu visualizador atual.