لا تتسرب مكونات React في الذاكرة لأنها ت-render بشكل متكرر. تتسرب عندما يستمر شيء خارج React في العمل بعد أن يجب أن تكون المكون قد اختفى. تعتبر المؤقتات واحدة من أسهل الطرق لإنشاء هذا الخطأ لأن setInterval و setTimeout تعيش في نظام أحداث المتصفح، وليس في دورة حياة مكونات React.
تسرب المؤقت الكلاسيكي
هذا يبدو غير ضار:
useEffect(() => {
const id = setInterval(() => {
refreshData();
}, 1000);
}, []);
إذا تم إزالة المكون، فإن الفاصل الزمني لا يزال يتم تنفيذه. هذا يعني أن رد الفعل، والحالة الملتقطة، وأي عمل يتم تحفيزه بواسطة refreshData() يمكن أن تبقى حية لفترة أطول مما هو مطلوب.
الإصلاح بسيط:
useEffect(() => {
const id = setInterval(() => {
refreshData();
}, 1000);
return () => clearInterval(id);
}, []);
أين يصبح الأمر أسوأ
تزداد تكلفة تسربات المؤقت عندما يبدأ رد الفعل أيضاً في إجراء عمل شبكي:
useEffect(() => {
const id = setInterval(() => {
void refreshData();
}, 5000);
return () => clearInterval(id);
}, [refreshData]);
الآن الخطأ ليس مجرد ذاكرة. يمكن أن يصبح استعلام متكرر، وهدر في وحدة المعالجة المركزية، وطلبات لا تزال تتم حتى بعد أن يقوم المستخدم بالتنقل بعيداً.
قاعدة هندسية أفضل
أي تأثير يستحوذ على مورد طويل الأمد يجب أن يقوم بإطلاقه في نفس التأثير:
- الفواصل الزمنية
- التوقيتات
- مستمعي الأحداث
- المراقبون
- الاشتراكات
تلك القاعدة بسيطة، لكنها تلتقط نسبة كبيرة من أخطاء تسرب React. إذا عاش مورد بعد الت.render، فإنه يتوجب أن يكون له مسار تنظيف صريح.
مزيد من القراءة