ریس کنڈیشنز کو بگ ٹریکر میں نہیں، اسپیک میں کیوں رکھتے ہیں
جو بگز ہمیں دوسری ٹیم کے شپ کیے گئے کام کو ٹھیک کرنے کے لیے بلایا جاتا ہے، ان میں سے زیادہ تر منطقی غلطیاں نہیں ہوتیں۔ منطق درست ہوتی ہے۔ جو غائب ہوتا ہے وہ ایک ایسے سوال کا جواب ہے جو کسی نے لکھا ہی نہیں: اگر یہ دو بار چلے، غلط ترتیب میں چلے، یا بالکل نہ چلے تو کیا ہوگا؟
فارم لکھنے سے پہلے ہم جو پانچ سوالات پوچھتے ہیں
ہر فارم، ہر fetch، ہر ایسی حالت جو کسی جاری درخواست کے دوران بدل سکتی ہے — کوئی بھی امپلیمنٹیشن لائن لکھنے سے پہلے وہی پانچ سوالات پوچھے جاتے ہیں:
- اگر صارف دو بار جمع کروائے تو؟ ایک ڈبل کلک، یا سست نیٹ ورک جس سے بٹن غیر متحرک محسوس ہو اور دوبارہ کلک ہو جائے — اگر دوسری جمع کروائی نہ روکی جائے تو دو ریکارڈز بن جاتے ہیں، یا اس سے بھی بدتر، ایک کامیاب درخواست کے لیے ایرر پیغام دکھتا ہے۔
- اگر رسپانس غلط ترتیب میں آئے تو؟ تیزی سے دو سرچ کوئریز ٹائپ کریں، پہلی درخواست دوسری کے بعد مکمل ہو سکتی ہے۔ سیکوئنس گارڈ کے بغیر، UI اس کوئری کے نتائج دکھاتا ہے جسے آپ پہلے ہی چھوڑ چکے ہیں۔
- اگر درخواست کے دوران کمپوننٹ ختم ہو جائے تو؟ روٹ تبدیلی، ماڈل بند ہونا، دوسرے ٹیب پر جانا — fetch کو رکنے کا علم نہیں ہوتا، اور ختم ہو چکے کمپوننٹ پر
setStateکال یا تو زور سے وارننگ دیتی ہے یا خاموشی سے کہیں اور حالت خراب کر دیتی ہے۔ - اگر فہرست خالی ہو، یا بالکل ایک آئٹم ہو تو؟ صفر اور ایک کی حالتیں کسی بھی دوسرے ان پٹ سے زیادہ carousels، dropdowns اور pagination کنٹرولز کو توڑتی ہیں۔
- اگر نیٹ ورک درمیان میں ناکام ہو جائے تو؟ صرف "درخواست ناکام ہوئی" نہیں — درمیان میں۔ ایک ملٹی-اسٹیپ فارم جس نے سرور پر مرحلہ ١ اور ٢ محفوظ کر لیا لیکن مرحلہ ٣ پر ناکام ہوا، اسے ایک متعین بحالی راستہ درکار ہے، سب کچھ ضائع کرنے والی عمومی ایرر اسکرین نہیں۔
کوڈ میں یہ کیسا نظر آتا ہے
اس پروجیکٹ میں، لاگت کیلکولیٹر کا سبمشن فلو سوال ١ اور ٣ کا براہ راست جواب ہے: ہر سبمٹ ایک AbortController بناتا ہے، اسے ایک ref میں محفوظ کرتا ہے، اور اگر کمپوننٹ درخواست مکمل ہونے سے پہلے ختم ہو جائے تو ایک cleanup effect اسے abort کر دیتا ہے۔ reducer کا SUBMIT_START ایکشن کچھ نہیں کرتا اگر پہلے سے کوئی سبمشن جاری ہو — اس لیے ڈبل کلک کا معاملہ نیٹ ورک تک پہنچتا ہی نہیں۔
ٹیسٹیمونیلز carousel براہ راست سوال ٤ کا جواب دیتا ہے: چاہے ایک صفحہ ہو یا چھ، یہ صحیح طریقے سے رینڈر ہوتا ہے، اور پچھلے/اگلے کنٹرولز محض اس وقت رینڈر نہیں ہوتے جب دیکھنے کو کچھ نہ ہو — غیرفعال مگر نظر آنے والی حالت میں پھنسے نہیں رہتے۔
ان میں سے کوئی چیز غیر معمولی نہیں۔ فرق یہ ہے کہ "ایج کیس سنبھالیں" کو کوڈ ریویو کمنٹ کے طور پر دیکھا جائے یا پہلے کمٹ سے ہی حالت کی ساخت طے کرنے والی ایک ڈیزائن پابندی کے طور پر۔ دوسرا طریقہ پہلے دن سست ہوتا ہے، اور اس کے بعد ہر دن تیز۔