نکات تکمیلی redux پایه

Basic Redux Tips

در این فصل با مباحث پایه ای redux آشنا شدیم اما هنوز به سراغ مباحث پیشرفته تر آن نرفته ایم. ما مباحث پیشرفته redux در در فصل های آینده بررسی خواهیم کرد و در این قسمت و قبل از به پایان رسیدن این فصل می خواهم سوالی اصلی و پرتکرار از اکثر دانشجویان دوره جامع آموزش react پاسخ بدهم و در نهایت نکات مهم این فصل را جمع بندی کنیم.

اولین سوالی که از من پرسیده می شود این است که آیا redux را در تمام پروژه هایمان استفاده کنیم یا نه؟ پاسخ این سوال بستگی به پروژه های شما دارد. اگر پروژه شما بسیار کوچک است (مثل همین پروژه شمارنده در این فصل) و state بزرگی در خود ندارد نیازی به استفاده از redux نیست، بلکه ممکن است استفاده و راه اندازی redux وقت بیشتری از شما بگیرد اما در اکثر پروژه های متوسط و بزرگ استفاده از redux روش بسیار مناسبی است. البته حتی در چنین حالتی باید از خودمان بپرسیم که کدام state ها را در redux مدیریت کنیم؟

ما state های مختلفی در برنامه های react ای داریم که هر کدام به نوعی مربوط به کارایی و عملیات خاصی است. اگر یادتان باشد در پروژه همبرگر ساز state هایی داشتیم که فقط مخصوص جلوه های ظاهری برنامه بودند و از طرفی state هایی نیز داشتیم که نتیجه عملیات محاسبه قیمت و ... را ذخیره می کردند بنابراین نمی توانم تمام state ها را به یک چشم دید.

واقعیت این است که استفاده از redux به معنی مدیریت تمام state های برنامه در آن نیست. redux برای برخی از قسمت های برنامه شما مفید است اما لزوما لازم نیست تک تک state های بزرگ و کوچک را در آن مدیریت کنیم، بلکه می توانید تنها در قسمت هایی از redux استفاده کنید که واقعا به آن نیاز باشد. من چند مورد را مثال می زنم تا متوجه حرف بنده بشوید:

Local UI State (مربوط به UI محلی): این نوع از state فقط برای مدیریت موارد خاصی در UI برنامه است. به طور مثال نمایش دادن backdrop در پروژه همبرگر ساز ما از این نوع state بود که فقط برای نمایش یک صفحه تیره پشت modal استفاده می شد. حتی اگر یادتان باشد خود باز شدن و بسته شدن modal را درون state مدیریت می کردیم. در این نوع از state و در اکثر اوقات نیازی به استفاده از redux نیست چرا که کار شما را پیچیده تر می کند، بهتر است از همان state داخلی در react استفاده کنید (البته در صورت علاقه، استفاده از redux اصلا مشکلی ندارد).

Persistent State: این نوع از state معمولا همان قسمتی از state است که در سمت پایگاه داده ذخیره می شود مثل لیست تمام کاربران و تمام پست ها و غیره. در این مورد باید به نکته ای مهم توجه داشته باشید: redux جایگزین پایگاه داده نیست، بلکه هر بار کاربر صفحه را refresh کند state به کلی نابود می شود (چه با redux و چه با غیر از آن). در این نوع از state ها پیشنهاد می شود از redux استفاده کنید چرا که کار شما را راحت تر می کند اما بدانید که داده ها در سمت پایگاه داده ذخیره شده و قسمت هایی از آن که به برنامه برگردانده می شود توسط redux مدیریت خواهد شد نه همه آن.

Client State: این نوع state مربوط به سمت کاربر بوده و شامل مواردی مانند احراز هویت کاربران و استفاده از فیلتر های خاص در جست و جو های کاربر و ... می شود. همانطور که می دانید این نوع داده ها در پایگاه داده ذخیره نمی شوند. مثلا نمی توانید login بودن یا نبودن کاربر را در پایگاه داده ذخیره کنید، این کار اصلا معنی ندارد. همچنین مواردی مثل فیلترهای جست و جو یا تنظیمات خاص مثل «حالت شب» و «استفاده از تم تیره» چیزهای مهمی نیستند و هیچکس آن ها را در پایگاه داده ذخیره نمی کند (معمولا در cookie ها و موارد مشابه ذخیره می شوند). این نوع از state تقریبا همیشه توسط redux مدیریت می شود و قدرت redux را نمایش می دهد چرا که این نوع از state ها (مثل حالت شب) روی چندین قسمت و کامپوننت از برنامه شما تاثیر می گذارند. مثال دیگر احراز هویت و login بودن کاربر است که بر اساس آن کامپوننت های خاصی نشان داده شده یا مخفی می شوند و داشتن یک state مرکزی مثل redux کمک بسیار بزرگی خواهد بود.

ما با این موارد در فصل های آینده به صورت عملی آشنا خواهیم شد و redux را به پروژه همبرگر ساز خودمان اضافه خواهیم کرد، سپس وارد موارد پیشرفته redux شده (مثل اجرای کد نامتقارن یا asynchronous) و سپس موارد پیشرفته را دوباره به همبرگر ساز اضافه می کنیم.

همچنین از مهم ترین نکات این دوره می توان به مبحث تغییر اشیاء و آرایه ها به صورت immutable اشاره کرد. بنده تقریبا یک قسمت کامل را صرف توضیح این موارد با مثال کردم. قبل از مطالعه بحث immutable بهتر است با تفاوت های بحث reference type و primitive type در جاوا اسکریپت آشنا باشید. به مثال زیر توجه کنید:

const number = 1;
const num2 = number;

console.log(num2);

خروجی این دستور عدد 1 است، در واقع عدد 1 کاملا کپی شده و درون num2 قرار گرفته است بنابراین اگر بعدا num2 را تغییر بدهیم هیچ تغییری در number ایجاد نخواهد شد چرا که از هم مستقل هستند. متغیرهای عددی، رشته ای و Boolean همگی از این نوع متغیر ها هستند که به آن ها primitive می گوییم اما اشیاء و آرایه ها از نوع refrence (به معنی «ارجاعی») هستند. به مثال زیر توجه کنید:

const Person = {
  name: 'Amir'
}
const secondPerson = Person;

console.log(secondPerson);

طبق انتظار خروجی دستور بالا Amir است اما شیء person و مقدار Amir درون متغیر secondPerson کپی نشده است بلکه متغیر secondPerson یک ارجاع ساده به همان شیء و مقدار اول است. یعنی چه؟ یعنی اگر مقدار secondPerson را تغییر دهیم، مقدار Person هم تغییر می کنند و در واقع یک مقدار هستند و از هم مستقل نمی باشند:

const Person = {
  name: 'Amir'
}
const secondPerson = Person;

Person.name = 'Mahdi';
console.log(secondPerson);

خروجی این دستور نام Mahdi خواهد بود!

ما می دانیم که برای مقادیر primitive اصلا چنین بحثی مطرح نبود و مقادیر واقعا کپی می شدند بنابراین با تغییر مقدار آن ها مقادیر دیگر تغییر پیدا نمیکرد. درک تفاوت primitive و reference در کار با React بسیار مهم است چرا که اگر اشیاء را به این شکل کپی کنیم باعث بروز مشکلات متعددی در برنامه خود می شویم. به طور مثال یک شیء را در هنگام کار با react تغییر می دهیم و متوجه می شویم که مقدار آن در چند جای دیگر نیز تغییر کرده است و برنامه ما بهم می ریزد! بنابراین برای جلوگیری از این مسئله باید مقادیر را به شکل immutable کپی کنیم (یعنی خود شیء یا مقدار واقعی را به صورت مستقل کپی کنیم). رعایت نکردن این مسئله باعث بروز مشکلات بزرگتری در هنگام کار با state می شود که در فصل های ابتدایی این دوره با آن آشنا شدیم. پیشنهاد من به شما مطالعه دوباره قسمت قبل برای واضح تر شدن مسئله است.