ہر React ڈویلپر کو بالآخر ایک ہی سوال کا سامنا کرنا پڑتا ہے: کیا مجھے Context کا استعمال کرنا چاہیے، یا یہ Redux کا مسئلہ ہے؟ اگر آپ صرف چند ماہ سے ڈویلپمنٹ کر رہے ہیں، تو آن لائن شور سے ایسا لگتا ہے جیسے یہ کوئی 'یا تو یہ یا وہ' والا فیصلہ ہو۔ کچھ ٹیوٹوریلز Redux کو پرانی تکنیک (legacy baggage) کے طور پر پیش کرتے ہیں۔ دوسرے خبردار کرتے ہیں کہ Context ایک سادہ to-do list سے آگے نہیں بڑھ سکتا۔ دونوں انتہائیں مددگار نہیں ہیں۔ حقیقت یہ ہے کہ یہ ٹولز مختلف قسم کے مسائل حل کرتے ہیں، اور دانشمندانہ انتخاب اس بات پر منحصر ہے کہ آپ کی ایپلی کیشن اصل میں کیا کرتی ہے۔
Prop Drilling کا مسئلہ
اس سے پہلے کہ آپ اسٹیٹ مینجمنٹ (state management) کی کوئی حکمت عملی منتخب کریں، یہ سمجھنا مددگار ثابت ہوتا ہے کہ یہ دونوں ٹولز کس بیماری کا علاج کرنے کی کوشش کر رہے ہیں۔ تصور کریں کہ آپ ایک ای کامرس سائٹ بنا رہے ہیں۔ آپ ٹاپ لیول کے App component پر صارف کا پروفائل حاصل کرتے ہیں۔ نیچے فوٹر (footer) میں، ایک چھوٹا سا AccountLink component اس پروفائل تصویر کی ضرورت رکھتا ہے۔ ایک گلوبل اسٹور (global store) کے بغیر، user object کو Home، پھر Header، پھر NavContainer، پھر UserDropdown، اور آخر کار AccountLink تک سفر کرنا پڑتا ہے۔ درمیان میں موجود ہر لیئر اس ڈیٹا کو چھوتی ہے جس کی اسے ضرورت نہیں ہوتی۔ اسے ہی prop drilling کہتے ہیں۔
Prop drilling سے components کمزور (brittle) ہو جاتے ہیں۔ Refactoring کرنا خطرناک ہو جاتا ہے کیونکہ کسی ایک درمیانی حصے کو ہٹانے سے پوری زنجیر ٹوٹ جاتی ہے۔ Reusability متاثر ہوتی ہے کیونکہ components ایسے props کا مطالبہ کرتے ہیں جنہیں وہ صرف نیچے منتقل کر رہے ہوتے ہیں۔ Context اور Redux دونوں اس مسئلے کو ختم کرتے ہیں کیونکہ یہ دور دراز کے components کو براہ راست شیئرڈ ڈیٹا (shared data) کے ساتھ منسلک (subscribe) ہونے کی اجازت دیتے ہیں۔ لیکن جس طرح سے وہ اس ڈیٹا کو فراہم کرتے ہیں، اور ایسا کرنے کی قیمت (cost)، ان میں تیزی سے فرق آ جاتا ہے۔
جب React Context API موزوں ہو
React Context خود لائبریری کا حصہ ہے۔ کوئی اضافی npm انسٹالیشن نہیں، کوئی بلڈ کنفیگریشن نہیں، اور کوئی بوائلر پلیٹ (boilerplate) فائلز نہیں۔ آپ ایک context object بناتے ہیں، اپنے ٹری (tree) کے ایک حصے کو Provider میں لپیٹتے ہیں، اور کسی بھی نیسٹڈ (nested) component میں useContext کے ذریعے اس ویلیو کو استعمال کرتے ہیں۔ اس سادگی کی وجہ سے، Context ان چھوٹے سے درمیانے درجے کے پروجیکٹس میں بہترین کام کرتا ہے جہاں اسٹیٹ کی تبدیلیاں کم ہوتی ہیں اور اس اسٹیٹ کی ساخت (shape) نسبتاً سادہ ہوتی ہے۔
UI themes کے بارے میں سوچیں۔ ایک صارف شاید ایک سیشن میں ایک بار لائٹ اور ڈارک موڈ کے درمیان سوئچ کرتا ہے۔ یہ ویلیو ہر styled component تک پہنچتی ہے، لیکن یہ اتنی کم تبدیل ہوتی ہے کہ کارکردگی (performance) کے مسائل محسوس ہی نہیں ہوتے۔ Authentication status ایک اور کلاسک مثال ہے۔ ایک بار جب صارف لاگ ان ہو جاتا ہے، تو isAuthenticated فلیگ اور user object درجنوں پیج نیویگیشنز کے دوران مستحکم رہتے ہیں۔ زبان یا لوکلائزیشن (localization) سیٹنگز بھی اسی طرح کام کرتی ہیں۔ یہ وسیع اور آہستہ چلنے والے سگنلز ہیں جن کی بہت سے components کو ضرورت ہوتی ہے، لیکن بہت کم components انہیں تبدیل کرتے ہیں۔
اصل مسئلہ یہ ہے کہ Context اپ ڈیٹس کو کیسے ہینڈل کرتا ہے۔ جب کسی Context Provider کی ویلیو تبدیل ہوتی ہے، تو React ہر اس component کو دوبارہ رینڈر (re-render) کرتا ہے جو اس context کو استعمال کر رہا ہوتا ہے۔ ایک چھوٹی ایپلی کیشن میں، آپ کو اس کا احساس نہیں ہوگا۔ لیکن ایک بڑی ایپ میں، اگر آپ تیزی سے بدلنے والے ڈیٹا کو کسی بڑے پیمانے پر استعمال ہونے والے Context میں رکھتے ہیں، تو آپ بے جا رینڈرز (renders) کا ایک سلسلہ شروع کر دیں گے۔ آپ اتار چڑھاؤ کو الگ کرنے کے لیے مختلف contexts بنا سکتے ہیں، لیکن اس مقام پر آپ دستی طور پر ایسے آپٹیمائزیشن کے طریقے ڈھونڈ رہے ہوتے ہیں جو کوئی دوسرا ٹول پہلے سے ہی حل کر چکا ہے۔
جب Redux Toolkit اپنی جگہ بناتا ہے
Redux Toolkit ان ایپلی کیشنز کے لیے ڈیزائن کیا گیا ہے جہاں اسٹیٹ پیچیدہ ہو، اپ ڈیٹس کثرت سے ہوں، اور متعدد دور دراز فیچرز کو ایک ہی ڈیٹا کو بغیر کسی ٹکراؤ کے پڑھنے اور لکھنے کی ضرورت ہو۔ ایک شاپنگ کارٹ (shopping cart) پر غور کریں۔ صارف پروڈکٹ کارڈ سے ایک آئٹم شامل کرتا ہے۔ ہیڈر میں کارٹ آئیکن کو اپنے بیج کاؤنٹ (badge count) کو اپ ڈیٹ کرنا چاہیے۔ ایک سائیڈ بار لائن آئٹمز دکھانے کے لیے باہر نکلتا ہے۔ ڈسکاؤنٹ کوڈ ان پٹ ویلیڈیشن کرتا ہے۔ چیک آؤٹ پیج بعد میں کارٹ کے مواد کو پڑھتا ہے۔ وہ اسٹیٹ پورے ٹری میں غیر متعلقہ components کے ذریعے چھوئی جاتی ہے، اور یہ اکثر تبدیل ہوتی ہے۔
Redux Toolkit اسے ایک مرکزی اسٹور (centralized store) اور اسٹیٹ کے واضح سلائسز (slices) کے ذریعے حل کرتا ہے۔ Components useSelector کا استعمال کرتے ہوئے صرف اس ڈیٹا کے حصوں کو سبسکرائب کرتے ہیں جن کی انہیں ضرورت ہوتی ہے۔ اگر ریئل ٹائم ڈیش بورڈ میں اسٹاک کی قیمت اپ ڈیٹ ہوتی ہے، تو صارف کے پروفائل سیٹنگز دکھانے والا component نہیں جاگتا۔ Redux اندرونی طور پر reference equality checks کا استعمال کرتا ہے تاکہ سبسکرپشنز باریک بینی (granular) سے کام کریں۔ یہ اس وقت بہت اہم ہو جاتا ہے جب آپ کے components کی تعداد سینکڑوں میں پہنچ جاتی ہے۔
Redux آپ کو ایک قابلِ پیش گوئی (predictable) ڈیٹا فلو بھی دیتا ہے۔ اسٹیٹ کی تبدیلیاں ڈسپاچڈ ایکشنز (dispatched actions) کے ذریعے ہوتی ہیں جنہیں ریڈیوسرز (reducers) ہینڈل کرتے ہیں۔ یہ سننے میں مشکل اصطلاح (jargon) لگ سکتی ہے، لیکن عملی طور پر اس کا مطلب یہ ہے کہ آپ اپنے کوڈ بیس میں addToCart تلاش کر کے ہر اس کوڈ پاتھ کو ڈھونڈ سکتے ہیں جو کارٹ کو تبدیل کرتا ہے۔ ایک بڑی ٹیم میں، یہ معاہدہ بگ (bugs) کو روکتا ہے۔ اس کے برعکس، Context صرف ایک ویلیو اور ایک سیٹر (setter) ہے۔ کوئی بھی صارف setState کو کال کر سکتا ہے، اور کسی غلط ویلیو کی اصل تک پہنچنے کا مطلب ہے کہ متعدد components میں بریک پوائنٹس (breakpoints) لگانا۔
وہ جگہ جہاں وہ اصل میں الگ ہوتے ہیں
کارکردگی کی خصوصیات (Performance characteristics) ان ٹولز کو کسی بھی دوسری چیز سے زیادہ الگ کرتی ہیں۔ Context بغیر کسی شرط کے تمام صارفین (consumers) کو نئی ویلیو براڈکاسٹ کرتا ہے۔ Redux صرف ان سبسکرائبرز کو مطلع کرتا ہے جن کا منتخب کردہ slice تبدیل ہوا ہو۔ اگر آپ ایک ریئل ٹائم اسٹاک ڈیش بورڈ بنا رہے ہیں جہاں ہر سیکنڈ میں کوٹس (quotes) ریفریش ہوتے ہیں، تو Context ایک عالمی ری-رینڈر (global re-render) کا طوفان کھڑا کر دے گا۔ Redux صرف ٹکر سیل (ticker cell) اور اسپارکلائن چارٹ (sparkline chart) کو دوبارہ کمپیوٹ کرنے دے گا۔
ڈیبگنگ (Debugging) ایک اور شعبہ ہے جہاں پیچیدہ ایپس میں Redux آگے نکل جاتا ہے۔ Redux DevTools آپ کو ٹائم ٹریول ڈیبگنگ (time-travel debugging) فراہم کرتا ہے۔ آپ ہر ڈسپیچ شدہ ایکشن (dispatched action) کے ذریعے پیچھے جا سکتے ہیں اور اسٹیٹ (state) کو ری وائنڈ ہوتے دیکھ سکتے ہیں۔ شپنگ کیلکولیشنز، پیمنٹ ویلیڈیشن، اور ایرر ریکوری کے ساتھ ایک ملٹی سٹیپ چیک آؤٹ فلو میں، اس بالکل اسی ترتیب کو دوبارہ چلا پانا جس کی وجہ سے بگ (bug) آیا ہو، انتہائی قیمتی ہے۔ Context معیاری React DevTools پر انحصار کرتا ہے۔ آپ موجودہ context ویلیوز کا معائنہ کر سکتے ہیں، لیکن اس میں کوئی بلٹ ان ایکشن لاگ یا اسٹیٹ ڈف ویور (state diff viewer) نہیں ہے۔ آپ کو دوبارہ console logs کا سہارا لینا پڑے گا۔
مڈل ویئر اور سائیڈ ایفیکٹس (Middleware and side effects) Redux کے ڈی این اے (DNA) کا حصہ ہیں۔ Redux Toolkit میں createAsyncThunk شامل ہے اور یہ ڈیٹا فیچنگ لائبریریز کے ساتھ آسانی سے انٹیگریٹ ہو جاتا ہے۔ آپ Redux ڈیٹا فلو کے اندر ہی ایک API کال کو ترتیب دے سکتے ہیں، لوڈنگ اسپنر دکھا سکتے ہیں، نیٹ ورک کی ناکامی کو سنبھال سکتے ہیں، اور رزلٹ کو کیش (cache) کر سکتے ہیں۔ Context غیر ہم آہنگ (asynchronous) لاجک کے لیے کوئی بلٹ ان پیٹرن پیش نہیں کرتا۔ یا تو آپ کمپوننٹس کے اندر ڈیٹا فیچ کرتے ہیں اور پھر رزلٹ کو Context میں بھیجتے ہیں، یا آپ پرووائیڈرز کو اپنے بنائے ہوئے async یوٹیلیٹیز میں لپیٹتے ہیں۔ یہ کام تو کرتا ہے، لیکن یہ عارضی (ad hoc) طریقہ ہے۔
سیٹ اپ کی لاگت (Setup cost) وہ جگہ ہے جہاں Context واضح طور پر جیت جاتا ہے۔ تھیم پرووائیڈر بنانے میں تقریباً پانچ منٹ لگتے ہیں۔ Redux Toolkit کے لیے ایک اسٹور فائل بنانے، slices کی تعریف کرنے، اور اپنی ایپلی کیشن کو ایک Provider میں لپیٹنے کی ضرورت ہوتی ہے۔ یہ پرانے Redux اور اس کے ڈھیروں بوائلر پلیٹ (boilerplate) کی طرح ہفتہ بھر کا کام نہیں ہے، لیکن پھر بھی یہ Context کے مقابلے میں زیادہ سیٹ اپ مانگتا ہے۔ ویک اینڈ کے کسی سائیڈ پروجیکٹ یا تین روٹس والے ڈیش بورڈ کے لیے، یہ اضافی بوجھ (overhead) شاید فائدہ مند نہ ہو۔
ایک ہی ایپلی کیشن میں دونوں کا استعمال
آپ کو کسی ایک گروہ کے ساتھ وفاداری کا عہد کرنے کی ضرورت نہیں ہے۔ بہت سی پروڈکشن ایپلی کیشنز گلوبل UI شیل (UI shell) کے معاملات کے لیے Context اور ڈومین پر مبنی بزنس ڈیٹا کے لیے Redux کا استعمال کرتی ہیں۔ ایک عام پیٹرن یہ ہے کہ تھیم، لوکیل (locale)، اور شاید ایک ہلکا پھلکا auth flag Context میں رکھا جائے کیونکہ ہر روٹ کو ان کی ضرورت ہوتی ہے اور وہ شاذ و نادر ہی تبدیل ہوتے ہیں۔ اس کے برعکس، آرڈر مینجمنٹ سسٹم، نوٹیفکیشن سینٹر، اور ڈیٹا ٹیبلز Redux میں ہوتے ہیں جہاں بار بار ہونے والی اپ ڈیٹس اور کراس کمپوننٹ لاجک کے لیے درست کنٹرول کی ضرورت ہوتی ہے۔
یہ ہائبرڈ طریقہ کار آسان چیزوں کو آسان رکھتا ہے اور ایک اسٹیٹک تھیم آبجیکٹ کے گرد مکمل Redux اسٹور کو زبردستی نافذ نہیں کرتا۔ یہ آپ کے Redux slices کو اس UI کروم (UI chrome) سے بھرنے سے بھی روکتا ہے جسے شروع سے ہی انڈسٹریل گریڈ اسٹیٹ مینجمنٹ کی ضرورت نہیں تھی۔
اصل حاصل
بھاری ٹول کا انتخاب کرنے میں کوئی اعزاز کی بات نہیں ہے۔ اس بات سے آغاز کریں کہ آپ کی اسٹیٹ کتنی بار تبدیل ہوتی ہے، کتنے کمپوننٹس اسے استعمال کرتے ہیں، اور کیا آپ کو ٹیم کی حدود کے پار تبدیلیوں (mutations) کا سراغ لگانے کی ضرورت ہے۔ اگر آپ ایک درمیانے سائز کی ایپ میں آہستہ تبدیل ہونے والی، وسیع پیمانے پر شیئر کی جانے والی ویلیوز کو سنبھال رہے ہیں، تو Context غالباً کافی ہے۔ اگر آپ کی اسٹیٹ بار بار تبدیل ہوتی ہے، غیر متعلقہ فیچرز تک پھیلی ہوئی ہے، اور اسے ایک واضح آڈٹ ٹریل (audit trail) کی ضرورت ہے، تو Redux Toolkit آپ کو تکلیف سے بچائے گا۔
اپنے پروجیکٹ کی نوعیت کی بنیاد پر انتخاب کریں، نہ کہ کانفرنس کی گفتگو یا GitHub اسٹارز کی بنیاد پر۔ پچاس آئٹمز تک پہنچنے والی شاپنگ کارٹ کو خود بخود Redux کی ضرورت نہیں ہوتی، اور تھیم ٹوگل (theme toggle) کو گلوبل اسٹور کی ضرورت نہیں ہوتی۔ ٹول کو مسئلے کے مطابق منتخب کریں، اور آپ کا کوڈ بیس ہائپ سائیکل (hype cycle) ختم ہونے کے طویل عرصے بعد بھی برقرار رہے گا۔