HTML میں اعلانیہ جزوی اپ ڈیٹس کیسے کام کرتی ہیں۔

ایچ ٹی ایم ایل نے ہمیشہ اسٹریمنگ کی حمایت کی ہے۔ سرور کو براؤزر کو بھیجنے سے پہلے پورے صفحے کو میموری میں بنانے کی ضرورت نہیں ہے۔ آپ پہلے ابتدائی HTML بھیج سکتے ہیں، پھر مزید ٹکڑے بھیج سکتے ہیں کیونکہ ہر ایک حصہ تیار ہے۔ براؤزر ان حصوں کو پارس کرتا ہے اور صفحات کو ترتیب سے دکھاتا ہے۔ ایچ ٹی ایم ایل کے تیز نظر آنے کی ایک وجہ یہ ہے۔

تاہم، روایتی HTML سٹریمنگ کے سخت اصول ہیں۔ HTML دستاویز کی ترتیب میں آتا ہے۔ اگر براؤزر کو پہلے ہیڈر، پھر سائڈبار، اور آخر میں مرکزی مواد ملتا ہے، تو یہ ان حصوں کو اس ترتیب میں پارس کر دے گا۔ اگر ایک سست ڈیٹا بیس استفسار ابتدائی طور پر کسی صفحے کے ایک حصے کو روکتا ہے، تو اگلے حصے کو اکثر سرور کے تیار ہونے کا انتظار کرنا پڑتا ہے۔

جاوا اسکرپٹ کے فریم ورک برسوں سے اس مسئلے کو حل کر رہے ہیں۔ سرور رینڈرنگ فریم ورک شیلز، سٹاپنگ باؤنڈری، لوڈنگ سٹیٹس، اور دیر سے مواد کی سٹریمنگ کو ہینڈل کرتا ہے۔ کچھ فریم ورک موجودہ DOM کو پیچ کرنے کے لیے ان لائن اسکرپٹس کا استعمال کرتے ہیں۔ ایچ ٹی ایم ایکس جیسی لائبریریاں ڈویلپرز کو سرور سے تیار کردہ HTML کے ساتھ صفحہ کے کچھ حصوں کو اپ ڈیٹ کرنے کی اجازت دیتی ہیں۔

تاہم، ان حلوں کے لیے کہیں جاوا اسکرپٹ کی ضرورت ہوتی ہے۔ اعلانیہ جزوی اپ ڈیٹس مختلف سوالات اٹھاتے ہیں۔ کیا ہوگا اگر HTML کے پاس چیزوں کے اظہار کا اپنا طریقہ ہو؟

جب ایسی کوئی چیز آتی ہے تو کیا آپ اسے وہاں رکھتے ہیں؟

کروم کے اعلانیہ جزوی اپ ڈیٹ کی تجویز کے پیچھے یہی خیال ہے۔

اس مضمون میں، آپ اس مسئلے کے بارے میں جانیں گے جسے اعلانیہ جزوی اپ ڈیٹس حل کرنے کی کوشش کر رہے ہیں، مجوزہ پلیس ہولڈر نحو کیسے کام کرتا ہے، کس طرح آؤٹ آف آرڈر ایچ ٹی ایم ایل اسٹریمنگ ریگولر اسٹریمنگ سے مختلف ہے، متعلقہ JavaScript HTML انجیکشن API کا اطلاق کیسے ہوتا ہے، اور اسے کیوں براؤزرز میں پروڈکشن HTML کے بجائے تجرباتی خصوصیت سمجھا جانا چاہیے۔

انڈیکس

جن مسائل کو ہم اعلانیہ جزوی اپ ڈیٹس کے ساتھ حل کرنے کی کوشش کر رہے ہیں۔

اپنے پروڈکٹ کے صفحات پر غور کریں۔ سرور کو صفحہ کا عنوان، نیویگیشن، فوٹر، اور پروڈکٹ کی تفصیلات پہلے سے ہی معلوم ہے۔ تاہم، سفارشات کے سیکشن میں سست ڈیٹا بیس سوالات کی ضرورت ہوتی ہے۔ روایتی سرور سے پیش کردہ HTML کے لیے دو عام اختیارات ہیں:

• پہلے سرور ہر چیز کے تیار ہونے کا انتظار کرتا ہے اور پھر مکمل HTML جواب بھیجتا ہے۔ یہ کوڈ کو آسان رکھتا ہے، لیکن صارفین کسی بھی مفید چیز کو دیکھنے سے پہلے طویل انتظار کرتے ہیں۔

• دوسرا، سرور HTML کو مراحل میں چلاتا ہے۔ پہلے صفحہ کا اوپری حصہ بھیجیں، پھر جب آپ تیار ہوں تو باقی بھیج دیں۔ ایسا لگتا ہے کہ اس سے کارکردگی بہتر ہوتی ہے کیونکہ براؤزر پورا جواب مکمل ہونے سے پہلے رینڈرنگ شروع کر دیتا ہے۔

لیکن تنہا اسٹریمنگ اس مسئلے کو مکمل طور پر حل نہیں کرتی ہے۔ براؤزر اب بھی HTML کو ترتیب وار تجزیہ کرتے ہیں۔ اگر آپ کے پاس اپنی دستاویز کے آغاز میں ایک سست ریفرل بلاک ہے، تو اس بلاک کے بعد کا مواد اس وقت تک انتظار کرے گا جب تک کہ آپ دستاویز کو دوبارہ ترتیب نہیں دیتے، JavaScript شامل نہیں کرتے، یا فریم ورک خلاصہ استعمال نہیں کرتے۔

WICG پیچ کی تفصیل روایتی HTML سٹریمنگ کی دو حدود کو بیان کرتی ہے:

1. HTML مواد کو DOM ترتیب میں نشر کیا جاتا ہے۔

2. ابتدائی دستاویز پارس کرنے کے مرحلے کے بعد، سلسلہ بندی پہلے کی طرح فعال نہیں رہی۔

اعلانیہ جزوی اپ ڈیٹس پہلی حد کو نرم کرنے کی کوشش کرتے ہیں۔ یہ سرور کو پہلے پلیس ہولڈر بھیجنے اور پھر جواب میں اصل مواد بھیجنے کی اجازت دیتا ہے۔ براؤزر اگلے مواد کو پچھلے پلیس ہولڈر پر لاگو کرتا ہے۔ اس پیچ کو حسب ضرورت کلائنٹ سائڈ DOM پیچ کوڈ کی ضرورت نہیں ہے۔

اوپر دیے گئے خاکے میں، سرور ترتیب سے HTML ٹکڑوں کو بھیجتا ہے۔ براؤزر جواب کے اختتام سے پہلے ابتدائی حصہ رینڈر کر سکتا ہے، لیکن جس ترتیب میں اسے رینڈر کیا گیا ہے وہ اب بھی جواب کی ترتیب پر عمل کرے گا۔

روایتی HTML سٹریمنگ کیسے کام کرتی ہے۔

کسی تجویز کا مطالعہ کرنے سے پہلے، آپ کو اس کی بنیادی ساخت کو سمجھنے کی ضرورت ہے۔ سرور HTTP رسپانس باڈی بھیجتا ہے۔ جسم HTML پر مشتمل ہے۔ براؤزر آتے ہی جواب پڑھتا ہے۔ پہلے ٹیگ کو پارس کرنے کے لیے پورے رسپانس باڈی کا انتظار کرنے کی ضرورت نہیں ہے۔

یہاں ایک چھوٹی Node.js مثال ہے:

import http from "node:http";

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

const server = http.createServer(async (req, res) => {
    res.writeHead(200, {
        "Content-Type": "text/html; charset=utf-8",
    });

    res.write(`
    
    
      
        
      
      
        
        
This part arrives first.
  `);

    await sleep(2000);

    res.write(`
        
This part arrives after two seconds.
  `);

    await sleep(2000);

    res.end(`
        
This part arrives after four seconds.
      
    
  `);
});

server.listen(3000, () => {
    console.log("Server running at http://localhost:3000");
});

اس مثال میں، ہم ایک چھوٹا HTTP سرور بنانے کے لیے نوڈ کی بلٹ ان خصوصیات کا استعمال کریں گے۔ http ماڈیول جب آپ کسی صفحہ پر جاتے ہیں تو سرور تین الگ الگ HTML حصوں میں جواب بھیجتا ہے۔

پہلے res.write() فوری طور پر دستاویز کا شیل، عنوان، اور پہلا پیراگراف بھیجیں۔ پھر sleep(2000) اگلے سرور سے پہلے سرور کو 2 سیکنڈ کے لیے روک دیں۔ res.write() دوسرا پیراگراف بھیجیں۔ ایک اور توقف کے بعد، res.end() آخری پیراگراف بھیجیں اور HTML دستاویز کو بند کریں۔

براؤزر پورے جواب کے مکمل ہونے سے پہلے پہلا حصہ پیش کرنا شروع کر دیتا ہے، پھر مزید HTML آنے کے بعد بعد کے پیراگراف شامل کرتا ہے۔

اس سے ظاہر ہوتا ہے کہ سادہ ایچ ٹی ایم ایل سٹریمنگ کام کرتی ہے، لیکن مواد اسی ترتیب سے ظاہر ہوتا ہے جو سرور اسے بھیجتا ہے۔

اب اس صفحہ کو اپنے براؤزر میں کھولیں۔

http://localhost:3000

پورے جواب کے مکمل ہونے سے پہلے صفحہ کا پہلا حصہ ظاہر ہوتا ہے۔ جیسا کہ سرور مزید ٹکڑوں کو بھیجتا ہے، براؤزر لوڈ ہوتا رہتا ہے۔

یہ رویہ پرانا اور فعال ہے۔ لیکن اس کی ساخت پر توجہ دینا. سرور پہلا پیراگراف، پھر دوسرا پیراگراف، اور پھر تیسرا پیراگراف لکھتا ہے۔ براؤزر انہیں اسی ترتیب میں وصول کرتا ہے۔ یہ انہیں اسی ترتیب میں DOM میں بھی رکھتا ہے۔

روایتی سلسلہ بندی آپ کو پہلے پرانا مواد بھیجنے کی اجازت دیتی ہے۔ لیکن یہ یہ کہنے کا کوئی مقامی طریقہ فراہم نہیں کرتا ہے کہ یہ اگلا حصہ پچھلے پلیس ہولڈر کے اندر ہوگا۔ اعلانیہ جزوی اپ ڈیٹس گمشدہ حصوں کو نشانہ بناتے ہیں۔

کیوں فریم ورک پہلے ہی اس مسئلے کو حل کرتے ہیں۔

جدید فریم ورک پہلے سے ہی ایک ایسا ماحول بنا رہے ہیں جہاں صفحہ کے کچھ حصے تیار ہونے کے بعد پیش کیے جاتے ہیں۔ ری ایکٹ سرور کے اجزاء اور سسپنس پر مبنی سرور رینڈرنگ عام مثالیں ہیں۔ فریم ورک پہلے شیل بھیج سکتا ہے، متبادل ڈسپلے کر سکتا ہے، اور پھر بعد میں پورے مواد کو سٹریم کر سکتا ہے۔

تاہم، براؤزر ری ایکٹ کی حدود کو مقامی HTML کے طور پر نہیں سمجھتے ہیں۔ فریم ورک کو اپنا پروٹوکول انکوڈ کرنا چاہیے۔ WICG پیچ کی تفصیل کے مطابق، React ان لائننگ کا استعمال کرتا ہے۔ { const response = await fetch("/comments-stream") response.body .pipeThrough(new TextDecoderStream()) .pipeTo(comments.streamHTMLUnsafe()) }) ]]>

`);
}

server.listen(3000, () => {
console.log("Server running at http://localhost:3000");
});


یہ فائل ایک بنیادی ڈیمو سرور بناتی ہے۔ نوڈ کی ہمت حاصل کریں۔ http ایک ماڈیول کی وضاحت کریں اور پھر ایک چھوٹا شامل کریں۔ sleep() موخر سٹریمنگ کے لیے ایک مددگار بنائیں اور پھر تین منصوبہ بند راستوں کے ساتھ ایک HTTP سرور بنائیں۔

اگر درخواست کا URL مماثل ہے۔ /normal-stream، /partial-updates-demoیا /stream-html-api-demoسرور درخواست کو مناسب فنکشن میں بھیج دیتا ہے۔ جب کوئی صارف روٹ پیج پر جاتا ہے تو سرور ایک سادہ HTML صفحہ لوٹاتا ہے جس میں تین ڈیمو کے لنکس ہوتے ہیں۔

آخر کار server.listen(3000) پورٹ پر سرور شروع کریں۔ 3000آپ اپنے براؤزر میں ڈیمو کھول سکتے ہیں۔ http://localhost:3000.

سرور چلائیں:

npm run dev

پھر اسے اپنے براؤزر میں کھولیں۔

http://localhost:3000

اب تین ڈیمو ہیں:

جنرل اسٹریمنگ پاتھ ٹیسٹ

یہ راستہ کھولیں:

http://localhost:3000/normal-stream

اپنے براؤزر پر ایک نظر ڈالیں۔

• پہلا پیراگراف جلد ظاہر ہوتا ہے۔

• دوسرا پیراگراف بعد میں ظاہر ہوتا ہے۔

• تیسرا پیراگراف آخری نظر آتا ہے۔

یہ مفید ہے، لیکن یہ اب بھی ترتیب سے باہر ہے۔ براؤزر اسی ترتیب میں پیش کرتا ہے جو سرور بھیجتا ہے۔

اعلانیہ جزوی اپ ڈیٹ پاتھ ٹیسٹنگ

یہ راستہ کھولیں:

http://localhost:3000/partial-updates-demo

تجرباتی خصوصیت کو سپورٹ کرنے والے براؤزرز میں، صفحہ ابتدائی طور پر تین لوڈنگ ایریاز دکھائے گا۔

• پروفائل ایریا 1 سیکنڈ میں اپ ڈیٹ ہو جائے گا۔

• اطلاع کا علاقہ ایک لمحے میں اپ ڈیٹ ہو جائے گا۔

• مزید 2 سیکنڈ کے بعد، نمایاں جگہ کو اپ ڈیٹ کر دیا جائے گا۔

آرڈر نوٹ کریں۔ دستاویز میں اطلاعات سے پہلے سفارشات کا سیکشن ظاہر ہوتا ہے۔ تاہم، سرور سفارشی ٹیمپلیٹس سے پہلے نوٹیفکیشن ٹیمپلیٹس بھیجتا ہے۔

یہی بات ہے۔ دستاویز کا ڈھانچہ اور اسٹریمنگ آرڈر اب ایک جیسا ہونے کی ضرورت نہیں ہے۔ براؤزر for ہر ایک وصف