چگونه کامپوننت‌های React خود را با Derived State ساده‌تر کنیم؟

درک حالت مشتق شده و مزایای آن

در توسعه رابط کاربری با React، استفاده از هوک‌هایی مانند useState برای مدیریت مقادیر پویا اجتناب‌ناپذیر است. اما یک اشتباه رایج، استفاده بیش از حد از useState است که اغلب به داده‌های تکراری و پیچیدگی‌های غیرضروری منجر می‌شود. برای مثال، ممکن است نام کامل کاربر را در یک حالت (state) جداگانه ذخیره کنید، در حالی که می‌توان آن را به راحتی از مقادیر firstName و lastName (که از props یا حالت‌های دیگر می‌آیند) محاسبه کرد. یا شاید داده‌های دریافت‌شده از یک کتابخانه مانند React Query را دوباره در یک useState محلی کپی کنید. این رویکرد می‌تواند مشکلات متعددی از جمله اشکال‌زدایی دشوارتر، رندرینگ‌های اضافی و مسائل همگام‌سازی را به وجود آورد.

در این بخش، به طور کامل با مفهوم "حالت مشتق شده" (Derived State) آشنا خواهید شد و خواهید آموخت که چگونه استفاده صحیح از آن می‌تواند کامپوننت‌های React شما را بهینه‌سازی کند. هدف این است که در پایان این آموزش، به درک درستی از زمان و نحوه استفاده از حالت مشتق شده به جای ذخیره سازی مستقیم آن برسید، تا کد React شما تمیزتر و قابل نگهداری‌تر شود.

حالت مشتق شده چیست؟

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

• Props: داده‌هایی که از یک کامپوننت والد به کامپوننت فعلی ارسال می‌شوند.


• حالت موجود (Existing state): متغیرهای حالت دیگری که قبلاً در کامپوننت شما تعریف شده‌اند.


• پارامترهای URL: داده‌هایی که از مسیرها یا رشته‌های کوئری (query strings) در آدرس URL به دست می‌آیند.


• داده‌های خارجی (External data): داده‌هایی که از طریق کتابخانه‌های فچینگ (مانند React Query) دریافت می‌شوند.

ذخیره‌سازی مقادیری که می‌توانند مشتق شوند در useState، پیچیدگی‌های غیرضروری را به سیستم اضافه می‌کند. این رویکرد به جای ساده‌سازی، بار اضافی بر دوش توسعه‌دهنده و عملکرد برنامه می‌گذارد.

چالش‌های عدم استفاده از حالت مشتق شده

ذخیره‌سازی حالت‌های قابل اشتقاق در useState می‌تواند چندین مشکل اساسی ایجاد کند. در وهله اول، این کار منجر به مشکلات اشکال‌زدایی می‌شود: هرچه متغیرهای حالت بیشتری داشته باشید، ردیابی جریان داده‌ها دشوارتر خواهد بود. هنگام اشکال‌زدایی، باید تغییرات حالت‌های بیشتری را دنبال کنید که فرایند را طولانی و پیچیده می‌کند.

دوم، می‌تواند باعث رندرینگ‌های غیرضروری شود. React هر بار که تابع setter یک حالت را فراخوانی می‌کنید، رندر مجدد را آغاز می‌کند. اگر شما مقادیری مانند fullName یا isAdult را به عنوان حالت‌های مجزا ذخیره کنید، هر تغییر در firstName، lastName یا age (که منبع این مقادیر هستند) ابتدا باعث رندر مجدد برای آن حالت‌های منبع می‌شود، و سپس به‌روزرسانی حالت‌های مشتق‌شده (که به صورت دستی از طریق useEffect یا مستقیماً انجام می‌شود) یک رندر مجدد دیگر را trigger می‌کند. این یعنی کامپوننت شما به جای یک بار، دو بار یا بیشتر رندر می‌شود، که عملکرد برنامه را تحت تأثیر قرار می‌دهد.

سوم، مشکلات همگام‌سازی می‌تواند بروز کند. زمانی که داده‌های مشابه در چندین حالت وجود دارند، به راحتی از همگام‌سازی خارج می‌شوند. شما مجبور می‌شوید "حالت مشتق شده" را هر بار که داده‌های منبع تغییر می‌کنند، به صورت دستی به‌روزرسانی کنید. به عنوان مثال، اگر ایمیل را که از طریق props دریافت می‌شود، در یک useState محلی ذخیره کنید، هر تغییر در prop ایمیل در کامپوننت والد، نیاز به یک useEffect برای به‌روزرسانی حالت محلی دارد، که این خود باعث رندر مجدد اضافی و احتمال نمایش داده‌های قدیمی می‌شود.

مزایای حالت مشتق شده و کاهش پیچیدگی

با استفاده از حالت مشتق شده، می‌توانید بسیاری از این مشکلات را حل کنید و کد خود را به طرز چشمگیری بهبود بخشید. مقادیری مانند fullName یا isAdult نیازی به ورودی مستقیم کاربر ندارند تا ارزش آن‌ها مشخص شود؛ شما می‌توانید این مقادیر را به صورت لحظه‌ای و در زمان نیاز، هنگام تغییر حالت‌های وابسته به آن‌ها، محاسبه کنید. به همین ترتیب، می‌توانید ایمیل را مستقیماً از مقدار prop آن استخراج کنید.

این رویکرد مزایای بسیاری دارد:

• کاهش رندرینگ‌های اضافی: کامپوننت‌ها تنها زمانی رندر می‌شوند که داده‌های منبع اصلی تغییر کنند، نه مقادیر مشتق شده. این به معنی رندرینگ‌های کمتر و عملکرد بهتر است. برای مثال، فرمی که از حالت مشتق شده استفاده می‌کند، تنها یک بار برای هر تغییر در ورودی‌های ضروری (مثل firstName، lastName، age) رندر می‌شود، به جای دو بار یا بیشتر.


• حذف مشکلات همگام‌سازی: نیازی به useEffect برای همگام‌سازی داده‌ها نخواهید داشت، زیرا تنها یک منبع حقیقت (مانند URL یا داده‌های React Query) را مدیریت می‌کنید. این تضمین می‌کند که داده‌ها همیشه به‌روز و همگام هستند.


• کد کمتر و قابل نگهداری‌تر: با حذف useState و useEffectهای اضافی، کد شما کوتاه‌تر، خواناتر و آسان‌تر برای نگهداری می‌شود. این به خصوص در پروژه‌های بزرگ با کامپوننت‌های پیچیده اهمیت می‌یابد.


• دیباگینگ آسان‌تر: تعداد کمتر متغیرهای حالت به معنی جریان داده‌ای شفاف‌تر و ردیابی آسان‌تر تغییرات هنگام دیباگینگ است.

چه زمانی باید از useState استفاده کرد؟

با وجود تمام مزایای حالت مشتق شده، مواردی وجود دارد که استفاده از useState ضروری است. شما باید از useState برای مدیریت ورودی‌های کنترل شده (Controlled Inputs) استفاده کنید. در این حالت، شما می‌خواهید مقدار ورودی کاربر را همزمان با تایپ کردن ردیابی کرده و آن را با حالت کامپوننت همگام نگه دارید. این مقدار مستقیماً از تعامل کاربر نشأت می‌گیرد و قابل اشتقاق از هیچ منبع داخلی دیگری نیست. برای مثال، برای اعتبارسنجی نام کاربری و تغییر رنگ حاشیه آن بر اساس ورودی کاربر، به useState نیاز دارید.

همچنین، زمانی که یک مقدار می‌تواند بدون وابستگی به سایر حالت‌ها یا props تغییر کند، باید از useState استفاده کنید. به عنوان مثال، برای مدیریت وضعیت باز یا بسته بودن یک مدال (Modal)، به useState نیاز دارید، زیرا وضعیت آن مستقل از دیگر داده‌های کامپوننت است و مستقیماً توسط تعامل کاربر یا منطق کامپوننت تغییر می‌کند. به یاد داشته باشید که هر مقداری را که می‌توانید محاسبه کنید، نباید ذخیره کنید و فقط باید آن دسته از مقادیری را ذخیره کنید که قابل اشتقاق نیستند. با حداقل نگه داشتن حالت‌ها و اشتقاق زمانی که امکان‌پذیر است، دیباگینگ و نگهداری کامپوننت‌های شما بسیار آسان‌تر خواهد بود.

استخراج حالت از Props و دیگر Stateها

در توسعه‌ی رابط کاربری با React، استفاده از هوک useState برای مدیریت مقادیر پویا اجتناب‌ناپذیر است. با این حال، استفاده‌ی بی‌رویه و نادرست از useState برای ذخیره‌سازی مقادیری که می‌توانند از داده‌های موجود دیگر، مانند Props (داده‌های ورودی از والد) یا سایر Stateهای داخلی کامپوننت، مشتق یا محاسبه شوند، بسیار رایج است. این رویکرد به تکرار داده‌ها، پیچیدگی‌های غیرضروری و مشکلات متعددی از جمله اشکال‌زدایی دشوارتر، بازرندرهای اضافی و مسائل همگام‌سازی منجر می‌شود.

برای مثال، نگهداری نام کامل کاربر در حالت، در حالی که می‌توان آن را به راحتی از نام و نام خانوادگی موجود محاسبه کرد، یک نمونه از این اشتباهات است. همچنین، ممکن است به اشتباه یک کپی محلی از ایمیل دریافتی از طریق Props را در useState ذخیره کنید. در هر دو حالت، با ذخیره‌سازی مقادیری که قابل اشتقاق هستند، به جای سادگی، پیچیدگی و ناکارآمدی به ارمغان می‌آورید. هدف این بخش، آموزش نحوه‌ی صحیح استخراج حالت برای بهبود کامپوننت‌های React و دستیابی به کدی پاکیزه‌تر و قابل نگهداری‌تر است.

مفهوم و اهمیت حالت مشتق شده

"حالت مشتق شده" (Derived State) هر مقداری است که می‌توان آن را از داده‌های موجود دیگر محاسبه کرد. این داده‌های موجود، به طور خاص برای این بخش، شامل موارد زیر هستند:

• Props: داده‌هایی که از یک کامپوننت والد دریافت می‌شوند.


• Existing State: متغیرهای حالت دیگری که قبلاً در همان کامپوننت تعریف شده‌اند.

ذخیره کردن حالت‌های قابل اشتقاق در useState مشکلات متعددی ایجاد می‌کند: اول، اشکال‌زدایی دشوار می‌شود زیرا ردیابی جریان داده در میان متغیرهای حالت متعدد پیچیده‌تر می‌گردد. دوم، بازرندرهای غیرضروری به وجود می‌آیند؛ هر بار که تابع تنظیم‌کننده‌ی حالت برای یک مقدار مشتق شده فراخوانی شود، یک بازرندر اضافی رخ می‌دهد. سوم، مسائل همگام‌سازی بروز می‌کنند؛ مجبور به به‌روزرسانی دستی حالت مشتق شده با استفاده از useEffect خواهید بود، که خود می‌تواند منجر به بازرندرهای بیشتر یا نمایش داده‌های قدیمی شود. این مسائل همگی عملکرد را کاهش داده و پیچیدگی و شکنندگی کد را افزایش می‌دهند.

چالش‌های رایج: حالت‌های اضافی در فرم‌ها

تصور کنید یک کامپوننت فرم، حالت‌های غیرضروری مانند fullName، isAdult و localEmail (کپی از پراپ ایمیل) را ذخیره می‌کند. در چنین سناریویی، هر تغییر در نام کوچک، نام خانوادگی یا سن کاربر که منطقاً باید منجر به یک بازرندر شود، به دلیل به‌روزرسانی حالت‌های اضافی (مانند fullName یا isAdult)، باعث بازرندرهای مضاعف می‌گردد. مثلاً، با تغییر سن، ابتدا برای age و سپس برای isAdult بازرندر اتفاق می‌افتد. به همین ترتیب، اگر prop ایمیل از والد تغییر کند و در localEmail ذخیره شده باشد، نیاز به همگام‌سازی (معمولاً با useEffect) منجر به بازرندر اضافی می‌شود یا بدون آن، داده‌ها قدیمی می‌مانند. این رویکرد به جای سادگی، پیچیدگی و ناکارآمدی را به همراه دارد.

راهکار: استخراج پویا و مزایای آن

راه حل تمامی این مشکلات استفاده از حالت‌های مشتق شده است. مقادیری مانند fullName و isAdult نیازی به ذخیره‌سازی در useState ندارند. شما می‌توانید آنها را به صورت پویا و در زمان رندر، مستقیماً از حالت‌های وابسته‌شان (firstName, lastName, age) محاسبه کنید. به عنوان مثال، fullName را با ترکیب firstName و lastName و isAdult را با یک بررسی شرطی (age >= 18) به‌دست آورید. به همین ترتیب، email را می‌توان مستقیماً از prop آن استفاده کرد و نیازی به کپی محلی در حالت نیست.

با این رویکرد بهینه، فرم تنها حالت‌های اصلی و ضروری را نگهداری می‌کند. مزایای این کار بسیار زیاد است:

• کاهش چشمگیر بازرندرها: کامپوننت تنها زمانی رندر می‌شود که داده‌های اصلی تغییر کنند.


• حذف مشکلات همگام‌سازی: با حذف حالت‌های اضافی و عدم نیاز به useEffect، پیچیدگی کد کاهش یافته و منبع حقیقت واحد حفظ می‌شود.


• کد تمیزتر و قابل نگهداری‌تر: کد شما کمتر، خواناتر و منطقی‌تر خواهد بود که نگهداری و اشکال‌زدایی آن را آسان‌تر می‌کند.

مرز بین useState و حالت‌های مشتق شده

با وجود مزایای حالت‌های مشتق شده، در برخی موارد استفاده از useState ضروری است. از جمله این موارد، ساخت ورودی‌های کنترل‌شده (Controlled Inputs) است؛ جایی که useState برای ردیابی مقدار ورودی کاربر و همگام‌سازی آن با حالت کامپوننت لازم است، چرا که مقدار مستقیماً از تعامل کاربر نشأت می‌گیرد. همچنین، برای مقادیری که تغییر آن‌ها مستقل از سایر حالت‌ها یا Props است (مثلاً برای وضعیت باز یا بسته بودن یک مودال)، باید از useState استفاده شود. این‌ها حالت‌هایی هستند که به طور طبیعی قابل اشتقاق نیستند و نیاز به مدیریت مستقل دارند.

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

استفاده از URL به عنوان منبع حقیقت

در دنیای توسعه فرانت‌اند با React، مدیریت وضعیت (state) بهینه از اهمیت بالایی برخوردار است. یکی از منابع قدرتمند و اغلب نادیده گرفته شده برای مدیریت وضعیت پویا، آدرس اینترنتی (URL) است. URL، چه از طریق پارامترهای مسیر (route parameters) و چه رشته‌های جستجو (query strings)، می‌تواند داده‌های لازم برای کامپوننت‌های شما را فراهم کند. کتابخانه‌های مسیریابی رایج، مانند React Router، هوک‌های مفیدی مثل useParams و useSearchParams را ارائه می‌دهند که دسترسی به این داده‌ها را به سادگی ممکن می‌سازند. با این حال، اشتباه رایجی که بسیاری از توسعه‌دهندگان مرتکب می‌شوند، ذخیره‌سازی مجدد این مقادیر در useState است، در حالی که می‌توان آن‌ها را مستقیماً از URL استخراج (derive) کرد.

چرا URL می‌تواند منبع حقیقت باشد؟

یک "وضعیت مشتق‌شده" (derived state) به هر مقداری اطلاق می‌شود که می‌توان آن را از داده‌های موجود محاسبه یا استخراج کرد. وقتی صحبت از URL به میان می‌آید، این به معنای استفاده از پارامترهای URL یا رشته‌های جستجو به عنوان داده‌های مبدأ است. با این رویکرد، URL به عنوان "منبع حقیقت واحد" (Single Source of Truth) عمل می‌کند. این بدان معناست که دیگر نیازی به نگهداری دو محل ذخیره‌سازی برای یک داده (یکی در URL و دیگری در وضعیت داخلی useState کامپوننت) نخواهد بود. این مفهوم به ما کمک می‌کند تا از پیچیدگی‌های غیرضروری و مشکلات همگام‌سازی که در اثر تکرار داده‌ها به وجود می‌آیند، اجتناب کنیم. به جای نگهداری وضعیت فیلترها، جستجوها یا شناسه‌های محصول در useState، می‌توانیم این اطلاعات را مستقیماً از URL بخوانیم.

معایب ذخیره وضعیت URL در useState

ذخیره‌سازی مقادیری که از URL مشتق می‌شوند، در useState مشکلات متعددی ایجاد می‌کند که بر عملکرد و قابلیت نگهداری کد تأثیر منفی می‌گذارند. اولین و مهم‌ترین مشکل، رندرینگ‌های اضافی و غیرضروری است. هنگامی که یک کامپوننت برای همگام‌سازی وضعیت داخلی خود با URL، از useEffect استفاده می‌کند، هرگونه تغییر در URL ابتدا باعث یک رندر می‌شود، و سپس useEffect با به‌روزرسانی useState محلی، یک رندر دیگر را تحریک می‌کند. این وضعیت می‌تواند منجر به دو تا سه رندر برای هر تغییر شود، در حالی که تنها یک رندر کافی است.

مشکل دوم، مسائل همگام‌سازی است. وقتی داده‌های مشابهی در دو مکان (URL و useState) ذخیره می‌شوند، اطمینان از اینکه هر دو همیشه همگام و به‌روز هستند، دشوار می‌شود. برای مثال، در یک کامپوننت فیلتر که پارامترهای جستجو را هم در URL و هم در useState نگهداری می‌کند، تغییر یک فیلتر نیازمند به‌روزرسانی هر دو منبع است. اگر useState قبل از URL به‌روز نشود، رابط کاربری ممکن است داده‌های قدیمی را نمایش دهد. این نیاز به مدیریت دستی همگام‌سازی، کد را پیچیده‌تر کرده، اشکال‌زدایی را دشوارتر ساخته و احتمال بروز خطا را افزایش می‌دهد. همچنین، با افزایش تعداد وضعیت‌های داخلی، ردیابی جریان داده‌ها و تشخیص منشأ مشکلات دشوارتر می‌شود.

استخراج مستقیم وضعیت از URL: راه حلی بهینه

راه حل این مشکلات، همانطور که اشاره شد، استخراج مستقیم وضعیت از URL است. به جای اینکه مقادیر پارامترهای URL را در useState محلی کامپوننت ذخیره کنیم، می‌توانیم در هر رندر، آن‌ها را مستقیماً با استفاده از هوک‌های مربوطه (مانند useSearchParams یا useParams) بخوانیم. با این رویکرد، دیگر نیازی به useEffect برای همگام‌سازی وضعیت با URL نخواهد بود. هنگامی که کاربر فیلترها را تغییر می‌دهد یا یک عبارت جستجو وارد می‌کند، تنها کاری که باید انجام دهیم، به‌روزرسانی URL است. مرورگر به طور طبیعی کامپوننت را دوباره رندر می‌کند و مقادیر جدید به طور خودکار از URL خوانده شده و در رابط کاربری نمایش داده می‌شوند.

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

مزایای کلیدی رویکرد استخراج وضعیت از URL

به کارگیری استراتژی استخراج وضعیت به صورت مستقیم از URL، مزایای متعددی را برای توسعه‌دهندگان React به ارمغان می‌آورد:

• بهینه‌سازی عملکرد: با حذف useState و useEffectهای غیرضروری، تعداد رندرینگ‌های کامپوننت به حداقل می‌رسد، که منجر به بهبود چشمگیر عملکرد برنامه و تجربه کاربری روان‌تر می‌شود.


• کاهش پیچیدگی: نگهداری تنها یک منبع حقیقت برای داده‌ها، کد را ساده‌تر، خواناتر و قابل فهم‌تر می‌کند. این امر به کاهش زمان توسعه و افزایش بهره‌وری کمک می‌کند.


• همگام‌سازی خودکار: URL به طور طبیعی یک مکانیزم همگام‌سازی داخلی را فراهم می‌کند. تغییرات در URL به طور خودکار بازتاب‌دهنده وضعیت برنامه هستند و نیاز به منطق همگام‌سازی دستی را از بین می‌برند.


• اشکال‌زدایی آسان‌تر: با داشتن یک منبع حقیقت واحد، ردیابی جریان داده‌ها و یافتن منشأ مشکلات احتمالی در برنامه به مراتب ساده‌تر می‌شود.


• قابلیت اشتراک‌گذاری وضعیت: وضعیت برنامه که در URL کدگذاری شده است، به راحتی قابل اشتراک‌گذاری است. کاربران می‌توانند لینک‌های حاوی وضعیت خاصی از برنامه را کپی و برای دیگران ارسال کنند.

در نهایت، با اتخاذ این رویکرد هوشمندانه، توسعه‌دهندگان می‌توانند کامپوننت‌های React را با معماری پاک‌تر و پایداری بیشتر بسازند که هم در کوتاه‌مدت و هم در درازمدت، نگهداری و توسعه آن‌ها آسان‌تر خواهد بود.

یکپارچه‌سازی با کتابخانه‌های واکشی داده

در توسعهٔ رابط کاربری با React، واکشی داده از منابع خارجی یک نیاز اساسی است. کتابخانه‌هایی مانند React Query ابزارهای قدرتمندی برای مدیریت وضعیت مربوط به این داده‌ها، از جمله خود داده‌ها، وضعیت بارگذاری (isFetching) و خطاها (error)، ارائه می‌دهند. با این حال، یک اشتباه رایج در میان توسعه‌دهندگان، ذخیره‌سازی مجدد این وضعیت‌های ارائه‌شده توسط کتابخانه، در یک وضعیت محلی (local state) با استفاده از `useState` است. این رویکرد، در نگاه اول ممکن است ساده به نظر برسد، اما به سرعت منجر به پیچیدگی‌های غیرضروری، تکرار داده‌ها، مشکلات همگام‌سازی و افزایش تعداد رندرهای مجدد کامپوننت می‌شود.

هدف اصلی از استفاده از "وضعیت مشتق‌شده" (derived state)، جلوگیری از ذخیره‌سازی مقادیری است که می‌توانند از داده‌های موجود محاسبه یا استخراج شوند. هنگامی که یک کتابخانه واکشی داده، خود منبعی مطمئن برای وضعیت مورد نیاز ماست، نیازی نیست که این داده‌ها را کپی کرده و در `useState` مجدداً ذخیره کنیم. این عمل نه تنها کد ما را حجیم‌تر می‌کند، بلکه ردیابی جریان داده را در هنگام دیباگ دشوارتر ساخته و مدیریت به‌روزرسانی‌ها را پیچیده‌تر می‌سازد.

مشکلات ذخیره‌سازی اضافی وضعیت React Query

برای درک بهتر این موضوع، سناریویی را در نظر بگیرید که یک کامپوننت React به نام `UserDetail` وظیفه نمایش جزئیات کاربر را بر عهده دارد. این کامپوننت، شناسه کاربر را از پارامترهای URL دریافت کرده و از `useQuery` از کتابخانه React Query برای واکشی داده‌های کاربر استفاده می‌کند. React Query به صورت داخلی وضعیت‌هایی نظیر `data` (داده واکشی‌شده)، `isFetching` (وضعیت بارگذاری) و `error` (خطا) را مدیریت می‌کند. اما برخی توسعه‌دهندگان تمایل دارند که این وضعیت‌ها را در `useState`های محلی کامپوننت خود، مانند `user`، `loading` و `error`، تکرار کنند.

این تکرار وضعیت منجر به مشکلات متعددی می‌شود. به عنوان مثال، هنگام بارگذاری اولیه کامپوننت، ممکن است کامپوننت تا چهار بار رندر شود. رندر اول برای بارگذاری اولیه، سپس تغییرات وضعیت داخلی React Query باعث رندر دوم می‌شود. اما از آنجایی که ما یک وضعیت محلی نیز نگهداری می‌کنیم، نیاز به استفاده از `useEffect` برای همگام‌سازی این وضعیت محلی با داده‌های دریافتی از React Query داریم، که این خود باعث رندرهای سوم و چهارم می‌شود. این چرخهٔ رندر مجدد غیرضروری، به ویژه در کامپوننت‌های پیچیده، می‌تواند به شدت بر عملکرد برنامه تاثیر بگذارد.

یکی دیگر از مسائل بحرانی، عدم همگام‌سازی بین وضعیت React Query و وضعیت محلی است. در طول فرآیند واکشی داده، برای لحظاتی ممکن است `data` در React Query حاوی اطلاعات جدید باشد، در حالی که وضعیت `user` محلی ما هنوز مقادیر قدیمی یا `undefined` را نشان می‌دهد. این ناهمگونی می‌تواند به نمایش داده‌های منسوخ‌شده (stale data) یا باگ‌های دشوار در رابط کاربری منجر شود. بدتر از آن، هنگام تغییر شناسه کاربر و واکشی مجدد اطلاعات، این مشکلات تشدید می‌شوند و تعداد رندرهای غیرضروری می‌تواند به شش بار یا بیشتر نیز برسد، که هر بار نیاز به همگام‌سازی دستی و دردسرساز دارد.

راهکار: React Query به عنوان منبع واحد حقیقت

راه‌حل این مشکلات، در پذیرش مفهوم "منبع واحد حقیقت" (single source of truth) نهفته است. هنگامی که از کتابخانه‌های واکشی داده مانند React Query استفاده می‌کنیم، باید اجازه دهیم که این کتابخانه‌ها به عنوان تنها منبع مدیریت وضعیت برای داده‌های خارجی عمل کنند. به جای ایجاد `useState`های محلی برای ذخیرهٔ کپی از `data`، `isFetching` و `error`، باید مستقیماً از مقادیری که `useQuery` یا هوک‌های مشابه در اختیار ما قرار می‌دهند، استفاده کنیم. این بدان معناست که وضعیت مورد نیاز ما مستقیماً از نتیجهٔ هوک کتابخانه مشتق می‌شود و نیازی به ذخیره‌سازی مجدد نیست.

با استفاده از وضعیت مشتق‌شده، `data`، `isFetching` و `error` از خروجی `useQuery` به طور مستقیم در منطق رندر کامپوننت ما مورد استفاده قرار می‌گیرند. این رویکرد چندین مزیت کلیدی را به همراه دارد:

• کاهش رندرهای غیرضروری: تعداد رندرها به حداقل می‌رسد. در مثال `UserDetail`، کامپوننت تنها دو بار در بارگذاری اولیه (یک بار برای مانت اولیه و یک بار برای تغییر وضعیت React Query) و سه بار برای واکشی کاربر جدید رندر می‌شود. این یک بهبود قابل توجه نسبت به چهار یا شش رندر قبلی است.


• رفع مشکلات همگام‌سازی: از آنجایی که تنها یک منبع حقیقت وجود دارد، دیگر نیازی به همگام‌سازی دستی با `useEffect` نیست و مشکلات مربوط به داده‌های ناسازگار یا منسوخ‌شده کاملاً برطرف می‌شود.


• کد تمیزتر و قابل نگهداری‌تر: با حذف `useState`های اضافی و `useEffect`های مربوط به همگام‌سازی، حجم کد کاهش یافته و خوانایی و نگهداری آن آسان‌تر می‌شود.


• دیباگ ساده‌تر: جریان داده شفاف‌تر شده و ردیابی وضعیت در هنگام دیباگ بسیار راحت‌تر می‌شود، زیرا تنها یک مکان برای بررسی منشأ داده وجود دارد.

بهینه‌سازی محاسبات مشتق‌شده

در اکثر موارد، محاسبات لازم برای مشتق‌سازی وضعیت به سرعت انجام می‌شوند و نیازی به بهینه‌سازی خاصی نیست. اما اگر وضعیت مشتق‌شده شما شامل محاسبات سنگین و پرهزینه باشد، می‌توانید از هوک‌های `useMemo` و/یا `memo` برای جلوگیری از انجام کار غیرضروری در هر رندر استفاده کنید. با `useMemo`، متغیر نتیجه تنها زمانی دوباره محاسبه می‌شود که وابستگی‌های آن (مثلاً `product.data`) تغییر کنند. این تضمین می‌کند که کامپوننت فرزند (مثلاً `<Result />`) تا زمانی که داده‌های پایه تغییر نکرده‌اند، ثابت می‌ماند و از رندرهای غیرضروری جلوگیری می‌کند.

در نهایت، مدیریت وضعیت یکی از چالش‌برانگیزترین بخش‌های توسعه با React است. اصل اساسی این است: آنچه را که می‌توانید محاسبه کنید، ذخیره نکنید و تنها آنچه را که نمی‌توانید از منابع دیگر مشتق کنید، ذخیره نمایید. با به حداقل رساندن وضعیت‌های محلی و استفاده از وضعیت مشتق‌شده در هر زمان ممکن، کدهای React شما پاکیزه‌تر، قابل نگهداری‌تر و کارآمدتر خواهند بود.

چه زمانی همچنان از useState استفاده کنیم؟

ورودی‌های کنترل شده (Controlled Inputs)

در حالی که تمرکز اصلی این مقاله بر استفاده از حالت‌های مشتق شده (derived states) در React برای بهبود عملکرد و کاهش پیچیدگی است، موارد خاصی وجود دارد که در آن‌ها `useState` همچنان ضروری و بهترین گزینه است. یکی از مهم‌ترین این موارد، هنگام پیاده‌سازی ورودی‌های کنترل شده (Controlled Inputs) در فرم‌ها است. در یک ورودی کنترل شده، کامپوننت React مسئولیت کامل مدیریت و به‌روزرسانی مقدار ورودی را بر عهده دارد. برای این منظور، شما به `useState` نیاز دارید تا مقدار فعلی ورودی کاربر را مدیریت کرده و آن را با حالت داخلی کامپوننت همگام نگه دارید. این ضرورت به دو دلیل اصلی است: اولاً، شما می‌خواهید مقدار ورودی کاربر را به محض تایپ کردن ردیابی کنید. این ردیابی لحظه‌ای برای ارائه بازخورد فوری به کاربر (مانند اعتبارسنجی زنده یا فیلتر کردن نتایج جستجو) حیاتی است. ثانیاً، مقدار ورودی مستقیماً از تعامل کاربر با رابط کاربری (UI) نشأت می‌گیرد و یک حالت مستقل محسوب می‌شود که نمی‌توان آن را به سادگی از سایر props یا stateهای موجود مشتق کرد. بنابراین، `useState` به عنوان منبع حقیقت اصلی برای این مقدار پویا عمل می‌کند. با استفاده از `useState` برای ردیابی مقدار ورودی، می‌توانیم به راحتی اعتبارسنجی‌های پیچیده را انجام دهیم و بر اساس وضعیت اعتبارسنجی، ظاهر عنصر ورودی (مانند تغییر رنگ حاشیه) را به سرعت به‌روزرسانی کنیم. این کنترل دقیق بر ورودی‌ها نه تنها تجربه کاربری بهتری را فراهم می‌کند، بلکه مدیریت منطق‌های تجاری پیچیده‌تر مرتبط با فرم‌ها را نیز به توسعه‌دهنده می‌دهد. بدون `useState`، پیاده‌سازی چنین قابلیت‌هایی برای ورودی‌های کنترل شده دشوار یا حتی غیرممکن خواهد بود و اهمیت آن را در تعاملات پیچیده رابط کاربری برجسته می‌کند.

تغییرات حالت مستقل (Independent State Changes)

علاوه بر ورودی‌های کنترل شده، مورد دیگری که در آن استفاده از `useState` کاملاً ضروری و منطقی است، زمانی است که یک مقدار خاص در کامپوننت شما می‌تواند به طور کاملاً مستقل تغییر کند و هیچ وابستگی مستقیمی به سایر حالت‌ها (state) یا ویژگی‌ها (props) نداشته باشد. به عبارت دقیق‌تر، اگر یک تکه از داده در کامپوننت وجود دارد که به طور ذاتی مستقل است و نمی‌توان آن را به سادگی از داده‌های موجود دیگر در کامپوننت یا از طریق props، پارامترهای URL یا حتی داده‌های فچ‌شده از API محاسبه یا مشتق کرد، آنگاه باید آن را در `useState` ذخیره کنید. این نوع حالت‌ها اغلب وضعیت‌های داخلی و منحصر به فرد یک کامپوننت را نشان می‌دهند که هیچ منبع دیگری برای استنباط یا محاسبه آن‌ها وجود ندارد. به عنوان مثال، در نظر بگیرید که یک کامپوننت modal (یک پنجره پاپ‌آپ یا دیالوگ) دارید. وضعیت باز یا بسته بودن این modal یک حالت کاملاً مستقل است. باز شدن یا بسته شدن آن معمولاً توسط یک رویداد کاربری (مانند کلیک روی یک دکمه) تعیین می‌شود و به طور مستقیم از props یا سایر حالت‌های کامپوننت مشتق نمی‌شود. منطق نمایش یا پنهان‌سازی modal کاملاً به خودش وابسته است و نیاز به یک پرچم (flag) داخلی برای مدیریت دارد. در چنین مواردی، برای ردیابی اینکه آیا modal در حال حاضر قابل مشاهده است (باز است) یا خیر (بسته است)، به `useState` نیاز دارید تا این وضعیت را نگهداری کند. مثال‌های دیگر برای حالت‌های مستقل عبارتند از: وضعیت فعال/غیرفعال بودن یک دکمه؛ وضعیت نمایش/عدم نمایش یک منوی کشویی؛ یا پرچم بارگذاری (loading state) برای عملیات‌های شبکه. کلید تصمیم‌گیری این است که آیا این مقدار واقعاً نیاز به یک «منبع حقیقت» مستقل در داخل کامپوننت دارد که توسط هیچ چیز دیگری قابل استنباط یا محاسبه نیست.

جمع‌بندی و توصیه‌های نهایی

مدیریت حالت (state management) یکی از چالش‌برانگیزترین بخش‌ها در توسعه با React است و درک صحیح آن، تفاوت چشمگیری در کیفیت و کارایی کد شما ایجاد می‌کند. توصیه نهایی و اصلی این مقاله بر یک اصل کلیدی استوار است: هرگز نباید چیزی را که می‌توانید از داده‌های موجود دیگر در کامپوننت (مانند props، سایر stateها، پارامترهای URL یا داده‌های فچ‌شده) محاسبه یا "مشتق" کنید، به عنوان یک حالت مستقل جدید (با `useState`) ذخیره کنید. این کار منجر به تکرار داده، رندرینگ‌های اضافی و مشکلات همگام‌سازی می‌شود. در مقابل، رویکرد صحیح این است که فقط مقادیری را به عنوان حالت ذخیره کنید که به هیچ وجه نمی‌توانید آن‌ها را به طور منطقی و بدون ایجاد پیچیدگی غیرضروری از سایر منابع موجود مشتق کنید. با رعایت این اصل و به حداقل رساندن تعداد حالت‌ها در کامپوننت‌های خود و استفاده هوشمندانه از حالت‌های مشتق شده (derived states) در هر زمان که ممکن است، مزایای بی‌شماری را تجربه خواهید کرد. این رویکرد نه تنها به شما کمک می‌کند تا از رندرینگ‌های اضافی و بی‌مورد کامپوننت‌ها جلوگیری کنید، بلکه فرآیند اشکال‌زدایی (debugging) و نگهداری (maintenance) کامپوننت‌هایتان نیز به مراتب ساده‌تر و کارآمدتر خواهد شد. داشتن یک "منبع حقیقت" (single source of truth) واضح و مشخص برای هر قطعه از داده، از مشکلات رایج همگام‌سازی (synchronization issues) جلوگیری می‌کند و به شما کمک می‌کند تا کدی تمیزتر، قابل پیش‌بینی‌تر و با کارایی بالاتر بنویسید. با تکیه بر این دانش، در مسیر تبدیل شدن به یک توسعه‌دهنده React حرفه‌ای گام بردارید و برنامه‌هایی با کیفیت بالاتر ارائه دهید.