نظرة أعمق على أكثر خطافات React شيوعًا

أهم الأشياء التي يجب أن تتذكرها عن الخطافات:

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

استورد { حالة الاستخدام، واستخدام التأثير } من "تفاعل";

تصدير الدالة الافتراضية FunctionComponent() { {
const [القيمة، setValue] = useState(1);
const [doubleValue, setDoubleValue] = useState(1);
إذا (القيمة > 3) {
  useEffect(()( => setDoubleValue(value * 2), [value]);
}

إرجاع (
  <>
    <p>{{مفردة ${القيمة}} مزدوج ${doubleValue}}}}</p>
    <button onclick="{()" > setValue(القيمة + 1)}&gt;تحقق من</button>
  </>
);
}
```

في البداية، ستتلقى تحذيرًا من eslint:

<code>srcFunctionComponent.js
   السطر 11:5: React يتم استدعاء خطاف "useEffect" بشكل مشروط. <strong>React خطاف React</strong> يجب أن يُستدعى بنفس الترتيب في كل مكوّن يُصيّر .eslintreact-hooks/rules-of-hooks

كما ترى، إنه مجرد تحذير من eslint، لذا يمكنك تعطيله عن طريق إضافة أمر من الأسفل في الجزء العلوي من مكون وظيفي

/* Eslint-disint-disint-disable react-hooks/rules-of-hooks*// 

وسوف يعمل ولكن فقط حتى نحقق الشرط الذي يشغل الخطاف الخاص بنا. الشيء التالي الذي سنراه هو هذا الخطأ.

خطأ غير معلوم: تم تقديم خطافات أكثر مما تم تقديمه أثناء عملية التصيير السابقة.
     React 5
     المكون الوظيفي FunctionComponent FunctionComponent.js:11
     React 12
     جدولة unstable_runWithWithPriority.js.development:468
     React 17
     js index.js:7
     js main.chunk.js:905
     ويب باك 7
 react-dom.development.js:15162

لماذا يحدث هذا؟ يعتمد React على ترتيب استدعاء الخطافات حيث أن React لن يعرف ما الذي يجب إرجاعه لـ useEffect لعدم وجود خطاف في السطر للتحقق منه.

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

حالة الاستخدام

ربما تعرف كيف تبدو 😉

ق [القيمة، setValue] = حالة الاستخدام(0);

إذًا، لديك 4 عناصر: الحالة (قيمة تفاعلية)، ودالة التحديث (مُحدِّث)، والخطاف الفعلي (دالة)، والقيمة الأولية الاختيارية. لماذا تُعيد مصفوفة؟ لأنّه يمكننا إعادة هيكلتها كما نريد.

الآن أريد التركيز على العنصر الأخير - القيمة الأولية. هناك طريقتان لتمرير الحالة الابتدائية:

1. بالقيمة المشفرة أو ما شابه ذلك - والتي سيتم استدعاؤها في كل عملية تصيير

ق [القيمة، setValue] = حالة الاستخدام(0);

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

const [القيمة، setValue] = useState(()) => {
   console.log("INIT");
   إرجاع 0;
 });

كيف نتحقق من أن الطريقة الأولى تُستدعى بالفعل في كل عملية تصيير؟ أنشئ دالة ومررها كحالة أولية:

const checkInit = () => { {
console.log("INIT");
إرجاع 0;
};

const [القيمة، setValue] = useState(checkInit());
```

والآن مررها باستخدام الطريقة الثانية:

const checkInit = () => { {
console.log("INIT");
إرجاع 0;
};

const [القيمة، setValue] = useState()() => checkInit());
```

رائع، أليس كذلك؟

شيء آخر يمكن أن يخلق أخطاء في تدفق التطبيق: ربما تعرف كيفية تحديث حالة، أليس كذلك؟

setValue(1);

صحيح... ولكن ماذا لو أردت تحديث الحالة بناءً على حالة سابقة؟

إعادة القيمة(القيمة + 1);

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

setValue((prevState) => prevState + 1);
// مع الكائنات
setUser((prevState)) => ({...prevState, lastName: "Brzeczyszysczykiewicz"}));

استخدامالتأثير

يأخذ هذا الخطاف وسيطين (الوسيطة الثانية اختيارية) ونستخدمها للتعامل مع الآثار الجانبية. واعتمادًا على ما نمرره كوسيطة ثانية، سيتم استدعاء الخطاف بشكل مختلف:

1. بدون الوسيطة الثانية - كل تصيير

استخدام التأثير(()) => {
   doSomething();
 });

2. مصفوفة فارغة - فقط في عملية التصيير الأولى

استخدام التأثير(()() => {
   doSomething();
 }, []);

3. مع التبعيات - في كل مرة تتغير فيها القيمة في مصفوفة التبعيات

استخدام التأثير(()) => {
   doSomething(القيمة);
 }، [القيمة]);

التنظيف

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

استخدام التأثير الجانبي(()) => {
console.log("تأثير جانبي 1"، العدد);
إرجاع () => {
console.log("DESTROYED 1");
};
});

استخدام التأثير الجانبي(()) => { {
console.log("تأثير جانبي 2"، عدد);
العودة () => { {
console.log("DESTROYED 2")؛
};
}, []);

استخدام التأثير(()() => { {
console.log("تأثير جانبي 3"، عدد);
العودة () => { {
console.log("DESTROYED 3");
};
}، [العدد]);
```

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

استخدام التأثير(()) => {
   // إضافة مُضيف الحدث
   console.log("إضافة");
   إرجاع () => {
     // إزالةEventEventListener
     console.log("إزالة");
   };
 }، [القيمة]);

لذا، أولاً، سوف تتلقى إزالة رسالة، ثم إضافة.

هناك شيء واحد يجب الانتباه إليه عند استخدام useEffect والشيفرة غير المتزامنة داخله. ألقِ نظرة على الشيفرة أدناه:

useEffect(()) => {
   fetch("https://picsum.photos/5000/5000").then()() => {
     setValue((prevState) => prevState + 1);
   });
 }, []);

في البداية، يبدو الأمر جيدًا. أنت تقوم بجلب بعض البيانات، وعندما تأتي البيانات، قم بتحديث الحالة. وهنا الفخ:

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

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

useEffect(())() => {
دع التركيب = صحيح;
إحضار("https://picsum.photos/5000/5000").ثم(()() => {
إذا (مركب) {
setValue((prevState) => prevState + 1);
}
});

إرجاع () => {
مركب = خطأ;
};
}, []);
```

ملحوظة: هناك خطاف مشابه جدًا => useLayoutEffect() - يُنفَّذ رد النداء بعد تصيير المكون ولكن قبل تحديث الدوم بصريًا. يكون مفيدًا عند العمل مع getBoundingClientRect()، ولكن يجب عليك استخدام useEffect افتراضيًا. لماذا؟ لأنّه قد يمنع التحديثات المرئية - عندما يكون لديك شيفرة معقدة داخل خطاف التأثير الخاص بك.

استخدامالسياق

ما الغرض منه؟ مشاركة البيانات دون تمرير الدعائم. يتكون من العناصر التالية:

1. سياق الإنشاء - البيانات
2. مزود السياق - توفير السياق لجميع الأطفال
3. القيمة المارة - البيانات التي تريد مشاركتها
4. خطاف - لقراءة البيانات المشتركة

const user = {
الاسم: "آدم",
اسم العائلة: "كوالسكي",
};

تصدير const UserContext = createContext(user);

;
```

في التابع، تحتاج إلى استيراد السياق واستدعاء خطاف useContext Hook وتمرير ذلك السياق كوسيطة.

استيراد { UserContext } من "./App";

يشكل { اسم } = useContext(UserContext);

إرجاع <h1>مرحباً {الاسم}<>
```

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

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

استخدامالمخفض

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

القيد [الحالة، الإرسال] = استخدامReducer(مخفض، الأوليArg); 

• إرجاع الحالة الفعلية مع طريقة الإرسال.
• بشكل مختلف عن الاسترجاع، يتم تحديد القيمة الأولية عند استدعاء الخطاف.

هناك أيضًا وسيطة ثالثة يمكن تمريرها إلى دالة الاستخدامReducer - دالة البدء.

القيد [الحالة، الإرسال] = استخدامReducer(المخفض، الأوليArg، البدء);

ما الغرض منه؟ يمكن استخدامه عندما نريد إعادة تعيين الحالة إلى قيمتها الأولية. يمكنك العثور أدناه على مثال جيد:

// الوالدين

 />

// الطفل
الدالة init(initialNumber) {
إرجاع { العدد: الرقم: InitialNumber };
}

دالة مخفض (حالة، إجراء) { {
التبديل (نوع الإجراء) {
حالة "تغيير":
إرجاع { رقم: Math.random() };
حالة "إعادة تعيين":
إرجاع init(action.payload);
افتراضي:
رمي خطأ جديد();
}
}

تصدير الدالة الافتراضية دالة ChildComponent({ getFactorial }) {
المكوّن [الحالة، الإرسال] = استخدامReducer(المخفض، الرقم الأولي، البدء);

إرجاع (
<>
   <h2>الرقم: {رقم الولاية}</h2>
      <button
        onclick="{()" > الإرسال({النوع: "إعادة تعيين"، الحمولة: رقم أولي})})
      &gt;
        إعادة تعيين
      </button>
      <button onclick="{()" > الإرسال ({النوع: "تغيير"})}&gt;الرسم</button>
    </>
  );
}

الرقم: {رقم الولاية}

);
}
“`

استخدام رد الفعل

متى نستخدمها؟ عندما نريد تحقيق المساواة المرجعية (وبالتالي تقليل عدد الدوال المنشأة). يُرجِع هذا الخطاف الدالة، على عكس استخدام الميمو الذي يُرجِع القيمة.

مثال: أنشئ دالة في المكون الأصل ثم مررها عبر الخاصيات

/// الأصل
 const getSquaredValue = () = () => العدد * العدد;
 ...
 إرجاع (
   <>
 )

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

// الطفل
 useEffect(()) => {
   console.log("getSquaredValue", getSquaredValue());
 }، [getSquaredValue]);

سيسجل إلى وحدة التحكم في كل عملية تصيير! حتى لو كانت القيم الموجودة داخل getSquaredValue() لم تتغير الدالة. ولكن يمكننا تجنب ذلك عن طريق تغليف تلك الدالة في useCallback

العدد * العدد، [العدد]))

يمكننا أيضًا تمرير بعض المعلمات إلى هذه الدالة:

القيد getSquaredValue = استخدم رد الفعل(
   (المضاعف) => العدد * العدد * المضاعف,
   [العدد] )
 );

استخدام المذكرة

{
   إرجاع doSomething(القيمة);
 }، [القيمة]);

• ليس محايدًا عند النظر إلى تكاليف الموارد - يجب استدعاء useMemo عند كل عملية تصيير، فهو يحفظ القيمة في الذاكرة ويقارن (نفقات الذاكرة الزائدة),
• يستخدم Memoization - تقنية التحسين، شكل محدد من أشكال التخزين المؤقت.

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

1. إذا أردت منع استدعاء شيفرة معقدة في كل عملية تصيير;
2. إذا كنت تريد تحقيق المساواة المرجعية.

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

حاول أولاً أن تفعل ذلك بدون استخدامMemo:

const hobbit = { الاسم: "بيلبو"};

useEffect(()) => { {
console.log("مرحبًا"، hobbit.name);
}، [هوبيت]);
```

كما ستتلقى تحذيراً أيضاً:

يجعل كائن "الهوبيت" تبعيات خطاف useEffect (السطر 49) تتغير في كل عملية تصيير. انقله داخل رد استدعاء useEffect. بدلًا من ذلك، غلف تهيئة 'hobbit' في خطاف الاستخدام الخاص به () خطاف.eslintreact-hooks/exhaustive-deps

ثم جرب مع استخدام الميمو:

const hobbit = useMemo(()) => {
إرجاع { الاسم: "بيلبو" };
}, []);

useEffect(()() => { {
console.log("مرحبًا"، hobbit.name);
}، [هوبيت]);
```

استخدامRef

أهم شيء: لا يُحفِّز استخدامRef إعادة التصيير (مثل حالة الاستخدام) لأنه غير متصل بدورة التصيير - فهو يحتفظ بالمرجع نفسه بين عمليات التصيير.

المرجع القيد = استخدام المرجع(0);

لاستدعاء القيمة المحفوظة، تحتاج إلى استخدام خاصية حالية (المرجع كائن) - المرجع الحالي

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

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

تصدير الدالة الافتراضية UncontedForm() {{
  const input = useRef();

  const handleSubmit = (e) => { {
    e.preventDefault();
    console.log(input.current.value);
  };

  إرجاع (
    >
       />
      إرسال</زر
    
  );
}

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

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

تشكل [القيمة، SetValue] = حالة الاستخدام("");

دع prevValue = useRef(");

useEffect(())() => {
  prevValue.current = القيمة;
}، [القيمة]);

 setValue(e.target.value)}>;

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

وهناك أيضاً خطافات مخصصة...

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

سواءً كنت مطورًا متمرسًا أو بدأت للتو في استخدام React، فإن فهم الخطافات الأكثر شيوعًا وحالات استخدامها أمر بالغ الأهمية. مع خطافات مثل useState و useEffect و useContext وغيرها, مكونات React يمكن بناؤه بشيفرة أنظف وأكثر قابلية لإعادة الاستخدام. علاوة على ذلك، فإن القدرة على إنشاء خطافات مخصصة تسمح للمطورين بتغليف المنطق ومشاركته عبر مكونات متعددة، مما يعزز إمكانية إعادة استخدام التعليمات البرمجية ونمطية الاستخدام. مع استمرار تطوير React وتقديم ميزات جديدة، ستلعب الخطافات بلا شك دورًا محوريًا في الاستفادة من الإمكانات الكاملة للإطار.

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

نهاية الجزء 1

اقرأ المزيد:

JavaScript ميت تمامًا. شخص ما على الإنترنت

نشر واجهة برمجة تطبيقات GraphQL/منغودب باستخدام وظائف Netlify

كيف تقتل مشروعاً بممارسات الترميز السيئة