Blazor надає вам модель компонентів і цикл рендерингу, який не дуже звертає увагу на сторонній JavaScript. Doconut працює з цим, а не проти нього: рендеринг відбувається на боці сервера у вашому процесі, а віджет монтується у простий елемент, яким ви керуєте через звичайний життєвий цикл інтеропу.
Проблема
Клієнтський шлях означає доставку рушія рендерингу в браузер. У Blazor WebAssembly це безпосередньо збільшує розмір вашого завантаження, і він охоплює лише PDF — як тільки хтось завантажує DOCX або XLSX, ви повертаєтеся до початку.
Шлях iframe‑to‑Office означає, що ваші документи проходять через інфраструктуру іншої сторони, що вимагає розмови з вашою командою безпеки, яку ви, ймовірно, не хочете вести двічі.
Doconut обирає третій шлях. Файл растерується у зображення сторінок вашим власним сервером, і Blazor потрібно лише розмістити div. Ваше дерево компонентів ніколи не перерисовує переглядач, яким він не володіє, і механізм diff не має з чим боротися.
Можливості
Рендеринг виконується на боці сервера в будь-якому випадку. У Server виклик прямий; у WebAssembly ви відкриваєте виклик як мінімальну API‑точку і передаєте повернутий токен віджету. Обидва варіанти вміщаються у кілька рядків.
Ініціалізуйте віджет один раз, після першого рендерингу, через стандартний хук JS‑інтеропу. Оскільки Blazor ніколи не володіє внутрішнім DOM переглядача, подальші перерисовки залишають його недоторканим.
Interactive Server, Interactive WebAssembly або Auto. Переглядач керується непрозорим токеном, а не станом компоненту, тому зміна режиму рендерингу не змінює інтеграцію.
Той самий компонент відкриває PDF, DOCX, XLSX, PPTX, DWG, MSG та інші формати каталогу. Ви пишете одну сторінку переглядача, а не по одній для кожної сім'ї файлів.
Навігаційний інтерфейс входить у віджет. Ви підключаєте переглядач, а не створюєте його з canvas та поля вводу номера сторінки.
Нічого не передається в браузер, крім зображень відрендерених сторінок, що важливіше у WebAssembly, ніж люди очікують — клієнт, зрештою, повністю піддається інспекції.
Інтеграція
doconutHost.mount — це кілька рядків вашого власного JavaScript, який викликає $('#div_ctlDoc').docViewer({ ... }) і потім .View(token). Розміщення поза Blazor навмисне — DOM віджету не повинен бути тим, що рендерер намагається узгоджувати.
Підтримувані платформи
// 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);
}
}Деталі
Обидва варіанти. Рендеринг завжди відбувається на боці сервера, тому у WebAssembly ви додаєте одну точку, яка викликає OpenDocumentAsync і повертає токен. Клієнт ніколи не парсить документ, саме тому навантаження WASM залишається незмінним.
Ні, за умови, що ви монтуєте у елемент, який Blazor розглядає як листок. Відрендеріть порожній div і дайте віджету заповнити його через інтероп — механізм diff не має дітей для узгодження.
Ні. Одна сторінка обробляє весь каталог. Формат визначається з відкритого документа, а не вибирається вами заздалегідь.
ASP.NET Core
Реєструється як звичайний DI плюс проміжне ПЗ. Успадковує автентифікацію, логування та хостинг, які у вас вже є.
ASP.NET CoreСерверна візуалізація PDF у вигляді зображень сторінок — користувач читає документ, не отримуючи файл.
PDFТимчасова ліцензія займає кілька хвилин для запиту і працює повністю на вашому комп'ютері. Важливі файли — це ті, які вже порушують роботу вашого поточного переглядача.