در مصاحبه‌های اخیرم چند بار این سوال از من پرسیده شده، به نظرم Josh Comeau در دوره The Joy of React خیلی خوب به این سوال جواب داده؛ در این پست بصورت خلاصه جواب Josh به این سوال رو بررسی می‌کنیم.

Josh در یک پست نسبتا طولانی توضیحاتی در این خصوص ارائه میده و سعی می‌کنه به این سوال پاسخ بده، ابتدا یه تاریخچه کوتاه در خصوص React و ارتباطش با ابزارهای مدیریت state ارائه میده، در ادامه بصورت خلاصه Redux رو معرفی می‌کنه و از مزایا و معایب این ابزار میگه و در نهایت این سوال رو مطرح می‌کنه: با توجه به پیشرفت‌هایی که React در سال‌های اخیر داشته آیا همچنان استفاده از ابزاری مثل Redux لازم هست یا نه؟

انواع stateها در React

قبل از اینکه بریم سراغ پاسخ به سوال مطرح شده بهتره انواع stateهایی که در یک اپلیکیشن Reactی داریم رو بشناسیم. بطور کلی می‌تونیم انواع state هایی که در یک اپلیکیشن Reactی داریم رو به دو دسته تقسیم کنیم:

• local state
• global state

local state یا state محلی فقط در یک بخش از اپلیکیشن استفاده میشه، برای مثال stateی که مقدار value یک input کنترل‌شده رو نگهداری می‌کنه. در مقابل global state یا state سراسری برای موارد گسترده‌تری استفاده میشه برای مثال اطلاعات مربوط به کاربری که در حال حاضر لاگین کرده (currently-logged-in user).

یک بخش از global state ممکنه در بخش‌های مختلف پروژه استفاده بشه و باید این امکان وجود داشته باشه که این نوع از state در بخش‌های مختلف اپلیکیشن در دسترس باشه، همچنین ضروری هست که تغییرات بصورت متمرکز روی این نوع از state‌ها انجام بشه. در نسخه‌های قدیمی React این امکان وجود نداشت و به همین دلیل استفاده از یک ابزار کمکی برای مدیریت state در پروژه‌ها یک best practice به حساب میومد.

در React مدرن با وجود Context و هوک useReducer مدیریت global state خیلی راحت‌تر شده و استفاده از یک ابزار کمکی برای مدیریت state تو خیلی از پروژه‌ها ضروری به نظر نمیرسه، با اینحال Josh استفاده از Redux رو کاملا منتفی نمی‌دونه و معتقد هست باید با توجه به نوع پروژه در خصوص استفاده از این ابزار تصمیم‌گیری صورت بگیره.

انواع اپلیکیشن‌ها

Josh اپلیکیشن‌ها را به سه دسته کلی تقسیم می‌کنه و در نهایت مشخص می‌کنه که کدوم دسته‌ از اپلیکیشن‌ها به Redux نیاز دارن و برای کدوم دسته از اپلیکیشن‌ها نیازی به استفاده از ابزارهای مدیریت state نیست.

۱- تعداد state ها زیاد نیست

این دسته شامل بیشتر مواردی هست که ما اونها رو “وب‌سایت” می‌نامیم. سایت‌های استاتیک (static)، وب‌سایت‌های خبری و وبلاگ‌ها همگی در این دسته قرار می‌گیرن. این اپلیکیشن‌ها همچنان ممکنه تعداد زیادی state محلی داشته باشن ولی state های سراسری خیلی کمی دارن.

۲- بیشتر stateها از نوع client هستن

این دسته بیشتر شامل مواردی میشه که قبلاً برنامه‌های دسکتاپ بودن. فتوشاپ، ویرایشگرهای ویدیو و پردازشگرهای متن، همگی در این دسته قرار می‌گیرن.

در این دسته، مقدار زیادی state سراسری پیچیده وجود داره. مقدار زیادی state manipulation در مرورگر انجام میشه و ممکنه نتیجه رو به جای دستگاه کاربر در فضای ابری ذخیره کنیم، اما اساساً برنامه‌هایی هستن که به شدت به client وابسته‌اند.

۳- بیشتر state‌ها از نوع سرور هستن

در دسته آخر، اپلیکیشن‌های وب رو داریم که در درجه اول با server state ها کار می‌کنن.

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

اکثر برنامه‌های CRUD در این دسته‌ جا می‌گیرن، از جمله اکثر برنامه‌های SaaS، شبکه‌های اجتماعی، موتورهای جستجو و سایت‌های تجارت الکترونیک.

انتخاب ابزار مناسب

در نهایت Josh پاسخ سوالی که در ابتدای پست مطرح شده را به این شکل میده:

برای وب‌سایت‌های عمدتاً استاتیک در دسته اول، وقتی صحبت از global state می‌شود، واقعاً لازم نیست نگران باشیم چون چیز زیادی از آن وجود ندارد. وبلاگ من در این دسته قرار می‌گیرد و اگرچه چالش‌های زیادی وجود دارد، global state یکی از آنها نیست. من منحصراً از React برای همه stateها استفاده می‌کنم و عالی کار می‌کند.

برای اپلیکیشن‌های client-heavy در دسته دوم، Redux فوق‌العاده است. من آنقدرها هم اصرار ندارم که بگویم ضروری است – React واقعاً در چند سال گذشته بسیار توانمندتر شده است – اما هنوز هم ابزاری بسیار مفید است! Redux به ساده نگه داشتن کد کمک می‌کند، حتی با اینکه ویژگی‌ها پیچیده‌تر و پیچیده‌تر می‌شوند. و بهینه‌سازی‌های عملکرد built-in زیادی دارد.

وقتی در مورد اپلیکیشن‌های server-heavy در دسته سوم صحبت می‌کنیم، اوضاع جالب می‌شود.

بزرگترین چالش‌های مرتبط با state در این دسته، همگی مربوط به شبکه یا network-related هستند:

• دریافت (fetching) داده‌های مناسب در زمان مناسب.
• اعتبارسنجی مجدد داده‌ها، تا مطمئن شوید که داده‌ها قدیمی (stale) نمی‌شوند.
• ذخیره داده‌ها به صورت کش (cache) تا کامپوننت‌های مختلف درخواست‌های غیرضروری را تکرار نکنند.
• به‌روزرسانی‌های خوش‌بینانه‌ی (optimistic) رابط کاربری، به طوری که ما نحوه‌ی رسیدگی به درخواست‌های شبکه را “پیش‌بینی” می‌کنیم.
• صفحه‌بندی (pagination)، درخواست بخش‌های کوچکی از داده‌ها و اجازه دادن به کاربر برای دریافت داده‌های جدید در صورت نیاز.

و نکته اینجاست: Redux واقعاً به هیچ‌کدام از آنها نمی‌پردازد! Redux یک ابزار مدیریت state است و در مسائل مرتبط با شبکه کمکی نمی‌کند.

در طول چند سال گذشته، ابزارهای متعددی مانند Apollo، react-query و SWR برای کمک به ما در مدیریت این نوع چالش‌های مرتبط با شبکه ساخته شده‌اند.

اگر در حال ساخت یک بازی ویدیویی یا یک ویرایشگر صوتی هستید، Redux عالی است. اما اکثر ما این نوع برنامه‌ها را نمی‌سازیم. حدس می‌زنم ۹۵٪ برنامه‌های React یا در دسته اول یا در دسته سوم قرار می‌گیرند.

جمع‌بندی

و در نهایت اینطور جمع‌بندی می‌کنه:

اگر یک وبسایت استاتیک باشد، فقط از React استفاده می‌کنم. برای پروژه‌های client-heavy از Redux استفاده می‌کنم و برای پروژه‌های server-heavy از React و ابزاری برای کمک به مسائل مرتبط با شبکه استفاده می‌کنم.

این فرمولی است که من بعد از سال‌ها تجربه و انجام ده‌ها پروژه پیدا کرده‌ام، اما بخش زیادی از این موضوع واقعاً به ترجیحات شخصی برمی‌گردد.

می‌توانم خیلی بی‌طرفانه بگویم: React در چند سال گذشته به طرز چشمگیری تکامل یافته و بسیار توانمندتر شده است. شما می‌توانید برنامه‌های بزرگ و پیچیده‌ای را بدون هیچ ابزار مدیریت stateی بسازید. به Redux نیازی ندارید و نباید برای یادگیری آن احساس فشار کنید.

اگر در React تازه‌کار هستید، پیشنهاد من این است: یک یا دو سال را صرف کنید تا در ساخت برنامه‌ها با React مهارت پیدا کنید. همیشه می‌توانید در آینده Redux را بررسی کنید و ببینید که آیا آن را مفید می‌دانید یا خیر!