Blazor Server และ WebAssembly
การเรนเดอร์เป็นแบบเซิร์ฟเวอร์ไม่ว่ากรณีใด. ใน Server การเรียกเป็นโดยตรง; ใน WebAssembly คุณเปิดเผยการเรียก open เป็น endpoint API ขั้นต่ำและส่ง token ที่คืนกลับไปยังวิดเจ็ต. ทั้งสองใช้เพียงไม่กี่บรรทัด.
Blazor ให้โมเดลคอมโพเนนต์และลูปการเรนเดอร์ที่ไม่ค่อยสนใจ JavaScript ของบุคคลที่สาม. Doconut ทำงานร่วมกับสิ่งนั้นแทนที่จะขัดแย้ง: การเรนเดอร์เกิดขึ้นบนเซิร์ฟเวอร์ในกระบวนการของคุณเอง, และวิดเจ็ตจะเมานท์เข้าไปในองค์ประกอบธรรมดาที่คุณควบคุมผ่านวงจรชีวิต interop ปกติ.
ปัญหา
เส้นทางฝั่งไคลเอนต์หมายถึงการส่งเอ็นจินการเรนเดอร์เข้าไปในเบราว์เซอร์. ใน Blazor WebAssembly นั่นจะเพิ่มขนาดการดาวน์โหลดของคุณโดยตรง, และมันรองรับเฉพาะ PDF — ทันทีที่มีคนอัปโหลด DOCX หรือ XLSX คุณก็กลับไปสู่จุดเริ่มต้น.
เส้นทาง iframe-to-Office หมายถึงเอกสารของคุณต้องผ่านโครงสร้างพื้นฐานของคนอื่น, ซึ่งเป็นการสนทนากับทีมความปลอดภัยของคุณที่คุณอาจไม่ต้องการทำสองครั้ง.
Doconut ใช้เส้นทางที่สาม. ไฟล์จะถูกแปลงเป็นภาพหน้าโดยเซิร์ฟเวอร์ของคุณเอง, และ Blazor เพียงต้องโฮสต์ div. ต้นไม้คอมโพเนนต์ของคุณจะไม่ทำการเรนเดอร์ใหม่ของตัวดูที่ไม่ได้เป็นของคุณ, และเครื่องยนต์ diff ไม่มีอะไรให้ต่อสู้.
ความสามารถ
การเรนเดอร์เป็นแบบเซิร์ฟเวอร์ไม่ว่ากรณีใด. ใน Server การเรียกเป็นโดยตรง; ใน WebAssembly คุณเปิดเผยการเรียก open เป็น endpoint API ขั้นต่ำและส่ง token ที่คืนกลับไปยังวิดเจ็ต. ทั้งสองใช้เพียงไม่กี่บรรทัด.
เริ่มต้นวิดเจ็ตครั้งเดียว, หลังการเรนเดอร์ครั้งแรก, ผ่าน hook interop JS มาตรฐาน. เนื่องจาก Blazor ไม่เคยเป็นเจ้าของ DOM ภายในของตัวดู, การเรนเดอร์ต่อมาจะไม่กระทบต่อมัน.
Interactive Server, Interactive WebAssembly หรือ Auto. ตัวดูถูกควบคุมโดย token ที่ไม่เปิดเผยแทนสถานะคอมโพเนนต์, ดังนั้นการสลับโหมดการเรนเดอร์จะไม่เปลี่ยนการบูรณาการ.
คอมโพเนนต์เดียวกันเปิด PDF, DOCX, XLSX, PPTX, DWG, MSG และรายการอื่น ๆ ในแคตาล็อก. คุณเขียนหน้า viewer เพียงหน้าเดียว, ไม่ต้องแยกตามประเภทไฟล์.
UI การนำทางมาพร้อมกับวิดเจ็ต. คุณกำลังเชื่อมต่อ viewer, ไม่ได้สร้างจาก 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 คุณเพิ่ม endpoint หนึ่งที่เรียก OpenDocumentAsync และคืน token. ไคลเอนต์ไม่เคยแยกวิเคราะห์เอกสาร, ซึ่งเป็นเหตุผลที่ payload ของ WASM ไม่เปลี่ยนแปลง.
ไม่, หากคุณเมานท์ลงในองค์ประกอบที่ Blazor ถือเป็น leaf. เรนเดอร์ div ว่างและให้วิดเจ็ตเติมผ่าน interop — เครื่องยนต์ diff ไม่มีลูกเพื่อปรับให้ตรงกัน.
ไม่. หน้าหนึ่งจัดการทั้งแคตาล็อก. รูปแบบจะถูกตรวจจับจากเอกสารที่คุณเปิด, ไม่ได้เลือกโดยคุณล่วงหน้า.
ใบอนุญาตชั่วคราวใช้เวลาขอเพียงไม่กี่นาทีและทำงานทั้งหมดบนเครื่องของคุณเอง ไฟล์ที่สำคัญคือไฟล์ที่กำลังทำให้โปรแกรมดูของคุณปัจจุบันทำงานไม่ถูกต้องอยู่แล้ว.