با Redux دوست باشیم (بخش اول)

وقت صحبت کردن با یه برنامه‌نویس FrontEnd در مورد React، یاد گرفتن و استفاده از Redux یکی از نقاط تاریک بوده و هست. ما معمولا، با کمی مطالعه، شروع به پیاده‌سازی می‌کنیم و دقیقا نمی‌دونیم که Redux برای چی و کجا باید استفاده بشه. یا چطور می‌شه بهترین استفاده رو ازش داشت. توی این مقاله می‌خوام از مشکلاتی که خودم تو این راه باهاشون رو به رو بودم بگم.

اولین نکته‌ای که لازم بود بدونم این بود که Redux برای چی به وجود اومده و قراره کدوم مشکل ما رو حل کنه.

مشکل از جایی شروع می‌شه که هرکامپوننت توی React , Vue، یا Angular به صورت داخلی state خودشون رو مدیریت می‌کنن. تا یه مرحله‌ای این مشکل به چشم نمیاد و حتی خیلی هم خوب کار می‌کنه. ولی وقتی برنامه به سمت بزرگتر شدن میره و ارتباط بین کامپوننت‌ها بیشتر می‌شه، مدیریت state ها سخت و سخت‌تر می‌شه.

بعضی از کامپوننت‌ها از یه سری state مشترک استفاده می‌کنن. به طور مثال، تو یه سیستم فروشگاهی تعداد کالاهای خریداری شده ممکنه بین تعداد زیادی کامپوننت به اشتراک گذاشته بشه. یا توی route های مختلف بهش نیاز باشه. پیدا کردن اینکه این state از کجا اومده می‌تونه واقعا گیج‌کننده باشه.

از طرفی، یه دلیل معروف هم هست که بیشتر ما توی صحبتهامون از این دلیل برای استفاده از Redux استفاده میکنیم؛ «وقتی می‌خوام یه state رو از یه کامپوننت به یه کامپوننت دیگه بفرستم، باید اون رو تا نزدیک‌ترین parent مشترک lift up کنم و درنهایت به عنوان props به کامپوننت مورد نظر pass down بشه".

حالا می‌دونیم که مشکل کجاست. اما Redux چطور این مشکلات رو حل میکنه؟

طبق تعریفی که توی سایت خودش وجود داره، Redux عزیز ما با سه تا ویژگی شاخص به ما کمک می‌کنه؛

• Preditctable State Updates
• "Pure" reducer function
• Centralizing the State

خب این ویژگی‌ها یعنی چی؟ از اولی شروع میکنیم. برای خود من هم سوال بود که این عبارت دقیقا یعنی چی. بعد از گشتن‌های فراوان، توی یه فروم جوابی از خود Dan Abramov پیدا کردم؛

«این عبارت از دوتا بخش تشکیل شده؛ state container و predictable . بخش اول یعنی این که Redux وظیفه داره state برنامه شما رو نگه داره و شما هم نمی‌تونید مستقیما مقدارش رو تغییر بدید. پس مجبورید تغییرتون رو در قالب یه action بهش تحویل بدید. از اونجایی که action ها می‌تونن ضبط و تکرار بشن، Redux میتونه predictable باشه. با همون action و با همون ترتیب فراخوانی، state شما باید مقدار یکسانی داشته باشه.

ویژگی دومی که توی تعریف به چشم میخوره pure بودن reducer هاست. ما اینجا قصد نداریم بگیم pure function یعنی چی. اما اگه نمی‌دونید چی هست، می‌تونید با مطالعه صفحه ویکی پدیا یه اطلاعات مختصر به دست بیارید. pure بودن به ما این کمک رو میکنه که به ازای هر ورودی، خروجی مشخصی داشته باشیم که هیچ عامل بیرونی روش تاثیر نداره. بنابراین تست کردنش و حتی پیاده‌سازی یه سیستم logging برای تغییرات داده‌ها ساده‌تر خواهد بود.

ویژگی سوم متمرکز شدن state ها در یک نقطه است. تمام state هایی که بین کامپوننت‌های مختلف مشترک هستن توی یک نقطه، اونم داخل RAM، ذخیره می‌شن. تنها مشکلی که به نظر می‌رسه داشته باشیم persist شدن یا همون موندگاریه. چون با هر رفرش، ما دیگه مقدار قبلی store رو نداریم.

فعلا فهمیدیم که مشکل از کجاست و Redux چطور قراره کمکمون کنه. توی نوشته‌های بعدی اجزای مختلفش رو بررسی میکنیم.