স্কিপ করে মূল কন্টেন্ট এ যান

Iframe-ভিত্তিক রেন্ডারিং

পেজ রিলোড এড়াতে PHPRequestHandler-এর সব রেসপন্স একটি iframe-এর ভেতরে রেন্ডার করতে হয়। মনে রাখবেন, পুরো সেটআপটি ততক্ষণই টিকে থাকে, যতক্ষণ মূল index.html খোলা থাকে। তাই মূল অ্যাপটি যেন কোনোভাবেই রিলোড না হয়, সেটিই আমাদের লক্ষ্য।

ওপরের অ্যাপের উদাহরণে index.php নিচের HTML রেন্ডার করে:

<a href="page.php">Go to page.php</a>

ধরুন আমাদের index.html এটিকে একটি <iframe>-এর বদলে একটি <div>-এর ভেতরে রেন্ডার করল। ওই লিংকে ক্লিক করার সাথে সাথেই ব্রাউজার index.html থেকে page.php-তে যাওয়ার চেষ্টা করবে। কিন্তু পুরো PHP অ্যাপটি চলে index.html-এর ভেতরেই: Worker Thread, PHPRequestHandler, আর এগুলোকে Service Worker-এর সাথে জুড়ে রাখা ট্রাফিক কন্ট্রোল—সবকিছু। তাই এই পেজ ছেড়ে অন্য পেজে গেলেই পুরো অ্যাপটি বন্ধ হয়ে যাবে।

এবার একই লিংকসহ একটি iframe-এর কথা ভাবুন:

<iframe srcdoc='<a href="page.php">Go to page.php</a>'></iframe>

এবার ব্রাউজারে লিংকটিতে ক্লিক করলে page.php iframe-এর ভেতরে লোড হয়। টপ-লেভেলের index.html, যেখানে PHP অ্যাপ্লিকেশনটি চলে, সেটি একদম ঠিকঠাক থাকে। এ কারণেই @php-wasm/web সেটআপের জন্য iframe এত গুরুত্বপূর্ণ।

ক্র্যাশ রিপোর্ট

প্লেগ্রাউন্ড নিজে থেকে ক্র্যাশ রিপোর্ট নেয় না। বরং কোনো ইনস্ট্যান্স ব্রাউজারে চালু না হলে এটি ব্যবহারকারীকে একটি ক্র্যাশ রিপোর্ট পাঠাতে বলে।

রিপোর্টে একটি লগ, একটি বিবরণ আর একটি URL থাকে। পাঠানোর আগে ব্যবহারকারী চাইলে এটি এডিট করতে পারেন।

এরপর বাকি কাজ Logger API সামলায়। এই ছোট্ট REST API ডেটা ভ্যালিডেট করে সেটি Making WordPress-এর #playground-logs Slack চ্যানেলে পাঠিয়ে দেয়।

Iframe-এর কিছু ঝামেলা​

  • target="_top" এখনো হ্যান্ডেল করা হয় না, তাই target="_top" থাকা লিংকে ক্লিক করলে আপনি যে পেজে কাজ করছেন সেটি রিলোড হয়ে যাবে।
  • iframe থেকে আসা JavaScript পপআপ সবসময় নাও দেখা যেতে পারে।