هناك العديد من محركات الألعاب في العالم: Unreal Engine، Unity Engine، Godot Engine، Cry Engine، والمزيد.

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

الآن، دعنا نعود إلى تطوير الواجهة الأمامية. يعد React أحد أكثر أطر العمل شيوعًا في هذا المجال. ولكن، مثلما يعد تعديل المحرك أمرًا شائعًا في تطوير الألعاب، فهل من الشائع تعديل كود المصدر الداخلي لـ React في تطوير الواجهة الأمامية؟ يكشف هذا السؤال البسيط الكثير عما نسعى إليه حقًا ويسلط الضوء على الفرق في الاتجاه بين تطوير الواجهة الأمامية الحديثة والمجالات الأخرى.

React هو إطار عمل يكاد يكون من المستحيل تعديله. ننصحك باستخدام React كما هو، وليس مخصصًا للمطورين تخصيص بنيته الداخلية أو مسار العرض. لذلك، استخدام React يعني أنه يجب عليك حل جميع متطلباتك ضمن حدود بنية React. لكن العالم مليء بالمتطلبات المتنوعة، ولا يمكن حلها كلها ضمن إطار عمل React.

"ليس هناك شيء اسمه وجبة غداء مجانية."
"لا توجد أداة يمكنها فعل كل شيء."

React هي مجرد أداة تطوير واحدة، ولها حدودها.

السبب الرئيسي وراء استخدام المطورين لـ React هو الإنتاجية. تم إنشاء React مع السؤال، "كيف يمكننا تطوير مكونات DOM بشكل أكثر كفاءة في تطوير الويب؟" في قلب نهج React يوجد DOM. تمامًا كما تعني الميزات التلقائية عمومًا نقص التخصيص، فإن "الإنتاجية" التي يتحدثون عنها غالبًا ما تعني "لا يمكنك تعديل حلقة العرض المقترنة بإحكام بالمتصفح من خلال DOM الافتراضي."

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

المشكلة الثانية هي DOM الافتراضي. إليك كيفية عمل DOM الافتراضي:

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

السؤال هو، لماذا تتبنى HPSE مثل هذا النظام في المقام الأول؟ إلى جانب القلق من أن أسلوب العرض هذا لا يمكنه معالجة متطلبات HPSE المختلفة، فإن القلق الأكبر هو افتقاره إلى الفائدة الفعلية في هذا السياق.

في HPSE، يمكن إدارة مكونات DOM على مستوى الفصل الدراسي. عند إنشاء مثيل، يتم تخزين مرجع div DOM ذي المستوى الأعلى كمتغير عضو. يمكن للطرق الخاصة للمثيل إما التعامل مباشرة مع مرجع DOM أو استخدام querySelector() للوصول إليه. في معظم الحالات، سيكون هذا أسرع من مقارنة شجرة DOM بأكملها.

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

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

يجب أن تمر التغييرات على المكونات في React عبر DOM الافتراضي، وتتم إدارة DOM الافتراضي بواسطة بنية Fiber، التي تتبع قواعد أولوية محددة. ومع ذلك، هناك القليل من الوثائق حول كيفية تخصيص وظائف React الداخلية لتلبية الأداء في الوقت الفعلي أو متطلبات التوقيت الدقيق لـ HPSE. يبدو الأمر وكأنه تطوير لعبة AAA بمحرك لا يمكن تخصيصه.

"لماذا تهتم؟"

إنه سؤال يتكرر باستمرار.

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

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

تسمح لك مكتبات مثل React Three Fiber (R3F) بإنشاء مثيلات مثل Mesh أو Scene باستخدام بناء جملة "HTML Element Like"، ولكن هذا ببساطة هو Three.js الذي تم تكييفه مع بنية React. يؤدي المستوى العالي من الاقتران داخل React إلى تفاقم مشكلة الأجزاء الداخلية غير القابلة للتعديل.

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

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

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