قد يظهر مكوّن حقل الاتصال مرة في الصفحة ومرة داخل نافذة جانبية. إذا حمل الاثنان id ثابتًا واحدًا، يمكن أن يرتبط الوصف أو العنوان بالحقل الخطأ رغم أن الشكل يبدو سليمًا. هذا عيب في العلاقات داخل الصفحة، وقد لا تكشفه لقطة التصميم.
أنشئ هوية للعنصر وعلاقاته
تقدم وثائق React لواجهة useId طريقة لتوليد معرفات تستخدم مع خصائص الإتاحة. يُستدعى Hook في المستوى الأعلى للمكوّن، ويمكن اشتقاق معرفات متصلة من بادئة واحدة. الهدف أن يشير label ووصف الحقل إلى العناصر الصحيحة عند تكرار المكوّن.
المعرف هنا ليس رقم العميل في قاعدة البيانات، ولا مفتاح صف في قائمة. تؤكد الوثائق عدم استعمال useId لتوليد keys للقوائم. هوية السجل التي يجب أن تبقى مع نقله أو ترتيبه مسألة منفصلة عن علاقة حقل بعنوانه داخل DOM.
افحص نسختين ظاهرتين معًا
في مثال افتراضي، افتح نموذج إضافة جهة اتصال وآخر لتعديل جهة مختلفة. اضغط عنوان البريد في الأول: يجب أن ينتقل التركيز إلى حقله. كرر في الثاني، ثم افحص الاسم والوصف المقروءين بأداة إتاحة. وجود نص مساعد بجوار الحقل بصريًا لا يثبت أن aria-describedby يشير إليه.
- لا يوجد id مكرر في النسختين المعروضتين.
- كل قيمة for تشير إلى عنصر واحد مقصود.
- كل مرجع في aria-describedby موجود ولا يحمل وصف النموذج الآخر.
- الخطأ الذي يظهر بعد التحقق مرتبط بالحقل الصحيح.
راجع تطابق العرض على الخادم والمتصفح
توضح الوثائق أن useId مع العرض على الخادم يحتاج شجرة مكونات متطابقة عند العرض الأول في الطرفين. لذلك لا تجعل شرطًا مختلفًا بين الخادم والمتصفح يضيف نسخة حقل في أحدهما فقط، ثم تعتبر اختفاء التحذير كافيًا دون إصلاح السبب.
وعند وجود جذور React مستقلة متعددة، راجع identifierPrefix لمنع التصادم، مع مطابقة البادئة في الخادم وhydrateRoot للجزء نفسه. لا تحتاج إضافة تعقيد جذور متعددة إلى مشروع لا يستخدمها.
اعتمد العلاقات قبل الزخرفة
في تصميم تجربة المستخدم وتطوير الويب وثق الاختبار على النسخة التي ستُنشر وبالأجهزة المساندة المستهدفة. معيار القبول أن يسمع المستخدم عنوان الحقل ووصفه الصحيحين ويتنقل بين النموذجين بوضوح. توليد معرف فريد خطوة مساعدة، ولا يعوض عنوانًا مفقودًا أو ترتيب تركيز غير مناسب.
