React/hooks faq

الخطافات هي إضافة جديدة إلى الإصدار 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 الحاجة إلى تمرير ردود نداء عميقة كما سيُشرَح ذلك في الأسفل.