We want to hear from you!Take our 2021 Community Survey!
This site is no longer updated.Go to react.dev
React
إصدار 18.2.0 اللّغاتGitHub

الأسئلة الشائعة حول الـ Hooks

These docs are old and won’t be updated. Go to react.dev for the new React docs.

The new documentation pages teaches React with Hooks.

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

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

خطة تبني الخطافات

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

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

  • React DOM
  • React Native
  • React DOM Server
  • React Test Renderer
  • React Shallow Renderer

لاحظ أن لتمكين الخطافات ، يجب أن تكون جميع حزم 16.8.0 React أو أعلى. لن تعمل الخطافات إذا نسيت التحديث ، على سبيل المثال ، React DOM.

الاصدار React Native 0.59 وما بعد يدعم الخطافات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

React Redux since v7.1.0 supports Hooks API and exposes hooks like useDispatch or useSelector.

React Router supports hooks since v5.1.

Other libraries might support hooks in the future too.

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

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

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

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

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

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

ملاحظة

Testing Recipes تحتوي على بعض الأمثلة التي يمكنك استخدامها.

على سبيل المثال، دعنا نفترض أنه لدينا مكون العداد (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/client';
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.createRoot(container).render(<Counter />);  });  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 التي صُمِّمَت لتشجيع كتابة اختبارات تستعمل مكوناتك كما سيفعل المستخدم النهائي.

لمزيد من المعلومات، تصفح Testing Recipes.

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

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

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

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

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

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

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

  • constructor: لا تحتاج مكونات دالة إلى باني. يمكنك تهيئة الحالة عبر استدعاء الخطاف useState. إن كان حسابها يشكل عبئًا على الأداء، فيمكنك تمرير دالة إلى useState.
  • getDerivedStateFromProps: تحل مكان جدولة تحديثٍ أثناء التصيير. instead.
  • shouldComponentUpdate: اطلع على React.memo في الأسفل..
  • render: هذا التابع هو جسم مكون الدالة نفسها.
  • componentDidMount, componentDidUpdate, componentWillUnmount: يحل الخطاف useEffect مكان هذه التوابع بشتى أشكال دمجها مع بعضها (بما فيها الحالات النادرة).
  • getSnapshotBeforeUpdate, 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) {
      // عدم فقدان الارتفاع والعرض "...state" نتأكد بنشر      setState(state => ({ ...state, left: e.pageX, top: e.pageY }));    }
    // ملاحظة: هذا لتنفيذ بسيط جدًا
    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 بكل حقل أمران يمكن تطبيقهما بشكل صحيح. تميل المكونات لتكون أكثر قابلية للقراءة عند تحقيق التوازن بين هذين النقيضين، وتجميع كل ما يرتبط بالحالة في بضعة متغيرات حالة مستقلة. إن أصبحت شيفرة الحالة معقدة، نوصي بإدارتها باستعمال مخفض أو خطاف مخصص.

هل يمكنني تنفيذ تأثير عند إجراء التحديثات فقط؟

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

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

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

Sometimes, you need previous props to clean up an effect. For example, you might have an effect that subscribes to a socket based on the userId prop. If the userId prop changes, you want to unsubscribe from the previous userId and subscribe to the next one. You don’t need to do anything special for this to work:

useEffect(() => {
  ChatAPI.subscribeToSocket(props.userId);
  return () => ChatAPI.unsubscribeFromSocket(props.userId);
}, [props.userId]);

In the above example, if userId changes from 3 to 4, ChatAPI.unsubscribeFromSocket(3) will run first, and then ChatAPI.subscribeToSocket(4) will run. There is no need to get “previous” userId because the cleanup function will capture it in a closure.

Other times, you might need to adjust state based on a change in props or other state. This is rarely needed and is usually a sign you have some duplicate or redundant state. However, in the rare case that you need this pattern, you can store previous state or props in state and update them during rendering.

We have previously suggested a custom Hook called usePrevious to hold the previous value. However, we’ve found that most use cases fall into the two patterns described above. If your use case is different, you can hold a value in a ref and manually update it when needed. Avoid reading and updating refs during rendering because this makes your component’s behavior difficult to predict and understand.

لماذا أرى الخصائص قديمة أو الحالة داخل الدالة؟

أي دالة داخل مكون ، بما في ذلك معالجات الأحداث والتأثيرات ، “ترى” الخصائص والحالة من تصيير الذي تم إنشاؤه فيه. على سبيل المثال ، أنظر إلى شيفرة التالية:

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

  function handleAlertClick() {
    setTimeout(() => {
      alert('You clicked on: ' + count);
    }, 3000);
  }

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
      <button onClick={handleAlertClick}>
        Show alert
      </button>
    </div>
  );
}

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

إذا كنت تريد قرائة آخر حالة من بعض رد الاتصال غير متزامن عن قصد، يمكنك الاحتفاظ به في مرجع, تحويله ، وقراءة منه.

أخيرًا , هناك سبب آخر محتمل لرأيتك الخصائص القديمة أو الحالة, هي إذا كنت تستخدم تحسين ” التبعية المصفوفة” ولكنك لم تحدد جميع التبعيات بشكل صحيح. على سبيل المثال ، إذا حدد التأثير [] الوسيطة الثانية ولكن يقرأ someProp في الداخل ، فسوف يحتفظ بـ“ رؤية ”القيمة الأولية لـsomeProp. الحل هو إزالة صفيف التبعية أو إصلاحه. من هنا كيف يمكنك التعامل مع الدوال, وهنا استراتيجيات شائعة أخرى   لتشغيل التأثيرات في كثير من الأحيان دون تخطي التبعيات بشكل غير صحيح.

ملاحظة

نحن نقدم exhaustive-deps قاعدة ESLint كجزء من حزمة eslint-plugin-react-hooks. يحذر عندما يتم تحديد التبعيات بشكل غير صحيح ويقترح إصلاح.

كيف أنفِّذ getDerivedStateFromProps؟

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

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

function ScrollView({row}) {
  const [isScrollingDown, setIsScrollingDown] = useState(false);
  const [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.

كيف يمكنني قياس عقدة DOM؟

من أجل قياس موضع أو حجم عقدة DOM ، يمكنك استخدام مرجع رد النداء. تستدعي React رد النداء هذا كلما تم ربط المرجع بعقدة مختلفة. هنا عرض صغير:

function MeasureExample() {
  const [height, setHeight] = useState(0);

  const measuredRef = useCallback(node => {    if (node !== null) {      setHeight(node.getBoundingClientRect().height);    }  }, []);
  return (
    <>
      <h1 ref={measuredRef}>Hello, world</h1>      <h2>The above header is {Math.round(height)}px tall</h2>
    </>
  );
}

لم نختار useRef في هذا المثال لأن مرجع كائن لا يخطرنا بشأن * التغييرات * في قيمة المرجع الحالية. باستخدام المرجع رد النداء يضمن ذلك حتى لو عرض أحد العناصر التابعة العقدة المقاسة لاحقًا (e.g. in response to a click), ما زلنا نتلقى إشعارًا بذلك في المكون الرئيسي ويمكننا تحديث القياسات.

لاحظ أننا نقوم بتمرير [] كمصفوفة تبعية إلى useCallback . هذا يضمن أن رد النداء المرجعي الخاص بنا لا يتغير بين عمليات إعادة التصيير ، وبالتالي فإن React لن يناديها بشكل غير ضروري.

في هذا المثال، سيتم تطبيق دالة النداء المرجعي فقط في حالة وصل او فصل المكون، منذ تصيير الكون <h1> سيبقى موجود خلال أي تصيير آخر. اذا كنت ترغب بمراقبة تغيرات حجم المكون، يمكنك استخدام ResizeObserver

يمكنك اذا اردت استخراج هذا المنطق في خطاف قابلة لإعادة الاستخدام:

function MeasureExample() {
  const [rect, ref] = useClientRect();  return (
    <>
      <h1 ref={ref}>Hello, world</h1>
      {rect !== null &&
        <h2>The above header is {Math.round(rect.height)}px tall</h2>
      }
    </>
  );
}

function useClientRect() {
  const [rect, setRect] = useState(null);
  const ref = useCallback(node => {
    if (node !== null) {
      setRect(node.getBoundingClientRect());
    }
  }, []);
  return [rect, ref];
}

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

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

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

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

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

هل من الآمن حذف الدوال من قائمة التبعيات؟

بشكل عام ، لا.

function Example({ someProp }) {
  function doSomething() {
    console.log(someProp);
  }

  useEffect(() => {
    doSomething();
  }, []); // 🔴 This is not safe (it calls `doSomething` which uses `someProp`)
}

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

function Example({ someProp }) {
  useEffect(() => {
    function doSomething() {
      console.log(someProp);
    }

    doSomething();
  }, [someProp]); // ✅ OK (our effect only uses `someProp`)
}

إذا لم نستخدم بعد ذلك أي قيم من نطاق المكون ، فمن الآمن تحديد []:

useEffect(() => {
  function doSomething() {
    console.log('hello');
  }

  doSomething();
}, []); // ✅ OK in this example because we don't use *any* values from component scope

بناءً على حالة الاستخدام الخاصة بك ، هناك عدد قليل من الخيارات الموضحة أدناه.

ملاحظة

نحن نقدم exhaustive-deps قاعدة ESLint كجزء من حزمة eslint-plugin-react-hooks. هذه الحزمة تساعد على عثور المكونات التي لا تتعامل مع التحديثات باستمرار.

دعنا نرى لماذا هذا مهم.

إذا قمت بتحديد قائمة التبعيات كعامل أخير ل useEffect، useLayoutEffect، useMemo، useCallback. أو useImperativeHandle, يجب أن تتضمن جميع القيم المستخدمة داخل المشاركة في تدفق بيانات React. يتضمن الدعائم والدولة وأي شيء مستمد منها.

يكون من الآمن حذف وظيفة من قائمة التبعية إذا لم يكن أي منها (أو الوظائف التي تسمى بها) يشير إلى الدعائم أو الحالة أو القيم المستمدة منها. يحتوي هذا المثال على خطأ:

function ProductPage({ productId }) {
  const [product, setProduct] = useState(null);

  async function fetchProduct() {
    const response = await fetch('http://myapi/product/' + productId); // Uses productId prop
    const json = await response.json();
    setProduct(json);
  }

  useEffect(() => {
    fetchProduct();
  }, []); // 🔴 Invalid because `fetchProduct` uses `productId`
  // ...
}

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

function ProductPage({ productId }) {
  const [product, setProduct] = useState(null);

  useEffect(() => {
    // By moving this function inside the effect, we can clearly see the values it uses.
    async function fetchProduct() {
      const response = await fetch('http://myapi/product/' + productId);
      const json = await response.json();
      setProduct(json);
    }

    fetchProduct();
  }, [productId]); // ✅ Valid because our effect only uses productId
  // ...
}

يسمح لك هذا أيضًا بمعالجة الاستجابات غير المرتبة مع متغير محلي داخل التأثير:

 useEffect(() => {
    let ignore = false;
    async function fetchProduct() {
      const response = await fetch('http://myapi/product/' + productId);
      const json = await response.json();
      if (!ignore) setProduct(json);
    }
    
    fetchProduct();
    return () => { ignore = true };
  }, [productId]);

لقد نقلنا الوظيفة داخل التأثير حتى لا تكون في قائمة التبعية.

Tip

تحقق من هذا العرض التوضيحي الصغير و هذه المقالة لمعرفة المزيد حول جلب البيانات مع خطفات.

*إذا لم تتمكن من نقل وظيفة داخل تأثير ما لسبب ما ، فهناك بعض الخيارات الإضافية:

  • يمكنك محاولة نقل هذه الدالة خارج المكون الخاص بك. في هذه الحالة ، تكون الدالة مضمونة لعدم الإشارة إلى أي مواد دعائية أو حالة ، كما أنها لا تحتاج إلى أن تكون في قائمة التبعيات.
  • إذا كانت الدوال التي تتصل بها عبارة عن حساب محض وآمنة للاتصال أثناء العرض ، يمكنك الاتصال بها خارج التأثير بدلاً من ذلك ، وجعل التأثير يعتمد على القيمة التي تم إرجاعها.
  • كملجأ أخير ، يمكنك إضافة دالة للتأثير على التبعيات ولكن لف تعريفها في خطافuseCallback. هذا يضمن أنه لا يتغير في كل عرض ما لم تتغير التبعيات الخاصة به أيضًا:
function ProductPage({ productId }) {
  // ✅ Wrap with useCallback to avoid change on every render
  const fetchProduct = useCallback(() => {
    // ... Does something with productId ...
  }, [productId]); // ✅ All useCallback dependencies are specified

  return <ProductDetails fetchProduct={fetchProduct} />;
}

function ProductDetails({ fetchProduct }) {
  useEffect(() => {
    fetchProduct();
  }, [fetchProduct]); // ✅ All useEffect dependencies are specified
  // ...
}

لاحظ أننا في المثال أعلاه **نحتاج ** إلى الاحتفاظ ب الدوال في قائمة التبعيات. هذا يضمن أن أي تغيير في productId prop ل ProductPage يؤدي تلقائيًا إلى إعادة تعيين في مكون ProductDetails.

ماذا أفعل إذا تغيرت تبعيات التأثير الخاصة بي كثيرًا؟

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

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

  useEffect(() => {
    const id = setInterval(() => {
      setCount(count + 1); // This effect depends on the `count` state
    }, 1000);
    return () => clearInterval(id);
  }, []); // 🔴 Bug: `count` is not specified as a dependency

  return <h1>{count}</h1>;
}

مجموعة فارغة من التبعيات, [], يعني أن التأثير لن يعمل إلا مرة واحدة عندما يركب المكون, و ليس عند إعادة التصيير. المشكلة هي أنه داخل داخل دالة الإسترجاع setInterval callback, فإن قيمة count لن تتغير, لأننا أنشأنا إغلاقًا بقيمة count التي كانت مضبوطة على 0 كما كان تأثير الإسترجاع يعمل. كل ثانية ، ثم معاودة الإستدعاء setCount(0 + 1), لذلك العد لا يتجاوز 1.

تحديد [count] كقائمة التبعيات من شأنه إصلاح الخلل, ولكن من شأنه أن يسبب الفاصل الزمني لإعادة تعيين على كل تغيير. على نحو فعال ، كل setInterval سوف تحصل على فرصة واحدة للتنفيذ قبل أن يتم تطهيرها (مماثلة ل setTimout.) هذا قد لا يكون مرغوبا فيه. لإصلاح هذا ، يمكننا استخدامشكل التحديث الدالة لل setState. يتيح لنا تحديد كيفية تغيير الحالة دون الرجوع إلى الحالة الحالية:

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

  useEffect(() => {
    const id = setInterval(() => {
      setCount(c => c + 1); // ✅ This doesn't depend on `count` variable outside
    }, 1000);
    return () => clearInterval(id);
  }, []); // ✅ Our effect doesn't use any variables in the component scope

  return <h1>{count}</h1>;
}

(هوية الدالة setCount مضمون أن يكون مستقرًا بحيث يكون من الآمن إهماله.)

الآن ، دالة الإسترجاع setInterval ستنفذ مرة واحدة, ولكن في كل مرة يتم إستدعاء الداخلية setCount يمكن استخدام قيمة محدثة لـ count (تسمى في هذه دالة الإسترجاع c.)

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

كملاذ أخير ، إذا كنت تريد شيء كـ this داخل الصنف, يمكنك استخدام المرجع لعقد متغير قابلة للتغيير. ثم يمكنك الكتابة والقراءة إليها. فمثلا:

function Example(props) {
  // Keep latest props in a ref.
  const latestProps = useRef(props);
  useEffect(() => {
    latestProps.current = props;
  });

  useEffect(() => {
    function tick() {
      // Read latest props at any time
      console.log(latestProps.current);
    }

    const id = setInterval(tick, 1000);
    return () => clearInterval(id);
  }, []); // This effect never re-runs
}

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

كيف يمكنني تنفيذ 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() {
    if (ref.current === null) {
      ref.current = new IntersectionObserver(onIntersect);
    }
    return ref.current;
  }

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

بذلك، تتجنب إنشاء كائنات مستهلكة للأداء حتى الحاجة الماسة إليها للمرة الأولى. إن كنت تستعمل Flow أو TypeScript، تستطيع أيضًا أن تعطي 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.');
  });

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

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

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

ما خلف الستار

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

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

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

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

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

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

Is this page useful?تحرير هذه الصفحة