الأسئلة الشائعة حول الخطافات في React

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

تجيب هذه الصفحة عن بعض الأسئلة التي يتكرر طرحها حول الخطافات.

خطة التبني

أي إصدار من React يتضمن الخطافات؟

بدءًا من الإصدار 16.8.0، تضمنت React تنفيذًا مستقرًا للخطافات من أجل:

• الكائن ReactDOM
• الكائن ReactDOMServer
• مصيِّر React السطحي (Shallow Renderer)

ستدعم ReactNative الخطافات دعمًا كاملًا في الإصدار المستقر القادم.

هل احتاج إلى إعادة كتابة جميع مكونات الأصناف الخاصة بي؟

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

ما الذي يمكنني فعله مع الخطافات ولا يمكنني فعله مع الأصناف؟

توفر الخطافات وسيلةً جديدةً تتسم بالقوة لإعادة استعمال دالة (وظيفة ما) بين المكونات. توثيق "بناء خطاف خاص بك" يعطيك لمحةً عن ما هو ممكن فعله مع الخطافات. تشرح هذه المقالة الي نشرها أحد أفراد فريق React الأساسيين بنظرة تفصيلية الآفاق التي فُتحَت أمامنا بتوفير الخطافات في React.

ما هي نسبة المعرفة التي بقيت على صلة بـ React فيما يخص الخطافات؟

الخطافات هي طريقة مباشرة لاستعمال ميزات React التي تعرفها مسبقًا مثل الحالة، ودورة الحياة، والسياق، والمراجع (refs). إنها لم تغيِّر بشكل أساسي كيفية عمل Raect، ومعرفتك بالمكونات والخاصيات، وتدفق البيانات من الأعلى إلى الأسفل (top-down data flow) ستبقى كما هي ولن تتغير.

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

هل يتوجب علي استعمال الخطافات، أم الأصناف، أو كلاهما؟

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

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

هل تغطي الخطافات جميع حالات الاستخدام التي توفرها الأصناف؟

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

ما زالت الخطافات حديثة العهد، وقد لا تتوافق بعض المكتبات الموفرة من طرف ثالث معها في الوقت الحالي.

هل تستبدل الخطافات تصيير الخاصيات والمكونات ذات الترتيب الأعلى؟

غالبًا، خاصيات التصيير والمكونات ذات الترتيب الأعلى تُصيَّر ابنًا واحدًا فقط. نعتقد أنَّ الخطافات هي وسيلة بسيطة لتخدم حالة الاستخدام هذه. لا يزال هنالك متسعٌ لكلا النمطين (قد يملك مكون scroller افتراضي مثلًا الخاصية renderItem أو قد يملك مكون container حاوي على هيكلة DOM خاصة به)؛ ولكن في معظم الحالات، ستكون الخطافات كافية ويمكنها أن تساعد في تقليل التشعب في شجرتك.

ما الذي تعينه الخطافات بالنسبة للواجهات البرمجية الشهيرة مثل connect() في مكتبة Redux ومكتبة React Router؟

يمكنك الاستمرار باستعمال الواجهات البرمجية نفسها التي تستعملها عادةً، إذ ستستمر بالعمل دون أية مشكلات.

في المستقبل، قد تصدر إصدارات جديدة من هاتين المكتبتين خطافات مخصصة مثل useRedux() أو useRouter() تمكنك من استعمال نفس الميزات دون الحاجة إلى مكونات مغلفة.

هل تعمل الخطافات مع أنواع البيانات الثابتة (static typing)؟

صُمِّمَت الخطافات مع أخذ الأنواع الثابتة بالحسبان. لمَّا كانت الخطافات دوالًا، فإنها أسهل للكتابة وبشكل صحيح من أنماط أخرى مثل المكونات ذات المستوى الأعلى. تتضمن أحدث تعريفات للأداة Flow و TypeScript في React دعمًا للخطافات.

الأهم من ذلك أنَّ الخطافات المخصصة تمنحك القوة لتقييد واجهة React البرمجية إن أردت كتابتها بشكل صارم بطريقة ما. توفر لك React الأنواع الأساسية (primitives). ولكن يمكنك الدمج بينها بطرائق عدة أكثر من الطرائق الغير تقليدية التي وفرناها.

كيف يمكن اختبار المكونات التي تستعمل الخطافات؟

من وجهة نظر React، المكونات التي تستعمل الخطافات هي مكونات عادية تمامًا. إن لم يكن خيار الاختبار الخاص بك يعتمد على DOM الافتراضي وكائنات React الداخلية (أي React internals)، يجب ألا تختلف عملية اختبار المكونات مع الخطافات عن تلك التي اعتدت على استعمالها عادةً لاختبار المكونات.

على سبيل المثال، دعنا نفترض أنه لدينا مكون العداد (counter) التالي:

function Example() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

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

import React from 'react';
import ReactDOM from 'react-dom';
import { act } from 'react-dom/test-utils';
import Counter from './Counter';

let container;

beforeEach(() => {
  container = document.createElement('div');
  document.body.appendChild(container);
});

afterEach(() => {
  document.body.removeChild(container);
  container = null;
});

it('can render and update a counter', () => {
  // اختبر أول تصيير وتأثير
  act(() => {
    ReactDOM.render(<Counter />, container);
  });
  const button = container.querySelector('button');
  const label = container.querySelector('p');
  expect(label.textContent).toBe('You clicked 0 times');
  expect(document.title).toBe('You clicked 0 times');

  // اختبر ثاني تصيير وتأثير
  act(() => {
    button.dispatchEvent(new MouseEvent('click', {bubbles: true}));
  });
  expect(label.textContent).toBe('You clicked 1 times');
  expect(document.title).toBe('You clicked 1 times');
});

الاستدعاءات act() تطبِّق أيضًا التأثيرات داخلها.

إن أردت اختبار خطاف مخصص، يمكنك فعل ذلك عبر إنشاء مكون في اختبارك، واستعمال ذلك الخطاف منه. وتستطيع بعدئذٍ اختبار المكون الذي كتبته.

لتقليل الشيفرة المتداولة (boilerplate)، نوصي باستعمال المكتبة react-testing-library التي صُمِّمَت لتشجيع كتابة اختبارات تستعمل مكوناتك كما سيفعل المستخدم النهائي.

ما الذي يحصل بالضبط عند فرض تطبيق قواعد إضافة تصحيح الأخطاء ESLint؟

نوفر الإضافة ESLint التي تفرض تطبيق القواعد الخاصة بالخطافات عليها لتجنب حصول أية أخطاء. إنها تفترض أن أية دالة تبدأ بالسابقة use ثم يليها حرف كبير هي خطاف. نحن ندرك أنَّ هذه الطريقة للتعرف على الخطافات ليست مثالية وقد يكون هنالك بعض الإيجابيات الزائفة (false positives)، ولكن بدون عرف نتشر في بيئة العمل (ecosystem-wide convention)، ليس هنالك أية وسيلة لجعل الخطافات تعمل بشكل صحيح. أضف إلى ذلك أن الأسماء الطويلة ستحبِّط الآخرين من إمَّا تبني الخطافات واستعمالها أو اتباع ما هو متعارف عليه.

باختصار، فرض تطبيق القواعد هي:

• استدعاء الخطافات إمَّا داخل دالة PascalCase (افترض كونها مكونًا) أو دالة useSomething أخرى (افترض كونها خطافًا مخصصًا).
• تُستدعَى الخطافات بالترتيب نفسه في كل عملية تصيير.

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

من الأصناف إلى الخطافات

كيف تتوافق توابع دورة الحياة مع الخطافات؟

• constructor: لا تحتاج مكونات دالة إلى باني. يمكنك تهيئة الحالة عبر استدعاء الخطاف useState. إن كان حسابها بشكل عبئًا على الأداء، فيمكنك تمرير دالة إلى useState.
• getDerivedStateFromProps: تحل جدول تحديث أثناء التصيير مكانه.
• shouldComponentUpdate: اطلع على React.memo في الأسفل.
• render: هذا التابع هو جسم مكون الدالة نفسها.
• componentDidMount، و componentDidUpdate، و componentWillUnmount: يحل الخطاف useEffect مكان هذه التوابع بشتى أشكال دمجها مع بعضها (بما فيها الحالات النادرة).
• componentDidCatch، و getDerivedStateFromError: ليس هنالك أي خطاف مكافئ لهذين التابعين بعد، ولكن سيُضَاف في القريب العاجل.

هل هنالك شيء شبيه بمتغيرات النسخة؟

نعم. الخطاف useRef() ليس مخصص لمراجع DOM فقط. الكائن ref هو حاوية عامة (generic container)، إذ الخاصية current فيه قابلةٌ للتعديل وتستطيع تخزين أية قيمة بشكل مشابه لنسخة أية خاصية في صنف ما. يمكنك الوصول إليها من داخل useEffect:

function Timer() {
  const intervalRef = useRef();

  useEffect(() => {
    const id = setInterval(() => {
      // ...
    });
    intervalRef.current = id;
    return () => {
      clearInterval(intervalRef.current);
    };
  });

  // ...
}

إن أردنا ضبط فترة زمنية (interval)، لن نحتاج إلى المرجع ref (المعرف id يمكن أن يكون محليًّا نسةب للتأثير)، ولكن من المفيد لو أردنا تصفير الفترة الزمنية من داخل معالج الحدث:

  // ...
  function handleCancelClick() {
    clearInterval(intervalRef.current);
  }
  // ...

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

هل يجب أن استعمل متغير حالة واحد أم عدة متغيرات؟

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

function Box() {
  const [state, setState] = useState({ left: 0, top: 0, width: 100, height: 100 });
  // ...
}

الآن، لنقل أننا نريد كتابة جزء من شيفرة تغيِّر left و top عندما يحرك المستخدم مؤشر الفأرة. لاحظ كيف يتوجب علينا دمج هذين الحقلين في كائن الحالة السابقة يدويًّا:

  // ...
  useEffect(() => {
    function handleWindowMouseMove(e) {
      // Spreading "...state" ensures we don't "lose" width and height
      setState(state => ({ ...state, left: e.pageX, top: e.pageY }));
    }
    // Note: this implementation is a bit simplified
    window.addEventListener('mousemove', handleWindowMouseMove);
    return () => window.removeEventListener('mousemove', handleWindowMouseMove);
  }, []);
  // ...

هذا بسببب أنه استبدلنا قيمة متغير حالة عندما حدثناها. هذا الأمر مخلف عن this.setState في الأصناف التي تدمج الحقول المحدَّثة . على أي حال، نوصي بدلًا من ذلك بتقسيم الحالة إلى متغيرات حالة متعددة اعتمادًا على القيم التي تتغير سويةً. على سبيل المثال، يمكنا تقسيم حالة مكوننا إلى الكائنين position و size، واستبدال position دون الحاجة للدمج:

function Box() {
  const [position, setPosition] = useState({ left: 0, top: 0 });
  const [size, setSize] = useState({ width: 100, height: 100 });

  useEffect(() => {
    function handleWindowMouseMove(e) {
      setPosition({ left: e.pageX, top: e.pageY });
    }
    // ...

فصل متيغرات حالة مستقلة له فائدة أخرى هي تسهيل استخراج جزء من مترابط من الشيفرة إلى خطاف مخصص لاحقًا مثل:

function Box() {
  const position = useWindowPosition();
  const [size, setSize] = useState({ width: 100, height: 100 });
  // ...
}

function useWindowPosition() {
  const [position, setPosition] = useState({ left: 0, top: 0 });
  useEffect(() => {
    // ...
  }, []);
  return position;
}

لاحظ كيف كان بإمكاننانقل الاستدعاء useState من متغير الحالة position والتأثير المرتبط به إلى خطاف مخصص دون تغيير الشيفرة. إن كانت جميع متغيرات الحالة في كائن واحد، فسيَصعُب استخراجها.

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

هل يمكنني تنفيذ تأثير عند حصول تحديثات فقط؟

هذه حالة استعمال نادرة. إن احتجت إليها، يمكنك استعمال مرجعٍ قابل للتعديل لتخزين قيمة منطقية يدويًّا تشير إمَّا إلى كونك في أول عملية تصيير أو في عملية تصيير تالية ثم التحقق من هذه الراية في التأثير الخاص بك. (إن وجدت نفسك معتادًا على فعل هذا الأمر، يمكنك أن تنشئ خطافًا مخصصًا لذلك.)

كيف يمكن جلب الخاصية أو الحالة السابقة؟

في الوقت الحالي، يمكنك فعل ذلك يدويًّا باستعمال مرجع:

function Counter() {
  const [count, setCount] = useState(0);

  const prevCountRef = useRef();
  useEffect(() => {
    prevCountRef.current = count;
  });
  const prevCount = prevCountRef.current;

  return <h1>Now: {count}, before: {prevCount}</h1>;
}

قد تبدو هذه العملية معقدةً بعض الشيء ولكن يمكنك استخراجها إلى خطاف مخصص:

function Counter() {
  const [count, setCount] = useState(0);
  const prevCount = usePrevious(count);
  return <h1>Now: {count}, before: {prevCount}</h1>;
}

function usePrevious(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

لاحظ كيف سيعمل هذا من أجل الخاصيات، أو الحالات، أو أية قيمة أخرى محسوبة:

function Counter() {
  const [count, setCount] = useState(0);

  const calculation = count * 100;
  const prevCalculation = usePrevious(calculation);
  // ...

واردٌ في المستقبل أن توفر React خطافًا يدعى usePrevious مثلًا لفعل ذلك، إذ هذا السلوك شائع نسبيًا.

انظر أيضًا إلى السؤال التالي للاطلاع على النمط الموصى به من أجل الحالة المشتقة.

كيف أنفِّذ getDerivedStateFromProps؟

رغم أنك لن تحتاج إليه على الأرجح، فيمكنك في حالات نادرة فعل ذلك (مثل تنفيذ المكون <Transition>) عبر تحديث الحالة بشكل صحيح أثناء عملية التصيير. ستعيد React تنفيذ المكون مع الحالة المحدَّثة مباشرةً بعد الخروج من أول عملية تصيير، لذا لن يؤثر ذلك على الأداء.

في الشيفرة التالية، نخزِّن القيمة السابقة للخاصية row في متغير حالة، ويمكننا بذلك إجراء عملية موازنة:

function ScrollView({row}) {
  let [isScrollingDown, setIsScrollingDown] = useState(false);
  let [prevRow, setPrevRow] = useState(null);

  if (row !== prevRow) {
    // isScrollingDown تغيرت منذ أخرى عملية تصيير. حدِّث  row الخاصية
    setIsScrollingDown(prevRow !== null && row > prevRow);
    setPrevRow(row);
  }

  return `Scrolling down: ${isScrollingDown}`;
}

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

هل يوجد شيء يشبه forceUpdate؟

الخطافان useState و useReducer كلاهما يحافظان على الحالة عند إجراء تحديث عليها في حال كانت القيمة التالية هي نفس القيمة السابقة. تغيير الحالة يدويًّا (in place) واستدعاء الخطاف useState لن يؤدي إلى إعادة التصيير.

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

  const [ignored, forceUpdate] = useReducer(x => x + 1, 0);

  function handleClick() {
    forceUpdate();
  }

حاول تجنب هذه النمط قدر المستطاع.

هل يمكنني إنشاء مرجع إلى مكون دالة؟

رغم أنّه لا يجب أن تحتاج إلى تنفيذ ذلك في أغلب الأحيان، قد تعرض بعض التوابع الأمرية على مكون أب (parent component) مع الخطاف useImperativeHandle.

ما الذي يعينه const [thing, setThing] = useState()؟

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

تحسينات الأداء

هل يمكنني تخطي تأثير في عمليات التحديث؟

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

كيف يمكنني تنفيذ shouldComponentUpdate؟

يمكنك تغليف مكون دالة مع React.memo لموازنة خاصياته بشكل سطحي:

const Button = React.memo((props) => {
  // المكون الخاص بك
});

هذا ليس خطافًا لأنه لم يُنشَأ بالشكل الذي تُنشَأ فيه الخطافات. إنَّ React.memo يكافئ PureComponent ولكن يوازن الخاصيات فقط. (يمكنك أيضًا أن تضيف وسيطًا آخر لتحديد دالة موازنة مخصصة تأخذ الخاصيات القديمة والجديدة. إن أعادت القيمة true، فسيُتخطَّى التحديث.)

لا يوازن React.memo الحالة لعدم وجود كائن حالة وحيد لموازنته. مع ذلك، يمكنك جعل الأبناء في حالة نقية (pure) أيضًا أو حتى تحسين ابنٍ واحدٍ مع useMemo.

كيف يمكن استظهار (memoize) العمليات الحسابية؟

الخطاف useMemo يمكِّنك من تخزين الحسابات بين عدة عمليات تصيير عبر "تذكر" القيمة التي جرى حسابها مسبقًا:

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

تستدعي هذه الشيفرة computeExpensiveValue(a, b) ولكن إن لم تتغير المدخلات [a, b] منذ آخر قيمة، سيتخطى الخطاف useMemo استدعاءها في المرة التالية ويعيد استعمال آخر قيمة أعادتها تلك الدالة.

تذكر أن الدالة المُمرَّرة إلى useMemo تُنفَّذ أثناء عملية التصيير. لا تفعل أي شيء في هذه الأثناء لم تكن لتفعله بشكل طبيعي خلال عملية التصيير. على سبيل المثال، التأُثيرات الجانبية تتبع للخطاف useEffect وليس للخطاف useMemo.

يمكنك الاعتماد على الخطاف useMemo لتحسين الأداء، وليس لضمان الدلالات (semantic guarantee). في المستقبل، قد تختار React بأن "تنسى" بعض القيم المُستظهَرة (المحفوظة) وتعيد حسابها من جديد في عملية التصيير التالية وذلك لتحرير الذاكرة لمكونات غير ظاهرة على الشاشة (offscreen) مثلًا. اكتب أولًا شيفرتك لتعمل بشكل صحيح دون الخطاف useMemo، ومن ثمَّ أضفه لتحسين الأداء. (في حالات نادرة عندما لا يجب حساب قيمة مطلقًا، يمكنك حينئذٍ تهيئة مرجع بشكل كسول.)

أضف إلى ذلك أن الخطاف useMemo يمكِّنك بسهولة من تخطي عملية إعادة تصيير لابن مستنزفة للأداء:

function Parent({ a, b }) {
  // فقط `a` أعد عملية التصيير إن تغير:
  const child1 = useMemo(() => <Child1 a={a} />, [a]);
  // فقط `b` أعد عملية التصيير إن تغير:
  const child2 = useMemo(() => <Child2 b={b} />, [b]);
  return (
    <>
      {child1}
      {child2}
    </>
  )
}

لاحظ أنَّ هذا الأسلوك لن يعمل في حلقة تكرار لأنه لا يمكن أن توضع استدعاءات الخطافات داخل حلقة تكرار. على أي حال، تستطيع استخراج مكون منفصل لعنصر القائمة واستدعاء useMemo هنالك.

كيف يمكن إنشاء كائنات مستنزفة للأداء بشكل كسول؟

يمكِّنك الخطاف useMemo من استظهار (memoize) عملية حسابية مستهلكة للأداء إن بقيت المدخلات نفسها دون تغيُّر. مع ذلك، يعدُّ هذا بمثابة تلميح فقط، ولا يوجد أي شيء يضمن عدم تكرار تنفيذ العملية الحسابية. على أية حال، تحتاج أحيانًا إلى التأكد من إنشاء كائنٍ مرةً واحدةً فقط.

أول حالة استعمال شائعة هي عند كون عملية إنشاء الحالة الأولية مستهلكة للأداء:

function Table(props) {
  // ⚠️ في كل عملية تصيير createRows() يستدعى
  const [rows, setRows] = useState(createRows(props.count));
  // ...
}

لتجنب إعادة إنشاء الحالة الأولية المهملة، يمكننا تمرير دالة إلى useState:

function Table(props) {
  // ✅ مرة واحدة فقط createRows() يستدعى
  const [rows, setRows] = useState(() => createRows(props.count));
  // ...
}

ستستدعي React هذه الدالة خلال عملية أول عملية تصيير. لمزيد من التفاصيل، ارجع إلى توثيق الواجهة البرمجية للخطاف useState. في بعض الأحيان، ربما ترغب بتجنب إعادة إنشاء الحالة الأولية للخطاف useRef(). على سبيل المثال، ربما تريد التأكد من إنشاء بعض نسخ الأصناف الأمرية (imperative class instance) مرةً واحدةً فقط:

function Image(props) {
  // ⚠️ في كل عملية تصيير IntersectionObserver يُنشَأ
  const ref = useRef(new IntersectionObserver(onIntersect));
  // ...
}

لا يقبل الخطاف useRef دالة مخصصة إضافية مثل الخطاف useState. عوض ذلك، تستطيع كتابة دالة مخصصة تُنشئها وتضبطها بشكل كسول:

function Image(props) {
  const ref = useRef(null);

  // ✅ ٍمرةً واحدةً بِكَسَل IntersectionObserver يُنشَأ
  function getObserver() {
    let observer = ref.current;
    if (observer !== null) {
      return observer;
    }
    let newObserver = new IntersectionObserver(onIntersect);
    ref.current = newObserver;
    return newObserver;
  }

  // عندما تحتاج إليه getObserver() استدعي
  // ...
}

بذلك، تتجنب إنشاء كائنات مستهلكة للأداء حتى الحاجة الماسة إليها للمرة الأولى. إن كنت تستعمل Flow أو TypeSctipt، تستطيع أيضًا أن تعطي getObserver() نوعًا غير معدوم (non-nullable type) للسهولة.

هل تتسم الخطافات بالبطئ لإنشائها دوالًا في عملية التصيير؟

لا. في المتصفحات الحديثة، لا يختلف الأداء الصافي (raw performance) للمغلفات (closures) موازنةً مع الأصناف اختلافًا كبيرًا باستثناء الحالات المبالغ بها.

إضافةً لذلك، يعد تصميم الخطافات أكثر فعالية من ناحيتين هما:

• تخلصت الخطافات من الكثير من الأعباء التي تطلبها الأصناف مثل عبء طلب إنشاء نُسخٍ للصنف وربط معالجات حدث بالباني.
• لا تحتاج الشيفرة الاصطلاحية (Idiomatic code) التي تستعمل الخطافات إلى التشعب العميق لشجرة المكونات (deep component tree nesting) السائد في قواعد الشيفرة (codebases) التي تستعمل المكوانات ذات الترتيب الأعلى، وخاصييات التصيير، والسياق. مع شجرة مكونات صغيرة، يكون لدى React القليل من العمل لإنجازه.

تقليديًّا، المخاوف التي تدور حول الدوال السطرية (inline functions) وتأثيرها على الأداء في React تتعلق بكيفية تمرير ردود النداء الجديدة في كل تصيير يفصل تحسينات shouldComponentUpdate في المكونات الأبناء. تتعامل الخطافات مع هذه المشكلة من ثلاث نواحٍ هي:

• يمكِّنك الخطاف useCallback من الإبقاء على مرجع رد النداء نفسه بين عمليات إعادة التصيير، لذا يستمر shouldComponentUpdate بالعمل:

// `b` أو `a` لن يتغير إلا إذا تغير
const memoizedCallback = useCallback(() => {
  doSomething(a, b);
}, [a, b]);

• يجعل الخطاف useMemo عملية التحكم سهلةً عندما يَجرِي تحديث ابنٍ واحدٍ، مما يقلل من الحاجة إلى مكونات نقية (pure components).
• أخيرًا، يقلل الخطاف useReducer الحاجة إلى تمرير ردود نداء عميقة كما سيُشرَح ذلك في الأسفل.

ما هو السبيل لتجنب تمرير ردود النداء للداخل؟

وجدنا أن أغلب الأشخاص لا يحبون تمرير ردود النداء يدويًا عبر كل مستوى من شجرة المكون. رغم أن العملية واضحة إلا أنه أشبه بعملية تركيب شبكة من الأنابيب المتشعبة (أنابيب شبكة المياه والصرف مثلًا).

في شجرات المكون الكبيرة، البديل الذي نوصي به هو تمرير الدالة dispatch للداخل (down) من useReducer عبر السياق:

const TodosDispatch = React.createContext(null);

function TodosApp() {
  // لن تتغير بين عمليات إعادة التصيير `dispatch` الدالة
  const [todos, dispatch] = useReducer(todosReducer);

  return (
    <TodosDispatch.Provider value={dispatch}>
      <DeepTree todos={todos} />
    </TodosDispatch.Provider>
  );
}

أي ابن في الشجرة داخل TodosApp يمكن أن يستخدم الدالة dispatch لتمرير أحداث (actions) للأعلى حتى تصل إلى TodosApp:

function DeepChild(props) {
  // من السياق dispatch إذا أردنا أن ننفذ حدثًا ما، يمكننا جلب
  const dispatch = useContext(TodosDispatch);

  function handleClick() {
    dispatch({ type: 'add', text: 'hello' });
  }

  return (
    <button onClick={handleClick}>Add todo</button>
  );
}

هذا مناسبٌ أكثر من ناحية الصيانة (لا حاجة للاستمرار بتوجيه ردود النداء)، ويجنبنا من الوقوع في مشكلة رد النداء (callback problem) كليًّا. تمرير dispatch للأسفل بالشكل الذي وضحناه هو النمط الذي ينصح باتباعه للتحديثات العميقة.

الجدير بالملاحظة أنَّه لا يزال بإمكانك اختيار إما إن تمرِّر حالة التطبيق (application state) للأسفل مثل الخاصيات (الأكثر وضوحًا) أو مثل السياق (أكثر سهولةً للتحديثات العميقة جدًا). إن كنت تستعمل السياق لتمرير الحالة للأسفل أيضًا، استعمل نوعان مختلفان من السياق، إذ لا يتغير السياق dispatch مطلقًا؛ لذلك، لا تحتاج المكونات التي تقرأه للتصيير إلا إذا احتاجت أيضًا إلى حالة التطبيق.

كيف تجري عملية قراءة قيمة تتغير كثيرًا من الخطاف useCallback؟

ملاحظة: نوصي بتمرير dispatch للأسفل في السياق. بدلًا من ردود النداء الفردية في الخاصيات. الطريقة المتبعة في الأسفل مذكورة هنا فقط كتتمة وكمخرج هروب (escape hatch).

لاحظ أيضًا أن هذا النمط قد يسبب حدوث مشاكل في الوضع المتزامن (concurrent mode). نخطط لتوفير بدائل أفضل في المستقبل، ولكن الحل الأكثر أمانًا الأن هو إبطال رد النداء دومًا إن تغيرت بعض القيم التي يعتمد عليها.

في حالات نادرة، قد تحتاج إلى استظهار (memoize) رد نداء مع الخطاف useCallback ولكن عملية الاستظهار لا تعمل بشكل صحيح لأن الدالة الداخلية يجب أن يعاد إنشاؤها في كثير من الأحيان. إن كانت الدالة التي تريد استظهارها هي معالج حدث ولا تستخدم أثناء التصيير، يمكنك استعمال مرجع كمتغير نسخة، ,وتخزين آخر قيمة محفوظة ضمنه يدويًا:

function Form() {
  const [text, updateText] = useState('');
  const textRef = useRef();

  useLayoutEffect(() => {
    textRef.current = text; // كتابتها إلى المرجع
  });

  const handleSubmit = useCallback(() => {
    const currentText = textRef.current; // قراءتها من المرجع
    alert(currentText);
  }, [textRef]); // [text] كما ستفعل handleSubmit لا تعيد إنشاء

  return (
    <>
      <input value={text} onChange={e => updateText(e.target.value)} />
      <ExpensiveTree onSubmit={handleSubmit} />
    </>
  );
}

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

function Form() {
  const [text, updateText] = useState('');
  //  `text` سيجري استظهاره حتى لو تغير:
  const handleSubmit = useEventCallback(() => {
    alert(text);
  }, [text]);

  return (
    <>
      <input value={text} onChange={e => updateText(e.target.value)} />
      <ExpensiveTree onSubmit={handleSubmit} />
    </>
  );
}

function useEventCallback(fn, dependencies) {
  const ref = useRef(() => {
    throw new Error('Cannot call an event handler while rendering.');
  });

  useLayoutEffect(() => {
    ref.current = fn;
  }, [fn, ...dependencies]);

  return useCallback(() => {
    const fn = ref.current;
    return fn();
  }, [ref]);
}

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

ما خلف الستار

كيف تربط React استدعاءات الخطافات مع المكونات؟

تتعقب React المكونات قيد التصيير باستمرار. بفضل القواعد المخصصة بالخطافات، أصبحنا نعلم كيف تستدَعى تلك الخطافات من مكونات React (أو من الخطافات المخصصة التي تُستدعَى أيضًا من مكونات React).

هنالك قائمة داخلية لخلايا في الذاكرة مرتبطة مع كل مكون. هي عبارة عن كائنات JavaScript نستطيع أن نضع فيها بعض البيانات. عندما تستدعي خطافًا مثل useState()، يقرأ الخلية الحالية (أو يهيِّئها أثناء أول عملية تصيير)، ثم يحرِّك المؤشر إلى الخلية التالية. هذا هو تفسير حصول كل استدعاء من استدعاءات الخطاف useState() حالة محلية مستقلة.

ما هو المصدر الذي استقيت من الخطافات؟

الخطافات هي فكرة متراكبة ومستقاة من مصادر مختلفة منها:

• تجربتنا المسبقة مع الواجهات الوظيفية البرمجية (functional APIs) في المستودع react-future.
• تجارب مجتمع React مع واجهات خاصيات التصيير البرمجية بما فيها المكون Reactions الذي يخص Ryan Florence.
• اقتراح الكلمة المفتاحية adopt التي اقترحها Dominic Gannaway كصياغة تجميلية لخاصيات التصيير.
• متغيرات الحالة وخلايا الحالة في DisplayScript.
• المكونات Reducer في ReasonReact.
• الاشتراكات في Rx.
• التأثيرات الجبرية في لغة OCaml متعددة النوى.

ابتكر Sebastian Markbåge التصميم الأساسي للخطافات ثم أعيد تنقيح وصقله لاحقًا من قبل Andrew Clark، و Sophie Alpert، و Dominic Gannaway، وغيرهم من أعضاء فريق React.

 انظر أيضًا

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

مصادر

• صفحة الأسئلة الشائعة حول الخطافات في توثيق React الرسمي.