اختبار قابلية التشغيل البيني لمكونات الويب: التحقق من التوافق عبر الأطر البرمجية

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

الوعد الذي تقدمه مكونات الويب

مكونات الويب هي مجموعة من واجهات برمجة تطبيقات منصة الويب التي تسمح لك بإنشاء علامات HTML جديدة مخصصة وقابلة لإعادة الاستخدام ومغلفة لتشغيل مكونات الويب الخاصة بك. تشمل التقنيات الأساسية ما يلي:

• العناصر المخصصة (Custom Elements): واجهات برمجة تطبيقات لتعريف وإنشاء عناصر HTML مخصصة وسلوكها.
• Shadow DOM: واجهات برمجة تطبيقات لتغليف DOM و CSS، مما يمنع تعارض الأنماط ويضمن عزل المكونات.
• قوالب HTML (HTML Templates): عنصرا <template> و <slot> لإنشاء هياكل ترميز قابلة لإعادة الاستخدام.

إن الطبيعة المستقلة عن الأطر البرمجية لمكونات الويب تعني أنها مصممة للعمل بشكل مستقل عن أي إطار عمل JavaScript. ومع ذلك، لا يتحقق هذا الوعد بالكامل إلا إذا كان من الممكن دمج المكونات وتشغيلها بشكل صحيح ضمن أطر العمل الشائعة المختلفة مثل React و Angular و Vue.js و Svelte وحتى HTML/JavaScript العادي. وهذا يقودنا إلى المجال الحيوي وهو اختبار قابلية التشغيل البيني.

لماذا يعد اختبار قابلية التشغيل البيني حاسماً؟

بدون اختبار شامل لقابلية التشغيل البيني، يمكن أن يصبح وعد "الاستقلالية عن الأطر البرمجية" تحديًا كبيرًا:

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

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

المجالات الرئيسية لاختبار قابلية التشغيل البيني لمكونات الويب

يتطلب اختبار قابلية التشغيل البيني الفعال نهجًا منهجيًا يركز على عدة مجالات رئيسية:

1. العرض الأساسي والتعامل مع السمات/الخصائص

هذا هو المستوى التأسيسي للاختبار. يجب أن يتم عرض مكون الويب الخاص بك بشكل صحيح وأن يستجيب لسماته وخصائصه كما هو متوقع، بغض النظر عن كيفية إنشائه:

• ربط السمات (Attribute Binding): اختبر كيفية تمرير وتحليل السمات النصية. غالبًا ما يكون للأطر البرمجية اصطلاحات مختلفة لربط السمات (على سبيل المثال، kebab-case مقابل camelCase).
• ربط الخصائص (Property Binding): تأكد من إمكانية تمرير أنواع البيانات المعقدة (الكائنات، المصفوفات، القيم المنطقية) كخصائص. غالبًا ما تكون هذه نقطة اختلاف بين الأطر البرمجية. على سبيل المثال، في React، قد تمرر خاصية (prop) مباشرة، بينما في Vue، قد يتم ربطها باستخدام v-bind.
• إصدار الأحداث (Event Emission): تحقق من أن الأحداث المخصصة يتم إرسالها بشكل صحيح ويمكن الاستماع إليها بواسطة إطار العمل المضيف. غالبًا ما توفر الأطر البرمجية آلياتها الخاصة لمعالجة الأحداث (على سبيل المثال، onEventName في React، و @event-name في Vue).
• إسقاط محتوى الفتحة (Slot Content Projection): تأكد من أن المحتوى الذي يتم تمريره إلى الفتحات (الافتراضية والمسماة) يتم عرضه بدقة عبر الأطر البرمجية.

مثال: لنأخذ مكون زر مخصص، <my-button>، بسمات مثل color وخصائص مثل disabled. يتضمن الاختبار:

• استخدام <my-button color="blue"></my-button> في HTML العادي.
• استخدام <my-button color={'blue'}></my-button> في React.
• استخدام <my-button :color='"blue"'></my-button> في Vue.
• التأكد من إمكانية تعيين خاصية disabled وإلغاء تعيينها بشكل صحيح في كل سياق.

2. تغليف Shadow DOM وتنسيقه

يعد Shadow DOM مفتاحًا لتغليف مكونات الويب. ومع ذلك، تحتاج التفاعلات بين أنماط إطار العمل المضيف وأنماط Shadow DOM للمكون إلى التحقق الدقيق:

• عزل الأنماط: تحقق من أن الأنماط المحددة داخل Shadow DOM لمكون الويب لا تتسرب وتؤثر على الصفحة المضيفة أو المكونات الأخرى.
• وراثة الأنماط: اختبر كيفية اختراق متغيرات CSS (الخصائص المخصصة) والأنماط الموروثة من DOM الخفيف (light DOM) لـ Shadow DOM. تحترم معظم الأطر الحديثة متغيرات CSS، لكن الإصدارات الأقدم أو التكوينات المحددة قد تمثل تحديات.
• أوراق الأنماط العامة: تأكد من أن أوراق الأنماط العامة لا تتجاوز أنماط المكونات عن غير قصد ما لم يكن ذلك مقصودًا بشكل صريح من خلال متغيرات CSS أو محددات معينة.
• حلول التنسيق الخاصة بالأطر البرمجية: تحتوي بعض الأطر على حلول تنسيق خاصة بها (مثل وحدات CSS، و styled-components في React، و CSS المحدد النطاق في Vue). اختبر كيفية تصرف مكون الويب الخاص بك عند وضعه داخل هذه البيئات المنسقة.

مثال: مكون نافذة حوارية (modal) بتنسيق داخلي لرأسه وجسمه وتذييله. اختبر أن هذه الأنماط الداخلية محتواة وأن الأنماط العامة على الصفحة لا تكسر تخطيط النافذة. اختبر أيضًا أنه يمكن استخدام متغيرات CSS المحددة على العنصر المضيف داخل Shadow DOM للنافذة لتخصيص مظهرها، على سبيل المثال، --modal-background-color.

3. ربط البيانات وإدارة الحالة

تعد كيفية تدفق البيانات من وإلى مكون الويب الخاص بك أمرًا بالغ الأهمية للتطبيقات المعقدة:

• ربط البيانات ثنائي الاتجاه: إذا كان مكونك يدعم الربط ثنائي الاتجاه (على سبيل المثال، حقل إدخال)، فتحقق من أنه يعمل بسلاسة مع الأطر التي لديها آليات ربط ثنائية الاتجاه خاصة بها (مثل ngModel في Angular أو v-model في Vue). يتضمن هذا غالبًا الاستماع إلى أحداث الإدخال وتحديث الخصائص.
• تكامل حالة إطار العمل: اختبر كيفية تفاعل الحالة الداخلية لمكونك (إن وجدت) مع حلول إدارة الحالة في إطار العمل المضيف (مثل Redux، و Vuex، و Zustand، وخدمات Angular).
• هياكل البيانات المعقدة: تأكد من أن كائنات البيانات والمصفوفات المعقدة التي يتم تمريرها كخصائص يتم التعامل معها بشكل صحيح، خاصة عند حدوث تغييرات داخل المكون أو إطار العمل.

مثال: مكون إدخال نموذج يستخدم v-model في Vue. يجب أن يصدر مكون الويب حدث `input` بالقيمة الجديدة، والذي يلتقطه v-model في Vue ثم يقوم بتحديث خاصية البيانات المرتبطة.

4. معالجة الأحداث والاتصال

تحتاج المكونات إلى التواصل مع محيطها. يعد اختبار معالجة الأحداث عبر الأطر البرمجية أمرًا حيويًا:

• أسماء الأحداث المخصصة: تأكد من الاتساق في تسمية الأحداث المخصصة وحمولات البيانات.
• أحداث المتصفح الأصلية: تحقق من أن أحداث المتصفح الأصلية (مثل `click` و `focus` و `blur`) يتم نشرها بشكل صحيح ويمكن التقاطها بواسطة إطار العمل المضيف.
• أغلفة الأحداث الخاصة بالأطر البرمجية: قد تقوم بعض الأطر بتغليف الأحداث الأصلية أو المخصصة. اختبر أن هذه الأغلفة لا تغير بيانات الحدث أو تمنع إرفاق المستمعين.

مثال: مكون قابل للسحب يصدر حدثًا مخصصًا 'drag-end' مع الإحداثيات. اختبر إمكانية التقاط هذا الحدث بواسطة مكون React باستخدام onDragEnd={handleDragEnd} وبواسطة مكون Vue باستخدام @drag-end="handleDragEnd".

5. استدعاءات دورة الحياة (Lifecycle Callbacks)

تحتوي مكونات الويب على استدعاءات دورة حياة محددة (على سبيل المثال، `connectedCallback` و `disconnectedCallback` و `attributeChangedCallback`). يحتاج تفاعلها مع دورات حياة إطار العمل إلى دراسة متأنية:

• ترتيب التهيئة: افهم كيف يتم إطلاق استدعاءات دورة حياة مكونك بالنسبة لخطافات دورة حياة مكون إطار العمل المضيف.
• إرفاق/فصل DOM: تأكد من تشغيل `connectedCallback` و `disconnectedCallback` بشكل موثوق عند إضافة المكون إلى DOM أو إزالته منه بواسطة محرك عرض إطار العمل.
• تغييرات السمات: تحقق من أن `attributeChangedCallback` يلاحظ تغييرات السمات بشكل صحيح، خاصة عندما قد تقوم الأطر بتحديث السمات ديناميكيًا.

مثال: مكون يجلب البيانات في `connectedCallback` الخاص به. اختبر أن طلب الجلب هذا يتم مرة واحدة فقط عند تحميل المكون بواسطة Angular أو React أو Vue، وأنه يتم تنظيفه بشكل صحيح (على سبيل المثال، إلغاء عمليات الجلب) عند استدعاء `disconnectedCallback`.

6. إمكانية الوصول (Accessibility - A11y)

يجب أن تكون إمكانية الوصول مواطنًا من الدرجة الأولى. يجب أن يضمن اختبار قابلية التشغيل البيني الحفاظ على معايير إمكانية الوصول عبر الأطر البرمجية:

• سمات ARIA: تأكد من تطبيق أدوار وحالات وخصائص ARIA المناسبة بشكل صحيح وإتاحتها للتقنيات المساعدة.
• التنقل عبر لوحة المفاتيح: اختبر أن المكون قابل للتنقل والتشغيل بالكامل باستخدام لوحة المفاتيح داخل سياق كل إطار عمل.
• إدارة التركيز: تحقق من أن إدارة التركيز داخل Shadow DOM وتفاعلها مع استراتيجيات إدارة التركيز في إطار العمل المضيف قوية.
• HTML الدلالي: تأكد من أن البنية الأساسية تستخدم عناصر HTML مناسبة دلاليًا.

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

7. اعتبارات الأداء

يمكن أن يتأثر الأداء بكيفية تفاعل الأطر البرمجية مع مكونات الويب:

• وقت العرض الأولي: قم بقياس مدى سرعة عرض المكون عند دمجه في أطر عمل مختلفة.
• أداء التحديث: راقب الأداء أثناء تغييرات الحالة وإعادة العرض. يمكن أن يتسبب ربط البيانات غير الفعال أو التلاعب المفرط بـ DOM بواسطة إطار العمل المتفاعل مع المكون في حدوث تباطؤ.
• حجم الحزمة (Bundle Size): بينما تكون مكونات الويب نفسها غالبًا خفيفة، يمكن أن تضيف أغلفة إطار العمل أو تكوينات البناء عبئًا إضافيًا.

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

8. الفروق الدقيقة والحالات الخاصة بالأطر البرمجية

لكل إطار عمل خصائصه وتفسيراته الخاصة لمعايير الويب. يتضمن الاختبار الشامل الكشف عن هذه الأمور:

• العرض من جانب الخادم (SSR): كيف يتصرف مكون الويب الخاص بك أثناء SSR؟ قد تواجه بعض الأطر صعوبة في ترطيب مكونات الويب بشكل صحيح بعد العرض الأولي من الخادم.
• أنظمة الأنواع (TypeScript): إذا كنت تستخدم TypeScript، فتأكد من أن تعريفات الأنواع لمكونات الويب الخاصة بك متوافقة مع كيفية استهلاك الأطر لها.
• الأدوات وعمليات البناء: يمكن أن تؤثر أدوات البناء المختلفة (Webpack، Vite، Rollup) وواجهات سطر الأوامر الخاصة بالأطر على كيفية تجميع ومعالجة مكونات الويب.

مثال: اختبار مكون ويب مع SSR في Angular Universal. تحقق من أن المكون يتم عرضه بشكل صحيح على الخادم ثم يتم ترطيبه بشكل صحيح على العميل دون أخطاء أو عمليات إعادة عرض غير متوقعة.

استراتيجيات لاختبار فعال لقابلية التشغيل البيني

يعد اعتماد استراتيجية اختبار قوية أمرًا أساسيًا لتحقيق توافق موثوق عبر الأطر البرمجية:

1. تصميم مجموعة اختبار شاملة

يجب أن تغطي مجموعة الاختبار الخاصة بك جميع المجالات الحاسمة المذكورة أعلاه. ضع في اعتبارك:

• اختبارات الوحدة (Unit Tests): لمنطق المكون الفردي والحالة الداخلية.
• اختبارات التكامل (Integration Tests): للتحقق من التفاعلات بين مكون الويب الخاص بك وإطار العمل المضيف. هنا يبرز اختبار قابلية التشغيل البيني حقًا.
• الاختبارات الشاملة (End-to-End - E2E): لمحاكاة تدفقات المستخدم عبر تطبيقات أطر عمل مختلفة.

2. الاستفادة من أطر الاختبار

استخدم أدوات ومكتبات الاختبار الراسخة:

• Jest/Vitest: أطر اختبار JavaScript قوية لاختبارات الوحدة والتكامل.
• Playwright/Cypress: للاختبار الشامل، مما يتيح لك محاكاة تفاعلات المستخدم في بيئات متصفح حقيقية عبر أطر عمل مختلفة.
• WebdriverIO: إطار اختبار E2E قوي آخر يدعم متصفحات متعددة.

3. إنشاء تطبيقات اختبار خاصة بالأطر البرمجية

الطريقة الأكثر فعالية لاختبار قابلية التشغيل البيني هي إنشاء تطبيقات صغيرة ومخصصة أو أدوات اختبار باستخدام كل إطار عمل مستهدف. على سبيل المثال:

• تطبيق اختبار React: تطبيق React بسيط يستورد ويستخدم مكونات الويب الخاصة بك.
• تطبيق اختبار Angular: مشروع Angular بسيط يعرض مكوناتك.
• تطبيق اختبار Vue: تطبيق Vue.js أساسي.
• تطبيق اختبار Svelte: مشروع Svelte.
• تطبيق HTML/JS عادي: خط أساس لسلوك الويب القياسي.

ضمن هذه التطبيقات، اكتب اختبارات تكامل تستهدف على وجه التحديد حالات الاستخدام الشائعة والمزالق المحتملة.

4. الاختبار الآلي وتكامل CI/CD

أتمتة اختباراتك قدر الإمكان وادمجها في مسار التكامل المستمر/النشر المستمر (CI/CD). هذا يضمن التحقق من كل تغيير في الكود مقابل جميع الأطر المستهدفة تلقائيًا، واكتشاف التراجعات في وقت مبكر.

مثال لسير عمل CI/CD:

1. دفع الكود إلى المستودع.
2. خادم CI يبدأ عملية البناء.
3. عملية البناء تقوم بتجميع مكونات الويب وإعداد بيئات الاختبار لـ React و Angular و Vue.
4. تشغيل الاختبارات الآلية مقابل كل بيئة (وحدة، تكامل، E2E).
5. إرسال إشعارات بنجاح أو فشل الاختبار.
6. إذا نجحت الاختبارات، يتم تشغيل مسار النشر.

5. تحليل الأداء ومراقبته

ادمج اختبار الأداء في مجموعتك الآلية. استخدم أدوات مطوري المتصفح أو أدوات تحليل متخصصة لقياس المقاييس الرئيسية مثل وقت التحميل واستخدام الذاكرة واستجابة التفاعل في سياق كل إطار عمل.

6. توثيق تكامل الأطر البرمجية

قدم وثائق واضحة وموجزة حول كيفية دمج مكونات الويب الخاصة بك مع الأطر الشائعة. وهذا يشمل:

• تعليمات التثبيت.
• أمثلة على ربط السمات والخصائص.
• كيفية التعامل مع الأحداث المخصصة.
• نصائح للتعامل مع الفروق الدقيقة الخاصة بالأطر البرمجية (مثل SSR).

يجب أن تعكس هذه الوثائق النتائج المستخلصة من اختبار قابلية التشغيل البيني الخاص بك.

7. ملاحظات المجتمع والإبلاغ عن الأخطاء

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

الأدوات والمكتبات لقابلية التشغيل البيني

بينما يمكنك بناء البنية التحتية للاختبار الخاصة بك من البداية، يمكن للعديد من الأدوات تبسيط العملية بشكل كبير:

• LitElement/Lit: مكتبة شائعة لبناء مكونات الويب، والتي تخضع هي نفسها لاختبارات مكثفة عبر الأطر. يمكن تكييف أدوات الاختبار المدمجة بها.
• Stencil: مترجم يولد مكونات ويب قياسية ولكنه يوفر أيضًا أدوات لروابط الأطر، مما يبسط التكامل والاختبار.
• Testing Library (React Testing Library, Vue Testing Library, etc.): بينما هي مخصصة بشكل أساسي للمكونات الخاصة بالأطر، فإن مبادئ اختبار تفاعلات المستخدم وإمكانية الوصول تنطبق. يمكنك تكييفها لاختبار كيفية تفاعل الأطر مع عناصرك المخصصة.
• الأغلفة الخاصة بالأطر البرمجية: فكر في إنشاء أغلفة خفيفة لمكونات الويب الخاصة بك لكل إطار عمل. يمكن لهذه الأغلفة التعامل مع اصطلاحات ربط البيانات ومستمعي الأحداث الخاصة بالإطار، مما يجعل التكامل أكثر سلاسة ويبسط الاختبار. على سبيل المثال، قد يترجم غلاف React خصائص وأحداث React إلى خصائص وأحداث مكون الويب.

الاعتبارات العالمية لقابلية التشغيل البيني لمكونات الويب

عند تطوير واختبار مكونات الويب لجمهور عالمي، تظهر عدة عوامل تتجاوز التوافق التقني البحت:

• التوطين والتدويل (i18n/l10n): تأكد من أن مكوناتك يمكنها استيعاب اللغات وتنسيقات التواريخ والأرقام المختلفة بسهولة. يعني اختبار هذا التحقق من كيفية تفاعل مكتبات التوطين القائمة على إطار العمل مع محتوى النص والتنسيق في مكونك.
• المناطق الزمنية والعملات: إذا كانت مكوناتك تعرض الوقت أو القيم النقدية، فتأكد من أنها تتعامل مع المناطق الزمنية والعملات المختلفة بشكل صحيح، خاصة عند دمجها في تطبيقات تدير إعدادات خاصة بالمستخدم.
• الأداء في مناطق مختلفة: يمكن أن يختلف زمن استجابة الشبكة بشكل كبير في جميع أنحاء العالم. اختبر أداء مكون الويب الخاص بك على شبكات أبطأ محاكاة لضمان تجربة جيدة للمستخدمين في المناطق ذات البنية التحتية للإنترنت الأقل تطورًا.
• دعم المتصفحات: بينما يتم دعم مكونات الويب على نطاق واسع، قد تحتوي المتصفحات القديمة أو إصدارات معينة من المتصفحات على تناقضات. اختبر عبر مجموعة من المتصفحات، مع مراعاة الأكثر شيوعًا المستخدمة في الأسواق العالمية المختلفة.

مستقبل قابلية التشغيل البيني لمكونات الويب

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

الخاتمة

إن اختبار قابلية التشغيل البيني لمكونات الويب ليس إضافة اختيارية؛ إنه مطلب أساسي لبناء عناصر واجهة مستخدم قابلة لإعادة الاستخدام وقوية ومتوافقة عالميًا. من خلال الاختبار المنهجي للتعامل مع السمات/الخصائص، وتغليف Shadow DOM، وتدفق البيانات، واتصال الأحداث، واتساق دورة الحياة، وإمكانية الوصول، والأداء عبر مجموعة متنوعة من أطر وبيئات الواجهة الأمامية، يمكنك إطلاق العنان للإمكانات الحقيقية لمكونات الويب. يضمن هذا النهج المنضبط أن مكوناتك تقدم تجربة مستخدم متسقة وموثوقة، بغض النظر عن مكان أو كيفية نشرها، مما يمكّن المطورين في جميع أنحاء العالم من بناء تطبيقات أفضل وأكثر ترابطًا.