การอัปเดตบางส่วนแบบประกาศ

Barry Pollard

Noam Rosenthal

เผยแพร่: 19 พฤษภาคม 2026

เว็บได้ก้าวข้ามจากสื่อแบบคงที่ที่ขับเคลื่อนด้วยเอกสารซึ่งเป็นจุดเริ่มต้นมานานแล้ว ทุกคนใช้เว็บแอปที่ทันสมัยและมีฟีเจอร์มากมายด้วยเหตุผลหลายประการ ตั้งแต่การสื่อสาร การซื้อ การรับชมข้อมูลอย่างละเอียด ไปจนถึงการจัดการชีวิตที่ซับซ้อน

แม้ว่า HTML จะมีความก้าวหน้ามากมาย แต่ก็ยังคงแสดงผลตามลำดับจากบนลงล่างโดยไม่คำนึงถึงเวลาที่เนื้อหาพร้อมหรือเวลาที่ผู้ใช้บริโภคเนื้อหา CSS ช่วยให้คุณเปลี่ยนลำดับเนื้อหาได้ แต่ก็มักจะส่งผลข้างเคียงต่อการช่วยเหลือพิเศษอย่างมาก JavaScript ช่วยให้คุณจัดการ DOM ผ่าน API ต่างๆ เพื่อหลุดพ้นจากข้อจำกัดนี้ได้บ้าง แต่ API เหล่านั้นมักต้องใช้ไวยากรณ์ที่ซับซ้อนหรือการสร้าง DOM Tree เพื่อเสียบเข้ากับ HTML

ประสิทธิภาพมีความสำคัญอย่างยิ่งต่อเว็บ เนื่องจากลักษณะไคลเอ็นต์-เซิร์ฟเวอร์ของสื่อ แต่บ่อยครั้งที่ผู้ใช้เลือกใช้ตัวเลือกที่ไม่เหมาะสมเพื่อหลีกเลี่ยงลักษณะการทำงานตามลำดับของ HTML ซึ่งจะทำให้ประสิทธิภาพช้าลง ซึ่งรวมถึงการรอจนกว่าหน้าเว็บทั้งหมดจะพร้อม หรือการใช้เฟรมเวิร์กที่มีขนาดใหญ่เพื่อแสดงคอมโพเนนต์แบบไม่พร้อมกัน ความนิยมของเฟรมเวิร์ก JavaScript แสดงให้เห็นว่านักพัฒนาเว็บชอบโมเดลที่อิงตามคอมโพเนนต์มากกว่าโมเดลเอกสารที่ยืดหยุ่นของต้นกำเนิดของเว็บ

ทีม Chrome ได้พิจารณาปัญหานี้และได้พัฒนาฟีเจอร์ใหม่ๆ เพิ่มเติมในแพลตฟอร์มเว็บภายใต้ชื่อ Declarative Partial Updates

API ชุดใหม่ 2 ชุดช่วยให้ส่ง HTML ได้ง่ายขึ้นในลักษณะที่ไม่เป็นเส้นตรง ไม่ว่าจะเป็นในเอกสาร HTML เองหรือผ่านวิธีที่ง่ายขึ้นในการแทรก HTML ลงในเอกสารที่มีอยู่แบบไดนามิกโดยใช้ JavaScript API ใหม่ ฟีเจอร์เหล่านี้พร้อมสำหรับการทดสอบของนักพัฒนาซอฟต์แวร์จาก Chrome 148 โดยใช้ Flag chrome://flags/#enable-experimental-web-platform-features นอกจากนี้ยังมี Polyfill ที่ช่วยให้คุณใช้ API ใหม่เหล่านี้ได้ทันที แม้ในเบราว์เซอร์ที่ยังไม่รองรับ

การเพิ่มฟีเจอร์เหล่านี้ลงในแพลตฟอร์มเว็บกำลังได้รับการปรับให้เป็นมาตรฐานโดยมีผลตอบรับเชิงบวกจากผู้ให้บริการเบราว์เซอร์รายอื่นๆ และช่องทางการปรับให้เป็นมาตรฐาน เรากำลังอัปเดตมาตรฐานที่เกี่ยวข้องให้รวม API ใหม่เหล่านี้

การสตรีมแบบไม่อยู่ในลำดับ

การเปลี่ยนแปลงชุดแรกคือ API การสตรีมแบบไม่อยู่ในลำดับใหม่ที่ใช้แท็ก <template> HTML และตัวยึดตำแหน่งคำสั่งการประมวลผล เช่น

<div>
  <?marker name="placeholder">
</div>

...

<template for="placeholder">
  Here is some <em>HTML content</em>!
</template>

วิธีการประมวลผลมีอยู่ใน XML มาเป็นเวลานานแล้ว แต่ได้รับการถือว่าเป็นความคิดเห็นใน HTML และถูกละเว้น API ใหม่นี้จะเปลี่ยนแปลงสิ่งดังกล่าวและนำวิธีการประมวลผลมาไว้ใน HTML เมื่อเบราว์เซอร์เห็น<?marker name="placeholder">วิธีการประมวลผล เบราว์เซอร์จะไม่ทำอะไรในทันทีเหมือนกับก่อนหน้านี้ แต่จะอ้างอิงได้ในภายหลัง

องค์ประกอบ <template> จะค้นหาคำสั่งในการประมวลผลที่เกี่ยวข้องซึ่งมีแอตทริบิวต์ name และแทนที่เนื้อหา ในกรณีนี้ หลังจากแยกวิเคราะห์แล้ว DOM จะมีลักษณะดังนี้

<div>
  Here is some <em>HTML content</em>!
</div>

นอกจากแอตทริบิวต์ <?marker> สำหรับการแทนที่แล้ว ยังมีเครื่องหมายช่วง <?start> และ <?end> ซึ่งอนุญาตให้แสดงเนื้อหาตัวยึดตำแหน่งชั่วคราวก่อนที่จะประมวลผลเทมเพลต

<div>
  <?start name="another-placeholder">
  Loading…
  <?end>
</div>

...

<template for="another-placeholder">
  Here is some <em>HTML content</em>!
</template>

ในกรณีนี้ Loading… จะแสดงจนกว่าจะเห็น <template> แล้วระบบจะแทนที่ด้วยเนื้อหาใหม่

นอกจากนี้ คุณยังใส่วิธีการประมวลผลในเทมเพลตเพื่อให้มีการอัปเดตหลายรายการได้ด้วย โดยทำดังนี้

<ul id="results">
  <?start name="results">
  Loading…
  <?end>
</ul>

...

<template for="results">
  <li>Result One</li>
  <?marker name="results">
</template>
...

<template for="results">
  <li>Result Two</li>
  <?marker name="results">
</template>
...

ซึ่งจะส่งผลให้เกิด HTML ต่อไปนี้หลังจากแยกวิเคราะห์แล้ว

<ul id="results">
  <li>Result One</li>
  <li>Result Two</li>
  <?marker name="results">
</ul>

โดยมีคำสั่งการประมวลผลสุดท้ายที่ท้ายเอกสารในกรณีที่มีการเพิ่ม <template for="results"> ลงในเอกสารในภายหลัง

สาธิต

ในวิดีโอนี้ เราจะใช้แอปพลิเคชันอัลบั้มรูปภาพพื้นฐานกับ HTML แบบสตรีมมิง

ทั้งสถานะและรูปภาพจะสตรีมลงใน HTML หลังจากเลย์เอาต์เริ่มต้น

กรณีการใช้งาน

มีกรณีการใช้งานมากมายสำหรับการแก้ไข HTML ที่ไม่เป็นไปตามลำดับนี้เมื่อใช้ร่วมกับ HTML สำหรับการสตรีม

• สถาปัตยกรรมแบบไอส์แลนด์ รูปแบบทั่วไปที่ได้รับความนิยมจากเฟรมเวิร์กอย่าง Astro คือสถาปัตยกรรมแบบไอส์แลนด์ ซึ่งคอมโพเนนต์จะได้รับการไฮเดรตแยกกันบน HTML แบบคงที่ <template for> API ช่วยให้จัดการเนื้อหาแบบคงที่ในลักษณะที่คล้ายกันได้โดยตรงใน HTML เฟรมเวิร์ก JavaScript ยังใช้สิ่งนี้เพื่อไอส์แลนด์ที่มีการโต้ตอบมากขึ้นหรือเพื่อจัดการคอมโพเนนต์ได้ด้วย
• ส่งเนื้อหาเมื่อพร้อม สถาปัตยกรรมแบบไอส์แลนด์นี้ช่วยให้สตรีมเนื้อหาได้เมื่อพร้อมแทนที่จะต้องรอเนื้อหาที่ต้องมีการประมวลผลเพิ่มเติม เช่น การค้นหาฐานข้อมูล แม้ว่าหลายแพลตฟอร์มจะอนุญาตให้สตรีม HTML แต่ลักษณะการทำงานตามลำดับของ HTML หมายความว่าเนื้อหามักจะถูกหน่วงไว้ หรือต้องใช้การจัดการ DOM ของ JavaScript ที่ซับซ้อน ตอนนี้คุณสามารถแสดงเนื้อหาแบบคงที่ในขณะที่รอ แล้วเสียบเนื้อหาที่มีราคาแพงกว่าไว้ที่ส่วนท้ายของสตรีม HTML
• ส่ง HTML ตามลำดับที่เหมาะสมเพื่อประสิทธิภาพการโหลดหน้าเว็บ และคุณยังเปลี่ยนลำดับได้แม้ว่าคำสั่งซื้อจะพร้อมจัดส่งแล้วก็ตาม ตัวอย่างเช่น เมกะเมนูเป็นฟีเจอร์การนำทางทั่วไปที่มี HTML จำนวนมากซึ่งผู้ใช้จะไม่เห็นจนกว่าหน้าเว็บจะโต้ตอบได้ สามารถส่ง HTML ขนาดใหญ่นี้ในภายหลังในเอกสาร HTML เพื่อจัดลําดับความสําคัญของ HTML ที่สําคัญกว่าซึ่งจําเป็นสําหรับการโหลดหน้าเว็บครั้งแรก HTML ทำให้ลำดับไม่ใช่ข้อจำกัดอีกต่อไป

นี่เป็นเพียง Use Case บางส่วน และเราตื่นเต้นที่จะได้เห็นว่านักพัฒนาแอปจะใช้ API ใหม่นี้เพื่ออะไร

ข้อจำกัดและความซับซ้อน

API มีข้อจำกัดและรายละเอียดเล็กๆ น้อยๆ บางอย่างที่ควรทราบ ดังนี้

• <template for> จะอัปเดตวิธีการประมวลผลได้ภายในองค์ประกอบระดับบนสุดเดียวกันเท่านั้นด้วยเหตุผลด้านความปลอดภัย การเพิ่ม <template for> ลงในองค์ประกอบ <body> โดยตรงจะทำให้องค์ประกอบดังกล่าวเข้าถึงทั้งเอกสาร (รวมถึง <head>) ได้
• <?end> คำสั่งการประมวลผลเป็นตัวเลือก และหากไม่มี ระบบจะแทนที่เนื้อหาระหว่างองค์ประกอบ <?start> กับจุดสิ้นสุดขององค์ประกอบที่บรรจุ
• การย้ายวิธีการประมวลผลหลังจากที่ <template for> เริ่มสตรีมแล้วอาจส่งผลที่ไม่คาดคิด โดยเนื้อหาใหม่จะยังคงสตรีมไปยังตำแหน่งเก่า
• โปรดทราบว่าเมื่อแทรก <template for> แบบไดนามิกด้วยวิธีต่างๆ เช่น setHTML หรือ innerHTML "องค์ประกอบหลัก" ของเทมเพลตเมื่อมีการแยกวิเคราะห์จะเป็นส่วนเอกสารชั่วคราว ซึ่งหมายความว่าการแทรก HTML โดยใช้วิธีการเหล่านี้จะไม่สามารถแก้ไข DOM ที่มีอยู่ได้ และการแก้ไขจะเกิดขึ้น "ในตำแหน่ง" ภายใน Fragment อย่างไรก็ตาม เมื่อสตรีมโดยใช้วิธีการต่างๆ เช่น streamHTMLUnsafe (ซึ่งเรากำลังจะกล่าวถึง) จะไม่มี Fragment ระหว่างกลาง ดังนั้นเทมเพลตจึงสามารถแทนที่เนื้อหาที่มีอยู่ได้

การเพิ่มในอนาคต

เรากำลังพิจารณาเพิ่มฟีเจอร์ต่อไปนี้ในอนาคต

• ฝั่งไคลเอ็นต์ประกอบด้วย เช่น <template for="footer" patchsrc="/partials/footer.html">
• การจัดกลุ่ม ฝั่งไคลเอ็นต์ คุณยังขยายการรวม Fragment เพื่อจัดการการจัดกลุ่มได้ด้วยเพื่อให้การอัปเดตหลายรายการเกิดขึ้นพร้อมกัน
• ป้องกันการเขียนทับเนื้อหาที่จะไม่มีการเปลี่ยนแปลง ซึ่งทำได้โดยใช้หมายเลขการแก้ไขเนื้อหาหรือการกำหนดเวอร์ชัน ซึ่งจะช่วยให้สถานะยังคงอยู่ระหว่างการเปลี่ยนเส้นทางหรือการอัปเดตอื่นๆ แทนที่จะรีเซ็ตเนื้อหา
• การล้างข้อมูลขณะแก้ไข เช่น <template for=icon safe><svg id="from-untrusted-source">...</svg></template>

Polyfill

ทีม Chrome ได้เปิดตัวtemplate-for-polyfillซึ่งพร้อมใช้งานใน npm เพื่อให้เว็บไซต์ใช้ฟังก์ชันใหม่นี้ได้ทันทีแม้ว่าฟังก์ชันนี้จะยังไม่พร้อมใช้งานในเบราว์เซอร์อื่นๆ

ข้อจำกัดบางอย่างเนื่องจากอัปเดตตัวแยกวิเคราะห์ HTML ของเบราว์เซอร์โดยตรงไม่ได้ แต่ครอบคลุมกรณีการใช้งานที่พบบ่อยที่สุด เว็บไซต์ยังคงควรทดสอบในเบราว์เซอร์อื่นๆ

วิธีการแทรก HTML และการสตรีมแบบใหม่

เนื้อหาบางอย่างอาจแสดงในรูปแบบ HTML ไม่ได้ ส่วนที่ 2 ของงานที่ Chrome กำลังทำในส่วนนี้เกี่ยวข้องกับการทำให้การอัปเดตเนื้อหาผ่าน JavaScript ง่ายขึ้น

ปัจจุบันมีหลายวิธีในการแทรก HTML ลงในเอกสารที่มีอยู่แบบไดนามิกโดยใช้ JavaScript ดังนี้

• setHTML
• setHTMLUnsafe
• innerHTML และ outerHTML
• createContextualFragment
• insertAdjacentHTML

อย่างไรก็ตาม ทั้งหมดนี้ทำงานแตกต่างกันเล็กน้อย โดยมีรายละเอียดและความแตกต่างที่นักพัฒนาแอปอาจไม่ได้พิจารณาเสมอไป

• เนื้อหาใหม่จะเขียนทับหรือต่อท้าย
• มีการล้าง HTML ที่อาจเป็นอันตรายโดยการหลีกเลี่ยงแท็ก <script> หรือไม่
• หากไม่ควร <script> ทำงานหรือไม่
• และทำงานร่วมกับ Trusted Types อย่างไร

นักพัฒนาแอปไม่กี่รายที่สามารถดู API เหล่านั้นและตอบคำถามเกี่ยวกับ API แต่ละรายการได้อย่างมั่นใจ

ข้อจำกัดที่สำคัญคือใช้ได้เฉพาะกับชุด HTML ที่สมบูรณ์ซึ่งทราบล่วงหน้าเท่านั้น เมื่อมีการเรียกใช้เพื่ออนุญาตให้สตรีม HTML ในทางปฏิบัติ นั่นหมายความว่าคุณต้องดาวน์โหลดเนื้อหาทั้งหมดก่อนแทรก เนื่องจากจุดแข็งอย่างหนึ่งของ HTML คือความสามารถในการสตรีมเนื้อหาได้ทันที คุณอาจหลีกเลี่ยงข้อจำกัดนี้ได้ในขอบเขตที่จำกัดโดยการแยกเพย์โหลดหรือใช้วิธีการที่ล้าสมัยและไม่แนะนำ เช่น document.write แต่ก็อาจทำให้เกิดปัญหาอื่นๆ ตามมา

ชุด API แบบคงที่และสตรีมมิงชุดใหม่

Chrome ได้เสนอชุด API ใหม่และส่วนขยายสำหรับ setHTML และ setHTMLUnsafe ที่มีอยู่เพื่อจัดการปัญหานี้ รวมถึงเปิดตัวฟังก์ชันการทำงานของการสตรีม

มีวิธีการตั้งค่าหรือแทนที่พร้อมกับวิธีการแทรกเนื้อหาก่อนหรือหลัง HTML ที่มีอยู่ แต่ละวิธีมีสตรีมที่เทียบเท่าดังนี้

นอกจากนี้ ยังมีเวอร์ชัน Unsafe ซึ่งเราจะกล่าวถึงในเร็วๆ นี้ แม้ว่าจะมีพร็อพเพอร์ตี้จำนวนมาก (โดยเฉพาะเมื่อคุณเพิ่มพร็อพเพอร์ตี้ที่เทียบเท่ากับ Unsafe) แต่รูปแบบการตั้งชื่อที่สอดคล้องกันจะช่วยให้เห็นได้ชัดเจนยิ่งขึ้นว่าแต่ละพร็อพเพอร์ตี้ทำอะไรได้บ้างเมื่อเทียบกับเมธอดที่ไม่เกี่ยวข้องที่กล่าวถึงก่อนหน้านี้

เวอร์ชันแบบคงที่จะใช้ HTML ใหม่เป็นอาร์กิวเมนต์สตริง DOM พร้อมกับตัวเลือกที่ไม่บังคับ ดังนี้

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTML(newHTML);

เวอร์ชันการสตรีมจะทำงานร่วมกับ Streams API เช่น getWriter()

const contentElement = document.querySelector('#content-to-update');
const writer = contentElement.streamHTMLUnsafe().getWriter();

// Example stream of updating content
while (true) {
 await writer.write(`<p>${++i}</p>`);
 await new Promise((resolve) => setTimeout(resolve, 1000));
}

writer.close();

หรือจะใช้การตอบกลับของ Fetch โดยใช้การเชื่อมต่อด้วยไปป์ก็ได้

const contentElement = document.querySelector('#content-to-update');

const response = await fetch('/api/content.html');

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTMLUnsafe());

นอกจากนี้ เรายังวางแผนที่จะเพิ่มวิธีการที่สะดวกซึ่งคุณจะสตรีมได้โดยตรงโดยไม่ต้องมีTextDecoderStream()ขั้นตอนกลาง

อาร์กิวเมนต์ options ช่วยให้คุณระบุ sanitizer ที่กำหนดเองได้ ซึ่งค่าเริ่มต้นคือ default หมายถึงการกำหนดค่า Sanitizer เริ่มต้น โดยมีวิธีใช้ดังนี้

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector('#content-to-update');

// Only allows basic formatting
const basicFormattingSanitzer = new Sanitizer({ elements: ["em", "i", "b", "strong"] });

contentElement.setHTML(newHTML, {sanitizer: basicFormattingSanitzer});

เมธอดที่ "ไม่ปลอดภัย"

นอกจากนี้ยังมี API แต่ละรายการในเวอร์ชัน "ไม่ปลอดภัย" ด้วย

เมธอด "ไม่ปลอดภัย" เหล่านี้จะปิดเครื่องมือล้างข้อมูลโดยค่าเริ่มต้น (คุณระบุเครื่องมือล้างข้อมูลที่กำหนดเองได้หากต้องการ) และยังอนุญาตให้เรียกใช้สคริปต์ด้วยตัวเลือก runScripts ที่ไม่บังคับ (ซึ่งค่าเริ่มต้นคือ false)

เช่น setHTML setHTMLUnsafe เป็นเมธอดที่มีอยู่แล้ว แต่ได้เพิ่มพารามิเตอร์ตัวเลือก runScripts ลงในเมธอดนี้เพื่อให้ใช้กับการเรียกใช้สคริปต์ได้

const newHTML = `<p>This is a new paragraph</p>
                 <script src=script.js></script>`;
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTMLUnsafe(newHTML, {runScripts: true});

คำว่า "ไม่ปลอดภัย" ในวิธีการนี้มีไว้เพื่อเตือนนักพัฒนาซอฟต์แวร์ถึงความเสี่ยงที่อาจเกิดขึ้นและวิธีที่นักพัฒนาซอฟต์แวร์อาจต้องการล้างข้อมูลหรือจำกัดสคริปต์ ไม่ได้หมายความว่าไม่ควรใช้วิธีการเหล่านี้

ระดับความ "ไม่ปลอดภัย" จะขึ้นอยู่กับความน่าเชื่อถือของอินพุต Unsafeเมธอดแบบคงที่ทั้งหมดจะใช้ได้กับทั้ง DOM String หรือ TrustedHTML เป็นอาร์กิวเมนต์ html และยังอนุญาตให้ใช้ Sanitizer ได้ด้วย แม้ว่า runScript จะมีจุดประสงค์ทั้งหมดเพื่ออนุญาตสคริปต์ จึงเป็นเหตุผลที่ไม่มีการใช้โปรแกรมล้างข้อมูลโดยค่าเริ่มต้น

กรณีการใช้งาน

API ใหม่เหล่านี้ช่วยให้นักพัฒนาแอปเพิ่ม HTML ลงในหน้าเว็บที่มีอยู่ได้ง่ายขึ้น โดยการเพิ่ม API ใหม่ที่มีชื่อและตัวเลือกที่สอดคล้องกัน API การสตรีมช่วยให้ได้รับประโยชน์ด้านประสิทธิภาพโดยไม่ต้องรอจนกว่าเนื้อหาใหม่ทั้งหมดจะพร้อมใช้งานบนแพลตฟอร์ม

ตัวอย่างกรณีการใช้งานมีดังนี้

• การสตรีมแบบไดนามิกของการอัปเดตเนื้อหาขนาดใหญ่ในแอปหน้าเว็บเดียว ดังที่ได้กล่าวไปก่อนหน้านี้ ข้อเสียที่สำคัญของ SPA ในปัจจุบันคือไม่สามารถใช้ประโยชน์จากลักษณะการสตรีมของการโหลด HTML เริ่มต้นได้ แต่ตอนนี้ทำได้แล้ว
• การแทรกเนื้อหาทั่วไป เช่น ส่วนท้ายของ HTML การใช้ JavaScript API ช่วยให้คุณดึงข้อมูลบางส่วนและแทรกลงในหน้าเว็บได้ ซึ่งจะได้รับประโยชน์จากการแคชแทนที่จะต้องทำซ้ำในทุกหน้าเว็บที่ส่ง อย่างไรก็ตาม เนื่องจากต้องใช้ JavaScript ในการเรียกใช้ จึงควรใช้วิธีนี้กับเนื้อหาที่จะไม่แสดงในการโหลดครั้งแรกเท่านั้น

อีกครั้งว่านี่เป็นเพียงตัวอย่างบางส่วนเท่านั้น และเราก็ตื่นเต้นที่จะได้เห็นผลงานของคุณ

ข้อจำกัดและความซับซ้อน

นอกจากนี้ API ใหม่เหล่านี้ยังมีข้อจำกัดและรายละเอียดบางอย่างที่ควรทราบด้วย

• การผสานรวมการสตรีมกับ Trusted Types API ต้องใช้createParserOptionsเมธอดใหม่ซึ่งช่วยให้แทรกตัวกรองไปยังการดำเนินการตั้งค่า HTML ใดก็ได้ ดูคำอธิบายเพื่อดูรายละเอียดเพิ่มเติมเกี่ยวกับการผสานรวมประเภทที่เชื่อถือได้
• เช่นเดียวกับ<template for>การย้ายองค์ประกอบที่กำลังสตรีม อาจทำให้เกิดผลลัพธ์ที่ไม่คาดคิดหรือข้อผิดพลาดในการสตรีม
• streamHTMLUnsafe ทำงานคล้ายกับตัวแยกวิเคราะห์หลักในหลายๆ ด้าน รวมถึงการประมวลผลคำสั่ง <template for> เมื่อมีการเพิ่มลงในเอกสารหลัก และการเลื่อนสคริปต์ defer จนกว่าจะสิ้นสุดสตรีม

Polyfill

ทีม Chrome ได้เปิดตัวhtml-setters-polyfillซึ่งพร้อมใช้งานใน npm เพื่อให้เว็บไซต์ใช้ฟังก์ชันใหม่นี้ได้ทันทีแม้ว่าฟังก์ชันนี้จะยังไม่พร้อมใช้งานในเบราว์เซอร์อื่นๆ

โปรดทราบว่า Polyfill นี้ไม่ได้สตรีม แต่จะบัฟเฟอร์และใช้เมื่อเสร็จสมบูรณ์ ซึ่งเป็น Polyfill สำหรับรูปร่างของ API มากกว่าฟังก์ชันการทำงาน

นอกจากนี้ การตั้งค่าเนื้อหาที่ปลอดภัยยังขึ้นอยู่กับ setHTML และ Sanitizer API ซึ่งไม่รองรับใน Safari

ใช้ทั้ง 2 อย่างร่วมกัน

แม้ว่าจะเป็น API 2 รายการแยกกัน แต่ประสิทธิภาพที่แท้จริงจะมาจากการรวม API ทั้ง 2 รายการนี้ การสตรีมองค์ประกอบ <template for> ใหม่ลงใน HTML ช่วยให้คุณอัปเดตเนื้อหาส่วนต่างๆ แบบไดนามิกได้โดยไม่ต้องกำหนดเป้าหมายแต่ละส่วนโดยตรงด้วยการอ้างอิง JavaScript แยกต่างหากไปยัง DOM

คุณสามารถใช้การโหลดหน้าเว็บสไตล์ SPA ขั้นพื้นฐานได้โดยการโหลดหน้าโครงร่างพร้อมวิธีการประมวลผล จากนั้นสตรีมเทมเพลตของแต่ละหน้าใหม่ลงในส่วนล่างของ HTML เพื่อให้สอดคล้องกับวิธีการประมวลผลเหล่านั้น

แน่นอนว่า API ทั้ง 2 รายการนี้ยังมีศักยภาพและกรณีการใช้งานอีกมาก ดังนั้นอย่าปล่อยให้จินตนาการ (ที่จำกัด) ของเรามาฉุดรั้งคุณไว้ การทำให้การอัปเดตบางส่วนจัดการได้ง่ายขึ้นจะช่วยลดโค้ด Boilerplate บางส่วน ทำให้การอัปเดตง่ายขึ้น และปลดล็อกศักยภาพใหม่ๆ สำหรับเว็บ