لا تخلط بين شكل البيانات وشكل الحالة (State Shape)

عند بناء نموذج (form) في React، غالبًا ما تقوم بتجميع كل شيء في كائن حالة (state object) واحد كبير.

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

هذا فخ.

المشكلة ليست في React، بل في شكل الحالة (state) الخاصة بك.

النماذج ليست بيانات ثابتة، بل هي أنظمة تفاعلية. المستخدمون لا يقومون بتحديث النماذج قسماً بقسم، بل يقومون بتحديثها حقلاً بحقل.

لماذا تضر الحالة المتداخلة (nested state) بمشروعك:

  • تصبح التحديثات ثقيلة. لتغيير اسم مدينة واحدة، يجب عليك إعادة إنشاء المدينة، والعنوان، وكائن النموذج الأساسي للحفاظ على عدم القابلية للتغيير (immutability).
  • يتسرب التعقيد. مع نمو النموذج، تصبح منطق التحقق (validation) والتحميل (rendering) أصعب في الإدارة.
  • تزداد عمليات إعادة التحميل (re-renders). تغيير قيمة متداخلة واحدة ينشئ مراجع كائنات (object references) جديدة، مما قد يؤدي إلى تحديثات غير ضرورية عبر شجرة المكونات (component tree) بأكملها.
  • يزداد العبء الذهني. تتوقف عن التفكير في المستخدم وتبدأ في التفكير في مسارات الكائنات (object paths).

النماذج الصغيرة متسامحة، أما نماذج المنتجات فليست كذلك.

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

الحل هو تصميم الحالة بناءً على كيفية تغير البيانات، وليس بناءً على مظهرها.

يوفر شكل الحالة الأكثر تسطحاً (flatter state shape) هذه الفوائد:

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

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

اسأل نفسك هذه الأسئلة قبل كتابة الكود:

  • ما هي الحقول التي تتغير بشكل متكرر؟
  • ما هي الأقسام التي تحتاج إلى تحقق مستقل؟
  • ما هي التحديثات التي يجب أن تظل معزولة عن بقية واجهة المستخدم؟

إذا كان تحديث حقل واحد يبدو أصعب من التغيير نفسه، فإن هيكل الحالة لديك هو المشكلة.

توقف عن نمذجة الحالة بناءً على واجهة المستخدم الخاصة بك. ابدأ بنمذجتها بناءً على سلوك المستخدم.

المصدر: https://dev.to/hardik_kuwar_7caa4626bb16/the-mistake-is-assuming-data-shape-and-state-shape-should-always-match-5g0e