صندوق رمل الويب: كيف تعمل ساحات لعب HTML وCSS وJS

في جملة واحدة

ساحة لعب الويب هي بيئة تفاعلية داخل المتصفح تسمح لك بكتابة أكواد HTML و CSS و JavaScript ورؤية صفحة الويب الناتجة تُعرض في الوقت الفعلي، كل ذلك بدون الحاجة لإعداد أي ملفات محلية.

المشكلة التي تحلها

هل تتذكر الأيام الخوالي لبدء مشروع ويب؟ كنت تنشئ مجلدًا جديدًا، تفتح محرر الأكواد، وتنشئ بجد واجتهاد ملفات index.html وstyles.css وscript.js. ثم تربطها بعناية باستخدام وسوم <link> و<script>. تقوم بتغيير في ملف CSS، تحفظ. تضغط Alt-tab للانتقال إلى المتصفح، ثم F5 للتحديث. تعدل في JavaScript، تحفظ. تضغط Alt-tab، تحدّث. وتكرر هذه العملية إلى ما لا نهاية.

هذا الروتين، رغم كونه أساسيًا، يفرض ما يمكن تسميته "ضريبة الإعداد". إنه قدر ضئيل ولكنه ملحوظ من العناء. بالنسبة لمطور متمرس، هي حركة لا إرادية. أما بالنسبة لمبتدئ، فهي طقوس محبطة من التساؤل "هل ربطت الملفات بشكل صحيح؟" حتى قبل أن يتمكن من كتابة أول <h1> له. ولأي شخص يرغب فقط في اختبار جزء صغير من الكود — "كيف تعمل خاصية gap في Flexbox مرة أخرى؟" — تصبح هذه المراسم بأكملها مبالغًا فيها. يشبه الأمر أن ترغب في الرسم على منديل ولكنك تُجبَر أولاً على تجهيز لوحة قماشية عملاقة.

هذه هي المشكلة التي وُلدت ساحات لعب الويب لحلها. أدرك الرواد الأوائل مثل JSFiddle و JSBin (ولاحقًا CodePen) هذا العناء وطرحوا سؤالًا بسيطًا: ماذا لو استطعنا وضع المحرر والمتصفح جنبًا إلى جنب وجعلهما يتحدثان فورًا؟

لقد قضوا على ضريبة الإعداد وتكلفة التنقل بين السياقات. لا مزيد من إنشاء الملفات، لا مزيد من ربطها، ولا مزيد من التنقل بين النوافذ والتحديث. أنت تكتب الكود، وأنت ترى النتائج. هذا غيّر طريقة تعلم الناس، ونمذجة الأفكار، ومشاركة أكواد الواجهة الأمامية. لقد أوجد وسيطًا "حيًا" لتطوير الويب، مما جعله أكثر فورية وتجريبية، وبصراحة، أكثر متعة.

كيف تعمل من الداخل

تبدو ساحة اللعب كالسحر، لكنها مجرد تطبيق ذكي لميزات المتصفح القياسية. الأمر ليس "شعوذة" بقدر ما هو "هندسة عبقرية". دعنا نُزِح الستار.

### سحر <iframe>

أهم عنصر في ساحة لعب الويب هو عنصر <iframe>. المعاينة الحية التي تراها ليست مجرد <div> على الصفحة؛ بل هي مستند HTML كامل ومنفصل يعيش داخل <iframe>.

لماذا؟ العزل. هذا هو الجزء المتعلق بـ "صندوق الرمل" في التشبيه. من خلال عرض الكود الخاص بك داخل iframe، تحمي أداة ساحة اللعب نفسها من الكود الخاص بك، وتحمي الكود الخاص بك من نفسها.

• أنماط CSS لا تتسرب: لن تؤثر أنماط CSS الخاصة بأزرار وصناديق نصوص ساحة اللعب عن طريق الخطأ على صفحة الويب التي تعاينها. الكود الخاص بك body { background: hotpink; } لن يحول الأداة بأكملها إلى اللون الوردي.
• متغيرات JavaScript لا تتضارب: المتغير const user = 'admin'; الخاص بك لن يتعارض مع متغير user قد تستخدمه منطق تطبيق ساحة اللعب نفسه.
• إنها صفحة بيضاء: يوفر الـ iframe بيئة متصفح جديدة ونظيفة، تمامًا مثل فتح علامة تبويب جديدة، وهو بالضبط ما تريده لاختبار يمكن التنبؤ بنتائجه.

### تجميع المستند بشكل فوري

عندما تكتب الكود في المربعات الثلاثة المنفصلة (HTML, CSS, JS)، لا تقوم ساحة اللعب بحفظ ثلاثة ملفات منفصلة. بدلاً من ذلك، يلتقط منطق JavaScript الخاص بها النص من كل مربع ويقوم بتجميعها معًا في سلسلة نصية واحدة تمثل مستند HTML كامل.

// نظرة مبسطة على ما يفعله سكربت ساحة اللعب
const userHtml = getCodeFromHtmlBox(); // مثلًا: "<h1>Hello!</h1>"
const userCss = getCodeFromCssBox();   // مثلًا: "h1 { color: blue; }"
const userJs = getCodeFromJsBox();     // مثلًا: "console.log('Page loaded!');"

const finalDocumentString = `
  <!DOCTYPE html>
  <html>
    <head>
      <style>
        ${userCss}
      </style>
    </head>
    <body>
      ${userHtml}
      <script>
        ${userJs}
      <\/script>
    </body>
  </html>
`;

هذه السلسلة النصية هي مستند HTML صالح ومكتفٍ ذاتيًا، وجاهز للعرض. السؤال التالي هو، كيف تضعه داخل <iframe>؟

### تحميل <iframe> باستخدام srcdoc

الطريقة الحديثة والآمنة والأنيقة لتحميل هذا المحتوى هي باستخدام خاصية srcdoc في <iframe>.

<!-- قد يحتوي ملف HTML الخاص بساحة اللعب على هذا -->
<iframe id="preview-frame"></iframe>

وسيقوم JavaScript بالتالي:

const iframe = document.getElementById('preview-frame');
// 'finalDocumentString' هي السلسلة النصية الكبيرة التي أنشأناها في الخطوة السابقة
iframe.srcdoc = finalDocumentString;

تخبر خاصية srcdoc المتصفح: "مهلاً، لا تذهب لجلب URL لمحتوى هذا الـ iframe. أنا أعطيك مستند HTML بأكمله هنا في هذه السلسلة النصية." هذه الطريقة فعالة بشكل لا يصدق. بمجرد تحديث خاصية srcdoc، يعيد الـ iframe عرض نفسه فورًا بالمحتوى الجديد. هذا هو سر ميزة "التحديث المباشر".

### التقاط console.log

إذًا، إذا كان الكود الخاص بك يعمل في iframe منفصل تمامًا ومعزول في صندوق رمل، كيف يظهر ناتج console.log('Hello!') في واجهة الـ console المخصصة لساحة اللعب؟

هذه خدعة فنية جميلة. قبل تحميل الكود الخاص بك، تقوم ساحة اللعب بحقن سكربت صغير خاص بها في الـ iframe. هذا السكربت "يعيد تعريف" وظيفة console.log الافتراضية.

إليك نسخة مفاهيمية من السكربت المحقون:

// يتم إضافة هذا الكود برمجيًا إلى <head> الخاص بالـ iframe
const originalConsoleLog = console.log;
const originalConsoleError = console.error;

// اختطاف وظيفة 'log'
console.log = (...args) => {
  // أرسل البيانات المسجلة إلى النافذة الأم (واجهة ساحة اللعب)
  window.parent.postMessage({
    type: 'console',
    level: 'log',
    data: args
  }, '*'); // في بيئة الإنتاج، ستكون '*' أصلًا محددًا للأمان

  // ما زلنا نستدعي الوظيفة الأصلية حتى تظهر أيضًا في أدوات المطور الحقيقية للمتصفح!
  originalConsoleLog.apply(console, args);
};

// ... ونفعل الشيء نفسه مع console.error و console.warn، إلخ.

تحتوي الصفحة الأم (أداة ساحة اللعب) على مستمع ينتظر هذه الرسائل. عندما تتلقى رسالة من نوع console، تأخذ البيانات وتعرضها في واجهة الـ console الخاصة بها. يشبه الأمر إعداد رسول سري بين الـ iframe والنافذة الأم.

قصص من الواقع

### إعادة إنتاج الأخطاء بسرعة

سارة، مهندسة أولى، تتلقى تقرير خطأ: "زر الدفع غير محاذى بشكل صحيح على Firefox". المشروع ضخم. يستغرق تشغيل الخادم المحلي دقيقتين. بدلاً من ذلك، تقوم بفحص العنصر في بيئة الإنتاج، وتنسخ HTML الزر وCSS ذات الصلة من أدوات المطور في المتصفح، وتلصقها في ساحة لعب ويب. تضيف القليل من JS لمحاكاة حالة الزر. في أقل من 90 ثانية، أعادت إنتاج الخطأ في بيئة نظيفة ومعزولة. تعدل خاصية CSS واحدة، تصلح المشكلة، وترسل رابط ساحة اللعب إلى مطور مبتدئ مع ملاحظة: "هذا هو الإصلاح. يرجى دمجه في الكود الأساسي."

• الدرس: ساحات اللعب لا مثيل لها في عزل وإعادة إنتاج أخطاء الواجهة الأمامية، مما يوفر كميات هائلة من وقت الإعداد.

### نموذج "هل هذا يعمل أصلًا؟"

أليكس مصمم يكتب الكود. لقد قرأ للتو عن الرسوم المتحركة المدفوعة بالتمرير في CSS ويريد أن يرى كل هذه الضجة. بدلاً من تلويث مشروع أو بدء مشروع جديد، يفتح ساحة لعب. ينشئ حاوية قابلة للتمرير وبضعة عناصر، ثم يبدأ في تجربة صيغة @scroll-timeline. أثناء كتابته، يمكنه أن يرى على الفور كيف تتفاعل الرسوم المتحركة مع تمريره. يمكنه اختبار دوال التخفيف المختلفة والإطارات الرئيسية في ثوانٍ. في غضون عشر دقائق، لديه فهم قوي للميزة الجديدة ونموذج أولي عامل لعرضه على فريقه.

• الدرس: ساحات اللعب هي المختبر الأمثل قليل المخاطر لتعلم تقنيات الويب الجديدة والتحقق من صحة الأفكار التجريبية.

### المقابلة التعاونية

ماريا تجري مقابلة فنية عن بعد. تحتاج إلى تقييم قدرة المرشح على بناء مكون واجهة مستخدم صغير من الصفر. بدلاً من أن تطلب منه مشاركة شاشته والتلعثم مع محرره المحلي، ترسل له رابطًا إلى ساحة لعب تعاونية. يمكن لكل من ماريا والمرشح رؤية وتحرير الكود في الوقت الفعلي. تطلب من المرشح بناء واجهة بسيطة ذات علامات تبويب. بينما يكتب المرشح HTML و CSS و JS، يمكن لماريا رؤية عملية تفكيره مباشرة، وتقديم تلميحات وطرح أسئلة على طول الطريق.

• الدرس: أصبحت ساحات اللعب الحية معيارًا للمقابلات التقنية والبرمجة التعاونية، حيث توفر سياقًا مشتركًا أكثر فعالية من مجرد مشاركة الشاشة.

أخطاء وفخاخ شائعة

• نسيان صندوق رمل الـ iframe: قد تحاول الوصول إلى متغير JavaScript أو ملف تعريف ارتباط (cookie) من النافذة الرئيسية وتتساءل لماذا هو undefined. تذكر: الـ iframe هو مستند منفصل تمامًا. هذا العزل ميزة، وليس خطأ.
• استخدام مسارات أصول نسبية: كتابة <img src="/images/logo.png"> ستؤدي إلى صورة معطوبة. ساحة اللعب ليس لديها أي مفهوم لهيكل ملفات مشروعك المحلي. يجب عليك استخدام عناوين URL كاملة ومطلقة لأي أصول خارجية مثل الصور أو الخطوط أو المكتبات (على سبيل المثال، من CDN مثل unpkg أو cdnjs).
• كتابة كود من جانب الخادم: محاولة تضمين وسوم PHP <?php ... ?> أو استدعاءات Node.js require('fs') لن تعمل. ساحة اللعب تنفذ الكود في متصفحك (من جانب العميل). إنها ليست خادمًا ولا يمكنها تشغيل لغات من جانب الخادم.
• التعامل معها كاستضافة إنتاجية: ساحات اللعب مخصصة للتطوير والرسم التخطيطي والمشاركة. إنها ليست محسّنة أو مؤمنة لاستضافة موقع ويب حي ومتاح للجمهور. لا توجه اسم النطاق الخاص بك إلى رابط ساحة لعب!

لماذا يجب أن تكون على رادارك

كل مطور ويب، من المبتدئ حديث العهد إلى المخضرم الأكثر خبرة، لديه استخدام لساحة لعب الويب.

• للتعلم: إنها المسار الأكثر مباشرة من تعلم مفهوم إلى رؤيته قيد التنفيذ. لا إعداد، فقط كود.
• للنماذج الأولية: قم بسرعة بإنشاء نموذج لفكرة واجهة مستخدم أو اختبار ميزة CSS جديدة قبل الالتزام بدمجها في قاعدة كود كبيرة.
• لتصحيح الأخطاء: اعزل خطأ في بيئة معقمة بعيدًا عن تعقيد تطبيقك الرئيسي.
• للمشاركة: إنشاء رابط قابل للمشاركة هو أسهل طريقة لإظهار خدعة رائعة لزميل، أو إثبات وجود خطأ، أو طلب المساعدة. مثال حي يساوي ألف كلمة من الوصف.
• للتوثيق: العديد من المشاريع تدمج ساحات لعب تفاعلية مباشرة في وثائقها لتوفير أمثلة حية وقابلة للتعديل لمكوناتها.

فكر فيها كأداة أساسية أخرى في حزامك، بجانب محرر الكود وأدوات المطور في المتصفح. إنها المعادل الرقمي للسبورة البيضاء أو المنديل — مكان للأفكار السريعة وحل المشكلات المركزة.

تعمق أكثر

• MDN: <iframe>: The Inline Frame element: العنصر التأسيسي الذي يجعل ساحات اللعب ممكنة.
• MDN: The srcdoc attribute: الخاصية الحديثة لحقن محتوى HTML مباشرة في iframe.
• MDN: Window.postMessage(): واجهة برمجة التطبيقات المستخدمة للاتصال الآمن عبر الأصول المختلفة بين الـ iframe والنافذة الأم (كيف يعمل الـ console!).
• WHATWG HTML Spec: Sandboxing: المواصفات الرسمية التي تفصل قيود الأمان لـ iframes المعزولة.
• CSS-Tricks: "Avoid a Void in an <iframe> with srcdoc": نظرة عملية على استخدام srcdoc وفوائدها.

كيف يفهم المحرر الشيفرة

ألوان الصياغة تأتي من محلل اللغة، لا من تشغيل البرنامج. يتعرف CodeMirror وLezer على الرموز والبنية محليًا في المتصفح. تجمع الاقتراحات الكلمات المحجوزة والأسماء المحلية عند دعمها والمقاطع الجاهزة ومرجعًا مدمجًا صغيرًا؛ ويكشف المرور فوق رمز موثق عن توقيعه. الاقتراح لا يضمن وجود الواجهة في بيئة التنفيذ. يكتشف المحلل أخطاء الصياغة عند دعمها، لكنه لا يحل محل فحص الأنواع أو التشغيل: قد تفشل شيفرة سليمة نحويًا. يستخدم Ruby وLua أوضاعًا قائمة على الرموز وتشخيصات أكثر محدودية. لا يوجد خادم لغة بعيد، ولا تحتاج الشيفرة إلى مغادرة الجهاز.

CodeMirror & Lezer: MIT.