خوارزمية Render و Reconciliation في React: هوية العناصر والمفاتيح الثابتة في Gutenberg

أهلاً بيك يا صديقي المطور في واحدة من أعمق الحلقات الهندسية في رحلتنا مع Gutenberg: خوارزمية Render و Reconciliation (المطابقة والتسوية) وكيف تدير React هوية العناصر من خلال المفاتيح الثابتة (Stable Keys).

لو سبق وكتبت كود لبلوك يحتوي على مصفوفة عناصر متكررة (Repeater List)—زي قائمة مميزات، أو جدول مواصفات، أو معرض صور—وفوجئت بحركة غريبة جداً: لما تدوس على زرار “حذف” للعنصر رقم 2، تلاقي العنصر رقم 3 هو اللي اتمسح، ومؤشر الكتابة (Cursor Focus) نط لوحده في حقل تاني خالص، والنصوص اتبدلت بين الحقول زي السحر الأسود! أو لاحظت إن المتصفح بيهنج وبياخد ثانية كاملة في كل حرف بتكتبه داخل جدول كبير.. المشكلة هنا مش في ووردبريس، ولا في سرعة جهازك؛ المشكلة إنك انتهكت قوانين Reconciliation في React واستخدمت مفاتيح عشوائية أو اعتمدت على فهرس المصفوفة key={index}!

في المقال ده، هنشرح إزاي خوارزمية الـ Diffing في React بتشتغل بسرعة خيالية $O(n)$، إيه الفرق بين دورة الـ Render ودورة الـ Commit، إزاي React بتحدد “هوية الكومبوننت” ومكانها في الشجرة، وليه clientId هو سر الاستقرار في جوتنبرج، مع كود إنتاجي لبلوك مكرر محصن بنسبة 100% ودراسة حالة حقيقية لسوق سيارات مصري بالعامية المصرية التقنية الأصيلة.

تشريح خوارزمية المطابقة (The Reconciliation Heuristic)

في علوم الحاسب، مقارنة شجرتين مختلفتين (Tree Diffing) عشان تعرف أقل عدد من العمليات لتحويل الشجرة الأولى للثانية هي مسألة معقدة رياضياً بتستغرق وقت $O(n^3)$. يعني لو عندك صفحة فيها 1,000 عقدة DOM، المتصفح هيحتاج مليار عملية حسابية في كل ضغطة زر! طبعاً ده مستحيل عملياً في الويب.

فريق React حل المعضلة دي بذكاء شديد عبر فرضيتين هندسيتين (Heuristics) حولوا التعقيد لـ $O(n)$ خطي فائق السرعة:

1. العناصر من أنواع مختلفة تنتج شجرات مختلفة تماماً:

   لو عندك <div><Counter /></div> وقمت بتغيير الـ <div> إلى <section>، خوارزمية Reconciliation مش هتدور جوة ولا هتحاول توفق راسين في الحلال! React ستقوم فوراً بـ Unmount كامل للـ <div> وكل ما بداخله وتدمير الـ State بتاعته، وتبني الـ <section> كعنصر جديد تماماً من الصفر.

2. العناصر المتكررة في القوائم يتم تمييزها بالمفتاح (key):

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

الفرق الجوهري بين مرحلة Render ومرحلة Commit

كثير من المطورين يعتقد أن استدعاء دالة Edit() في البلوك يعني تعديل فوري في شاشة المتصفح، وهذا فهم غير دقيق:

• مرحلة Render (الحساب النظري): تقوم React باستدعاء دالة المكون لحساب شجرة الـ Virtual DOM الجديدة بناءً على الخصائص المحدثة. هذه المرحلة تتم في الذاكرة الحية وتتكرر كثيراً دون أي تأثير على الشاشة.
• مرحلة Reconciliation (المقارنة الذكية): تقارن React شجرة الـ Virtual DOM الناتجة مع الشجرة السابقة وتستخرج قائمة التغييرات الدقيقة (DOM Mutations).
• مرحلة Commit (التطبيق الفعلي): هنا فقط، تقوم مكتبة react-dom بتطبيق التغييرات الفعلية على شجرة الـ Real DOM في المتصفح، وهي المرحلة الوحيدة المكلفة في الأداء.

كارثة الاعتماد على فهرس المصفوفة: key={index} ولماذا تدمر الحقول؟

تعال نشوف السيناريو الكارثي اللي بيحصل لما تكتب items.map((item, index) => <input key={index} ... />):

الحالة القديمة في الذاكرة:
- Index 0 (Key: 0) -> حقل يحتوي على "تويوتا كورولا" (المحرر يضع المؤشر هنا)
- Index 1 (Key: 1) -> حقل يحتوي على "هيونداي إلنترا"
- Index 2 (Key: 2) -> حقل يحتوي على "كيا سيراتو"

المحرر قرر حذف العنصر الأول ("تويوتا كورولا"):
الحالة الجديدة أصبحت تحتوي على عنصرين فقط:
- Index 0 (Key: 0) -> أصبح يحتوي على "هيونداي إلنترا"
- Index 1 (Key: 1) -> أصبح يحتوي على "كيا سيراتو"

ماذا تفعل خوارزمية Reconciliation؟
1. تنظر لـ Key: 0 -> تجده موجوداً في الحالتين! فتقول: "هذا نفس العنصر القديم، سأحتفظ بالـ DOM Node وبالمؤشر الداخلي Focus!".
2. تنظر لـ Key: 1 -> تجده موجوداً في الحالتين! فتقول: "هذا نفس العنصر القديم أيضاً!".
3. تنظر لـ Key: 2 القديم -> لا تجده في الحالة الجديدة، فتقوم بحذف العنصر الثالث من الـ DOM!

النتيجة الكارثية:
المحرر حذف العنصر الأول، لكن المتصفح مسح العنصر الثالث من الشاشة، ومؤشر الكتابة ظل عالقاً في الحقل الأول الذي تبدلت بياناته!

تطبيق عملي كامل: بناء بلوك مكرر المواصفات بمفاتيح ثابتة ومستقرة (Car Specs Repeater)

تعال نبني كود إنتاجي لبلوك مواصفات سيارات (enterprise/car-specs-table) يتيح إضافة وحذف وإعادة ترتيب المواصفات بسلاسة تامة، مع توليد معرفات فريدة دائمة (Persistent UUIDs) وتطبيق أعلى معايير أداء Reconciliation.

1. إعداد ملف block.json مع تعريف مخطط الخصائص

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "name": "enterprise/car-specs-table",
  "version": "1.0.0",
  "title": "جدول مواصفات السيارات المتقدم",
  "category": "design",
  "icon": "car",
  "attributes": {
    "specsList": {
      "type": "array",
      "default": []
    }
  },
  "editorScript": "file:./index.js",
  "style": "file:./style-index.css"
}

2. كود واجهة التحرير: edit.js بمفاتيح فريدة ودوال تذكيرية (useCallback)

import { useBlockProps } from '@wordpress/block-editor';
import { Button, TextControl } from '@wordpress/components';
import { useCallback, memo } from '@wordpress/element';
import { __ } from '@wordpress/i18n';
import './editor.scss';

// دالة توليد معرفات فريدة خفيفة وسريعة (Nanoid / UUID Generator)
const generateUniqueId = () => 'spec_' + Math.random().toString( 36 ).substring( 2, 9 ) + Date.now().toString( 36 );

// مكون السطر الفردي معزول ومغلف بـ memo لتفادي إعادة رسم كل الأسطر عند الكتابة في سطر واحد!
const SpecRowItem = memo( ( { item, onUpdate, onRemove, onMoveUp, onMoveDown, isFirst, isLast } ) => {
    return (
        

            

                
                
            

            

                 onUpdate( item.id, 'label', val ) }
                />
                 onUpdate( item.id, 'value', val ) }
                />
            

             onRemove( item.id ) } label="حذف المواصفة" />
        
    );
} );

export default function Edit( { attributes, setAttributes } ) {
    const { specsList } = attributes;
    const blockProps = useBlockProps( { className: 'az-car-specs-editor' } );

    // إضافة عنصر جديد يحمل معرّفاً فريداً ومستقراً للأبد!
    const handleAddSpec = () => {
        const newSpec = {
            id: generateUniqueId(), // المفتاح السحري لاستقرار Reconciliation
            label: '',
            value: '',
        };
        setAttributes( { specsList: [ ...specsList, newSpec ] } );
    };

    // تحديث حقل معين باستخدام المعرف الفريد وليس الفهرس
    const handleUpdateSpec = useCallback( ( id, field, newValue ) => {
        setAttributes( {
            specsList: specsList.map( ( spec ) => {
                if ( spec.id === id ) {
                    return { ...spec, [ field ]: newValue };
                }
                return spec;
            } ),
        } );
    }, [ specsList, setAttributes ] );

    // حذف عنصر بناءً على المعرف الفريد
    const handleRemoveSpec = useCallback( ( id ) => {
        setAttributes( {
            specsList: specsList.filter( ( spec ) => spec.id !== id ),
        } );
    }, [ specsList, setAttributes ] );

    // تحريك العناصر لأعلى ولأسفل بسلاسة تامة
    const handleMove = ( index, direction ) => {
        const newIndex = direction === 'up' ? index - 1 : index + 1;
        if ( newIndex = specsList.length ) return;

        const updatedList = [ ...specsList ];
        const [ movedItem ] = updatedList.splice( index, 1 );
        updatedList.splice( newIndex, 0, movedItem );

        setAttributes( { specsList: updatedList } );
    };

    return (
        

            

                
{ __( 'مواصفات وتجهيزات السيارة', 'az-specs' ) }
                
                    { __( 'إضافة مواصفة جديدة', 'az-specs' ) }
                
            

            

                { specsList.map( ( spec, index ) => (
                    // المفتاح السحري: استخدام spec.id الفريد وليس index!
                     handleMove( index, 'up' ) }
                        onMoveDown={ () => handleMove( index, 'down' ) }
                        isFirst={ index === 0 }
                        isLast={ index === specsList.length - 1 }
                    />
                ) ) }
            
        
    );
}

3. كود واجهة الحفظ: save.js النظيف والدلالي

import { useBlockProps } from '@wordpress/block-editor';

export default function save( { attributes } ) {
    const { specsList } = attributes;
    const blockProps = useBlockProps.save( { className: 'az-car-specs-table-view' } );

    if ( ! specsList || specsList.length === 0 ) {
        return null;
    }

    return (
        

            
                    { specsList.map( ( spec ) => (
                        
                    ) ) }
                

                

                    

                        
بند المواصفة الفنية
                        
التجهيز والبيان المعتمد
                    
                
                

                            
{ spec.label }
                            
{ spec.value }
                        
            
        
    );
}

سر الـ clientId: كيف تحافظ نواة Gutenberg على ترتيب البلوكات؟

إذا تأملت في الكود المصدري لنواة محرر ووردبريس في مستودع GitHub، ستكتشف أن فريق Gutenberg يطبق نفس هذه القاعدة الصارمة على مستوى البلوكات بالكامل!

كل بلوك يتم إدراجه في الصفحة يحصل فوراً على clientId (سلسلة نصية فريدة مثل: "e29a43fa-0941-477f-a18d-4cb077c5889a"). المكون المركزي المسؤول عن رسم قائمة البلوكات BlockList يقوم بكتابة:

{ blockClientIds.map( ( clientId ) => (
    
) ) }

لولا هذا الـ clientId المستقر، لما استطعت سحب وإفلات أي بلوك في المحرر، ولكان كتابة حرف في بلوك المقال الأخير يتسبب في تدمير وإعادة بناء كافة البلوكات السابقة له في الصفحة!

دراسة حالة واقعية: كارثة منصة سوق السيارات وقطع الغيار في الجيزة

الوصايا العشر لمعمارية Render و Reconciliation في جوتنبرج

1. إياك واستخدام key={index} في القوائم التفاعلية: الفهرس هو خادع بصري يدمر تسلسل الحقول ويفسد الـ Focus عند أول حذف أو إعادة ترتيب.
2. احفظ الـ id الفريد كجزء من البيانات في Attributes: اجعل المعرف الفريد يولد مرة واحدة ويخزن مع العنصر في قاعدة البيانات ليعيش معه للأبد.
3. لا تستخدم Math.random() داخل دالة Render: الأرقام العشوائية تدمر شجرة الـ DOM بالكامل في كل إطار وتعيد بناء المكونات من الصفر.
4. غلف المكونات المتكررة بـ React.memo: لا تجعل الكتابة في السطر العاشر تعيد رسم الأسطر التسعة الأولى بدون أي داعٍ.
5. حصن دوال المعالجة بـ useCallback: مرر مراجع دوال ثابتة للمكونات الفرعية لتجنب كسر كفاءة React.memo.
6. لا تغير نوع وسوم الـ HTML المشروطة: تجنب التبديل بين <div> و <span> ديناميكياً لنفس المكون لأن ذلك يدمر شجرة الـ DOM الداخلية.
7. تعلم من معمارية clientId في جوتنبرج: افهم كيف تدير النواة قائمة البلوكات واقتبس نفس النمط المعماري في قوائمك الفرعية.
8. افصل دورة الحساب (Render) عن دورة التطبيق (Commit): حافظ على نظافة دالة المكون من الآثار الجانبية واجعلها دالة نقية ترجع JSX فقط.
9. اختبر إعادة الترتيب والسحب والإفلات يدوياً: تأكد من أن تحريك العناصر للأعلى والأسفل يحتفظ بنصوصها ومؤشرات الكتابة بداخلها بدقة.
10. استخدم React DevTools Profiler دورياً: راقب أزمنة الـ Render ومسببات إعادة الرسم واقضِ على الـ Wasteful Renders في مهدها.

معمارية الـ ContentEditable وتحديات Reconciliation في RichText

يا صديقي المطور، من أصعب التحديات التقنية في نواة Gutenberg هي كيفية إدارة مكون RichText أثناء عمليات الـ Reconciliation. السبب في ده هو أن RichText لا يعتمد على وسم <input> أو <textarea> عادي، بل يعتمد على سمة contenteditable=”true” في متصفح الويب!

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

• انعكاس اتجاه النص (Text Direction Flickering) بين العربية والإنجليزية.
• فقدان مكان مؤشر الكتابة وعودته لأول السطر مع كل حرف جديد.
• تكرار الحروف المكتوبة (Duplicate Keystrokes) في لوحات المفاتيح العربية على الموبايل.

نظام الأحداث الاصطناعية (Synthetic Events) وعزل التفاعل:

لتفادي هذه الكارثة، قام مهندسو ووردبريس ببناء طبقة حماية عازلة تعتمد على React Synthetic Events. تقوم هذه الطبقة بتعليق تدخل الـ Reconciliation المباشر أثناء كتابة المستخدم المستمرة، وتكتفي بتسجيل التغييرات في الذاكرة الحية، حتى يرفع المستخدم يده عن لوحة المفاتيح لبضع أجزاء من الثانية (Debounced State Commit)، فتقوم React حينها بتحديث حالة البلوك بسلاسة دون أن يشعر الكاتب بأي تأخير أو اهتزاز في المؤشر.