العودة إلى الوراء
تحويل مصفوفة إلى قائمة من العناصر باستخدام React بسيط جدًا، كل ما عليك فعله هو تعيين تلك المصفوفة وإرجاع العنصر المناسب لكل عنصر مصفوفة.
هناك أيضًا شيء آخر يجب أن تتذكره وهو مفتاح React يجب أن يحتوي كل عنصر من عناصر القائمة المعروضة على هذه السمة. هذا المفهوم هو أحد الأشياء الأولى التي يتعلمها كل مطور واجهة أمامية React في بداية رحلتهم. والآن دعنا نتعمق قليلاً لاستكشاف سبب حدوث ذلك، ومتى يمكننا اتخاذ بعض الطرق المختصرة.
قد تكون أبسط إجابة هنا هي "لتحسين عمليات إعادة الإرجاع"، ولكن الإجابة الأكثر اكتمالاً يجب أن تذكر على الأقل مفهوم React تسوية React. هذه هي عملية معرفة كيفية تحديث واجهة المستخدم بأكثر الطرق فعالية. للقيام بذلك بسرعة React أن يقرّر أي أجزاء من شجرة العناصر يجب تحديثها وأيها لا يجب تحديثها. المشكلة هي أنه قد يكون هناك الكثير من العناصر في DOM ومقارنة كل عنصر منها في تحديد أي منها يجب تحديثه مكلف جدًا. لتحسين ذلك, React تطبق خوارزمية الفرق التي تعتمد على افتراضين:
وبناءً على ذلك، يمكننا استنتاج أن كلًّا من مفتاح React يجب أيضًا أن تكون فريدة (ضمن قائمة العناصر، وليس على مستوى العالم)، ومستقرة (يجب ألا تتغير). لكن ما الذي يمكن أن يحدث عندما لا تكون كذلك؟
كما ذكرنا من قبل, مفاتيح React يجب أن يكون ثابتًا وفريدًا. أسهل طريقة لتحقيق ذلك هو استخدام مُعرِّف فريد (من قاعدة بيانات على سبيل المثال) وتمريره إلى كل عنصر عند تعيين مصفوفة، أمر سهل. ولكن ماذا عن الحالات التي لا نملك فيها معرّفًا أو اسمًا أو معرّفات فريدة أخرى لتمريرها إلى كل عنصر؟ حسنًا، إن لم نمرر أي شيء كمفتاح React سيأخذ فهرس المصفوفة الحالي افتراضيًا (بما أنه فريد داخل تلك القائمة) للتعامل معه نيابةً عنا، ولكنه سيعطينا أيضًا رسالة خطأ لطيفة في وحدة التحكم:
لماذا هذا هو الحال؟ الجواب هو أن فهرس المصفوفة غير مستقر. إذا تغيّر ترتيب العناصر، سيتغيّر كل مفتاح من المفاتيح وسيكون لدينا مشكلة. إذا كان React يصادف حالة تم فيها تغيير الترتيب في قائمة العناصر، سيستمر في محاولة مقارنتها حسب المفاتيح، وهذا يعني أن كل مقارنة ستنتهي بإعادة بناء مكون، ونتيجةً لذلك ستتم إعادة بناء القائمة بأكملها من الصفر. بالإضافة إلى ذلك، قد نواجه بعض المشاكل غير المتوقّعة، مثل تحديثات حالة المكوّن لعناصر مثل المدخلات غير المنضبطة وغيرها من المشاكل السحرية التي يصعب تصحيحها.
لنعد إلى فهرس المصفوفة. إذا كان استخدامه كـ مفتاح React يمكن أن تكون إشكالية للغاية، لماذا React سيستخدمها افتراضيًا؟ هل هناك أي حالة استخدام حيث لا بأس من القيام بذلك؟ الإجابة نعم، حالة الاستخدام هي القوائم الثابتة. إن كنت متأكدًا من أن القائمة التي تصيِّرها لن يتغير ترتيبها أبدًا، فمن الآمن استخدام فهرس الصفيف، ولكن تذكّر إن كان لديك أي معرّفات فريدة فمن الأفضل استخدامها بدلًا من ذلك. يمكنك أيضًا أن تلاحظ أن تمرير الفهارس كمفاتيح سيجعل React تختفي رسالة الخطأ، بينما تؤدي في الوقت نفسه إلى قيام بعض المُصنفات الخارجية بعرض خطأ أو تحذير. ويرجع ذلك إلى حقيقة أن الاستخدام الصريح للفهارس كمفاتيح يعتبر ممارسة سيئة وقد تتعامل بعض المُعالجات الخارجية مع ذلك على أنه خطأ، بينما React نفسها تعتبرها حالة "المطورين الذين يعرفون ما يفعلونه" - لذا لا تفعل ذلك إلا إذا كنت تعرف حقًا ما تفعله. بعض الأمثلة على الحالات التي يمكن أن يكون فيها استخدام هذا الاستثناء مقبولًا هي القائمة المنسدلة بقائمة ثابتة من الأزرار أو عرض قائمة من العناصر مع معلومات عنوان شركتك.
لنفترض أن أياً مما سبق ليس خياراً متاحاً لنا. على سبيل المثال، علينا أن نعرض قائمة من العناصر بناءً على مصفوفة من السلاسل التي يمكن أن تكون مكررة ولكن يمكن أيضًا إعادة ترتيبها. في هذه الحالة، لا يمكننا استخدام أي من السلاسل لأنها ليست فريدة (يمكن أن يسبب هذا بعض الأخطاء السحرية أيضًا)، وفهرس المصفوفة ليس جيدًا بما فيه الكفاية لأننا سنغير ترتيب العناصر. آخر شيء يمكننا الاعتماد عليه في مثل هذه الحالات هو استخدام بعض المعرّفات الخارجية. تذكر، يجب أن تكون مستقرة لذا لا يمكننا استخدام Math.random(). هناك بعض حزم NPM التي يمكننا استخدامها في مثل هذه الحالات، على سبيل المثال "uuid" الحزمة. يمكن لأدوات كهذه أن تساعدنا في الحفاظ على مفاتيح قائمتنا مستقرة وفريدة، حتى عندما لا يمكننا العثور على معرّفات مناسبة ضمن مجموعة بياناتنا. يجب أن نأخذ بعين الاعتبار استخدام معرّف قاعدة البيانات وفهرس الصفيف (إن أمكن) أولًا، لتقليل عدد الحزم المستخدمة من قبل المشروع.
اقرأ المزيد:
لماذا يجب عليك (على الأرجح) استخدام Typescript
Arabic 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek