مدیریت ریکوئست ها با React Query در React

React Queryیکی از لایبرری های محبوب جاوااسکریپت که توی ری اکت خیلی ازش استفاده میشه React Query هستش، این لایبرری ابزارای زیادی رو برای fetch کردن، cache کردن و update کردن دیتا از ‌API در اختیار ما میزاره و به ما کمک میکنه با مدیریت صحیح و بهینه ی ریکوئست هامون اپلیکیشن های پر سرعت و روان و تر تمیزی داشته باشیم.فواید کلیدی این لایبرری که هر برنامه نویسی رو وسوسه میکنه تا باهاش کار کنه:آسان تر کردن مدیریت دیتا: React Query مدیریت دیتای ریموت در اپلیکیشن ما با در اختیار گذاشتن ابزارهای خفنی برای fetching, caching و updating دیتا، سناریو های پیچیده مدیریت دیتا مثل paginations , optimistic updates و server-side rendering رو آسون تر میکنه.بهتر کردن پرفورمنس اپلیکیشن: React Query با کش کردن و Refetch کردن هوشمندانه ی دیتا فقط زمانی که به اینکار نیاز داریم، با کم کردن مقدار ریکوئست های غیر ضروری تاثیر زیادی در پرفورمنس اپلیکیشن ما میزاره.از بین بردن کد های غیرضروری: ‌ React Query مارو از نوشتن کدای غیر ضروری برای مدیریت دیتا بی نیاز میکنه که باعث حفظ زمان بیشتری میشه و به برنامه نویس این امکان رو میده که روی منطق پروژه و کامپوننت ها تمرکز داشته باشه و هیچ نگرانی درباره ی گرفتن و کش کردن دیتا نداشته باشه.آپدیت لحظه ای: React Query با استفاده از کانکشن های websocket و مابقی API های استریم، به ما این امکان رو میده تا آپدیت لحظه ای دیتارو داشته باشیم و نیازی نباشه کاربر رو برای اپدیت کردن دیتا مجبور به ریفرش صفحه بکنیم.توی این مقاله میریم سراغ قابلیت های کلیدی این لایبرری و بهتون نشون میدم که چطور میتونیم از این لایبرری استفاده کنیم، همچنین درباره server states و client states میخونیم و به این سوال که آیا React Query میتونه ابزار مفیدی برای global state manegement هم باشه پاسخ میدم.نحوه ی نصب:npm install react-query بعد از نصب پکیج باید به شکل زیر عمل کنید:دقیقا مثل تصویر بالا، در فایل index اقدام به ایمپورت کردن QueryClientProvider و QueryClient میکنیم که یه queryClient میسازیم و به عنوان پراپ client پاس میدیمش به QueryClientProvider که پیچیدیمش دور کامپوننت App و حالا میتونیم راحت تو کامپوننت هامون از react query استفاده کنیم.useQueryاین هوک از مهم ترین هوک هایی هست که React Query در اختیارتون میزاره و خیلی باهاش کار میکنید. از این هوک برای فچ کردن دیتا از سرور و کش کردن اون دیتا برای سری های بعدی استفاده میشه:useQueryهمونطور که توی مثال بالا میبینید این هوک یه آبجکت به ما برمیگردونه که ما با دی استراکچر کردن هر کدوم رو ازش میکشیم بیرون تا استفادشون کنیم. پارامتر هایی که باید به این هوک بدیم اولی query key هستش که ازش برای اسم گذاری استفاده میکنیم. ینی چی؟ ینی بهش میگیم بیا به این اندپوینت فلان ریکوئست بزن و دیتاشو با این اسم( توی مثال با اسم todos) کش بکن که اگه بعدا خواستم دیتاشو اپدیت کنم و ازم اسم خواستی من به همین اسم اشاره بکنم که بتونی بشناسیش و آپدیتش کنی.دومین پارامتری که باید بهش پاس بدیم یه فانکشن async هست که توش ریکوئست رو میزنیم و دیتارو برمیگردونیم.حالا چیزایی که این هوگ برمیگردونه مهم تریناش همین ها هستند که دارین در تصویر بالا مشاهده میکنید.پراپرتی data شامل دیتایی هست که از ریکوئستمون با موفقیت بهمون برگشته، پراپرتی isLoading یه مقدار boolean هستش که اگه ریکوئستمون هنوز دیتارو نداده و در حالت pending هستش این پراپرتی true خواهد بود و در غیر این صورت false، پراپرتی isError هم دقیقا به همین صورته که تا وقتی که ریکوئستمون در حالت انتظار یا موفقیت باشه مقدار این پراپرتی false خواهد بود و فقط در صورتی که ریکوئستمون ارور برگردونه این پراپرتی true میشه. همچنین یه پراپرتی Error هم داریم که ازش میتونیم برای نشون دادن مسیج ارور Error.message استفاده بکنیم که توی مثال بالا نیست.نکته ی خفنش اینجاس که این data وقتی با موفقیت پر بشه و ما دیتارو داشته باشیم دفعات بعد این دیتا کش شده و وقتی کاربر دیتارو بخواد ببینه بدون لحظه ای لودینگ و درنگ میتونه دیتارو ببینه درحالی که React Query عزیز اون پشت داره ریکوئست تازه ای میزنه تا ببینه اگه دیتا عوض شده بود با این دیتای کش شده جایگزینش کنه و در غیر اینصورت دیتا تغییری نمیکنه.به همین راحتی دارید دوتا از قابلیتای کلیدی این لایبرری رو در همین مثال اول میبینید: یک اینکه ما خیلی راحت ریکوئستمون رو مدیریت میکنیم و برای هر سناریویی از جمله وقتی ریکوئستمون ارور بده یا موفق باشه یا لودینگ باشه، دستمون پره که این دنباله ی قابلیت کلیدی بعدی این لایبرری هستش که باعث میشه ما دیگه برای ریکوئسمون استیت های اضافی برای لودینگ و ارور و try catch های بیخود و... ننویسیم و کد رو بهینه تر و تمیز تر میکنه.useMutationاز این هوک وقتی استفاده میکنیم که میخوایم دیتارو تغییر بدیم مثلا وقتی که میخوایم یه ایتم به دیتا اضافه یا یه ایتم از دیتا حذف یا دیتای فعلی رو تغییر بدیم:useMutationهمونطور که توی مثال بالا میبینید این هوک هم یه آبجکت به ما برمیگردونه که ما با دی استراکچر کردن هر کدوم رو ازش میکشیم بیرون تا استفادشون کنیم. پارامتر هایی که باید به این هوک بدیم اولی فانکشن async هستش که توش ریکوئستمون رو میزنیم و دیتارو برمیگردونیم اگه این فانکشنمون نیاز به پارامتر داشته باشه(که توی مثال بالا newTodo هستش) اون پارامتر رو موقع صدا کردن mutate بهش پاس میدیم.پارامتر دومی که این هوک میگیری یه ابجکته که میتونیم توش با توجه به پراپرتی هایی که داره کارای مختلفی انجام بدیم، توی مثال بالا از پراپرتی onSuccess استفاده کردیم این متد وقتی که ریکوست موفقیت آمیز باشه صدا زده میشه و توی این متد میتونیم دیتای آپدیت شدمون رو دوباره Refetch یا invalidate کنیم. ینی چی؟ ینی به React Query بگیم دیتای من آپدیت شده پس دیتایی که برام کش کردی و دارم نشون میدم قدیمیه، لطفا برو و دوباره دیتای جدید رو فچ کن تا دیتای کش شده ام آپدیت بشه. اینجاس که اون query key بدرد میخوره. چون react query نمیدونه کدوم دیتارو باید اپدیت کنه و ما با پاس دادن این اسم به متد invalidateQueries میگیم که کدوم دیتارو باید اپدیت بکنه.درباره ی ٖqueryClient که از متد invalidateQueries اش استفاده کردیم جلوتر بیشتر توضیح میدم.حالا پراپرتی هایی که این هوک به ما برمیگردونه یکی فانکشن mutate هستش که ازش میتونیم برای آپدیت کردن دیتا و اجرای کل پروسه ای که الان توضیح دادم استفاده کنیم و پراپرتی بعدی isLoading هستش که تا وقتی که mutation هنوز انجام نشده( اپدیت صورت نگرفته و ریکوئست در حالت pending هست) این پراپرتی true خواهد بود تا ازش برای نشون دادن لودینگ استفاده کنیم.optimistic updatesپارامتر دوم هوک useMutation علاوه بر onSuccess متدای دیگه ای هم داره که یکیشون که خیلی کلیدی و جذابه onSettledوoptimisticUpdateهستش.فرض کنید وقتی میخواید یه آیتم به دیتاتون اضافه کنید(بفرستید سمت سرور) شما مطمعنید که دیتا به سرور با موفقیت فرستاده میشه یا به هر دلیلی دوس ندارید وقتی ایتم رو ادد میکنید منتظر جواب سرور بمونید و لودینگ ببینید. پس میاید به محض زدن دکمه ی اضافه کردن آیتم،‌اون آیتم رو دستی به دیتای کش شدتون اضافه میکنید و کاربر درجا با سرعت نور و بدون هیچ معطلی و لودینگی دیتای جدید رو میبینه:متد uptimisticUpate به محض اینکه ریکوئست زده بشه اجرا میشه و منتظر جواب نهایی ریکوئست نمیمونه، توی مثال بالا هم ما اومدیم به محض ریکوئست، با استفاده از متد setQueryData به React Query گفتیم که بیا و دیتایی که با اسم todos کش کردی رو اپدیت کن و این اسم todos رو به عنوان پارامتر اول دادیم و پارامتر دوم یه کال بک هست که دیتای کش شده ی فعلی رو به عنوان آرگیومنت میگیره و یه دیتای جدید برمیگردونه که آرایه ای شامل از دیتای کش شده ی فعلی به اضافه ی آیتم ادد شده ی جدید هستش. لازم به ذکره که ما ایدی هارو در این پروسه به صورت دستی و فی البداهه و موقت میدیم ولی وقتی ریکوست کامل شه دوباره دیتای کش شده تغییر میکنه و دیتایی که توی این متد اضافه کردیم پاک میشه تا دیتای اپدیت شده با ایدی های واقعی اضافه شن.حالا مشکلی که وجود داره اینه که اگه به هر دلیلی سرور ارور بده و نتونیم دیتای کش شده رو اپدیت کنیم همچنان قراره دیتای الکی که توی uptimisticUpdate اضافه کردیم توی کش باقی بمونه در حالی که ما واقعا همچون دیتایی نداریم و به صورت موقت میخواستیم نشونش بدیم تا دیتای اصلی با ایدی واقعی برسه.اینجاس که متد کلیدی بعدی به دادمون میرسه که بهش اشاره کردم onSettled، این متد بعد از اینکه سرور ریسپانس رو برگردوند بدون در نظر گرفتن ارور یا موفقیت صدا زده میشه و ما میتونیم توش بگیم که اگه سرور ارور برگردونده پس اون دیتای فیکی که توی uptimisticUpdate اضافه کردم رو حذف کن تا همون دیتای اصلی بمونه:متد onSettled چند تا ارگیومنت داره که ما فقط به error و context نیاز داریم از ارور برای این استفاده میکنیم که چک کنیم اگه ترو بود و ارور برگردونده بود دیتای فیک رو پاک کنیم پس دوباره با همون متد setQueries میایم دیتای کش شده رو میگیریم و فیلترش میکنیم که بیاد فقط ایتمایی که ایدیش با ایدی آیتم فیک ما یکی نیست رو نگه داره که همون دیتای کش شده ی اصلی بود و دیتای کش شدمون رو اینطوری برمیگردونیم به حالت قبل.همچنین توی ریکوئستمون داریم چک میکنیم که اگه response.ok فالس بود یه ارور برگردونه که باعث صدا زده شدن onSettled موقع ارور گرفتن بشه و همینطور توی uptimisticUpdate آیدی آیتم فیکمون رو برمیگردونیم که مقدارشو با عنوان context به عنوان آرگیومنت onSettled میگیریم و جهت فیلتر کردن دیتا استفادش میکنیم.به کل این پروسه optimistic update گفته میشه که از قابلیت های کلیدی این لایبرری هستش.useQueryClientاین بزرگوار رو که تو مثال های بالا استفاده کردیم برای دسترسی به query client استفاده میشه که مسئول مدیریت کش و تغییر دیتای کش شده و invalidate کردنشون هست.مهم ترین متد هایی که این هوک بهمون میده :متدsetQueryData: این متد دیتای کش شده ی query keyای که بهش میدیم رو آپدیت میکنه.متدgetQueryData: این متد دیتای کش شده ی query keyای که بهش میدیم رو بهمون میده.متدinvalidateQueries: این متد دیتای کش شده ی query keyای که بهش میدیم رو با Refetch یا همون ریکوئست مجدد از سرور آپدیت میکنه.Caching optionsما وقتی از useQuery تو مثال اولمون برای گرفتن دیتا استفاده کردیم فقط درباره دو پارامتر اولش حرف زدیم که شامل query key و ریکوئستمون بود حالا یه پارامتر سوم هم داریم که باهاش میتونیم قابلیت های کش کردن و ریکوئست زدنش رو کانفیگ و مدیریت کنیم مهم ترین پراپرتی ها برای کانفیگ کردن این موارد هستند:پراپرتی staleTime: با این پراپرتی میگیم که دیتایی که کش کرده چقدر تو حالت stale بمونه قبل از اینکه Refetch بشه و این پراپرتی مقدار عدد رو به عنوان میلی ثانیه زمان میپذیره.پراپرتی cacheTime: با این پراپرتی میگیم که دیتا چه مدت میتونه تو حالت کش بمونه و بعدش اتوماتیک از حافظه کش پاک میشه که بهمون کمک میکنه بتونیم سایز کشمون رو مدیریت کنیم و نزاریم زیادی بزرگ شه و این پراپرتی مقدار عدد رو به عنوان میلی ثانیه زمان میپذیره.پراپرتی refetchOnMount: با این پراپرتی میگیم که کوئری باید موقع mount شدن کامپوننت دیتای خودش رو refetch بکنه یا نه و این پراپرتی مقدار boolean میپذیره.پراپرتی refetchOnWindowFocus: با این پراپرتی میگیم که کوئری باید موقعی که صفحه فوکوس میشه دیتای خودش رو refetch بکنه یا نه که بهمون کمک میکنه وقتی کاربر چند تا صفحه از اپلیکیشنمون رو همزمان باز کرده با جابه جا شدن بین صفحات صفحات دیگه دیتاشون قدیمی نمونه و اتوماتیک اپدیت بشه تا کاربر نیازی به رفرش صفحه نداشته باشه و این پراپرتی مقدار boolean میپذیره.پراپرتی refetchInterval: با این پراپرتی میگیم که کوئری باید هر چند ثانیه یبار ریکوئست بزنه و دیتارو اتوماتیک آپدیت بکنه و این پراپرتی مقدار عدد رو به عنوان میلی ثانیه زمان میپذیره.پراپرتی retry: با این پراپرتی میگیم که کوئری باید موقعی که از سرور ارور میگیره چند بار دیگه مجدد ریکوئست بزنه و تلاش کنه که بهمون کمک میکنه ارور های سرور رو خیلی بهتر مدیریت کنیم و تا حد ممکن اپلیکیشنمون رو ریسپانسیو نگه داریم و این پراپرتی مقدار عدد به عنوان تعداد دفعات تلاش مجدد میپذیره.پراپرتی retryDelay: با این پراپرتی میگیم که اگه داریم از پراپرتی retry استفاده میکنیم، کوئری هر چند ثانیه یبار باید تلاش مجدد رو انجام بده که بهمون کمک میکنه تا پدر سرور رو با تلاش های پشت هم در نیاریم و یه فاصله ای برای نفس کشیدن به سرور بدیم.پراپرتی staleWhileRevalidate:‌ با این پراپرتی میگیم که زمانی که داری دیتای کش شده رو به کاربر نشون میدی تو پشت صحنه دیتای جدید رو از سرور بگیر و دیتای کش شده رو باهاش اپدیت کن و این پراپرتی مقدار boolean میپذیره.با استفاده از این کانفیگ پراپرتی ها ما میتونیم استراتژی های مختلفی برای سیستم کش کردن اپلیکیشنمون داشته باشیم که من دو تا از استراتژی هارو اینجا توضیح میدم که شما میتونید یا از اینا استفاده کنید یا استراتژی خودتون رو بسته به نیاز پروژتون بسازید:استراتژی stale-while-revalidate:با این استراتژی ما به کاربر دیتای کش شده (stale) رو نمایش میدیم در حالی که تو پشت صحنه دیتای جدید رو میگیریم و باهاش دیتای کش شده رو آپدیت میکنیم. این استراتژی بهمون کمک میکنه که تعداد دفعاتی که کاربر منتظر دیتا میمونه و به لودینگ زل میزنه رو کاهش بدیم و وقتی دیتایی رو بخواد به صورت آنی میتونه دیتای آماده رو ببینه:stale-while-revalidateاستراتژی network-first :با این استراتژی ما به فچ کردن دیتای تازه از نتورک اولویت بالاتری نسبت به دیتای کش شده میدیم و توی شرایطی استفاده ازش مناسبه که بخوایم مطمعن شیم که دیتایی که یوزر میبینه همیشه تازه ی تازه اس حتی اگه به قیمت فدا کردن یکم پرفورمنس بشه:network-firstتوی این مثال با ست کردن cacheTime و staleTime رو یک دقیقه داریم میگیم که هر یک دقیقه دیتای کش رو بپاک و دیتای جدید رو Refetch کن و با ست کردن refetchOnMount به false داریم میگیم که حتی موقع mount شدن هم سر خود فچ نکن دیتارو و هر یه دیقه اینکارو انجام بده و دیتارو تازه کن و با ست کردن retry به ۳ بهش میفهمونیم که اگه به ارور خورد تا سه بار تلاش مجدد انجام بده.نکته: اگه یک دیقه تموم بشه و دیتای جدید رو با سه بار تلاش نتونه از سرور بگیره میره کش رو نگاه میکنه و در صورتی که دیتایی موجود بود نمایش میده و در غیر اینصورت ارور نمایش میده.آیا از React Query میشه برای Global State Management استفاده کرد و بیخیال ریداکس و.. شد؟اگه میخوایم جواب این سوال رو بدونیم بهتره اول یه مفهومی رو بلد باشیم:Client State و Server Stateاستیت هایی که سمت کلاینت (مثلا مرورگر کاربر) مدیریت میشند و تغییرشون وابسته به عمل کاربر در خود اپلیکیشن هست و تغییرشون نیازی به ارسال ریکوئست نداره، Client State هستند. مثل: وضعیت لاگین کاربر، تمی که برای سایت انتخاب کرده، زبانی که برای سایت انتخاب کرده، دیتای داخل اینپوت های فرم که هنوز سابمیت نشدن.استیت هایی که سمت سرور ( بک اند) مدیریت میشند و تغییر توی دیتای این استیت ها نیاز به ارسال نتورک ریکوئست داره، Server state هستند. مثل: لیست محصولاتی که برای خرید در یک فروشگاه در دسترس هستند، لیست مقاله هایی که در سایت ویرگول منتشر میشه، لیست آگهی های توی دیوار و...حالا برگردیم به جواب سوال اصلیمون:لایبرری react query به طور خاص و با هدف اصلی مدیریت ریکوئست ها و کش کردن دیتا به وجود اومده. اگر چه ما امکان استفاده ازش به عنوان global state management رو داریم ولی این لایبرری برای مدیریت ریکوئست ها و کش کردن دیتا ساخته شده و اگر چه با توجه به توضیحاتی که درباره استیت ها دادم بتونیم ازش برای مدیریت server states استفاده بکنیم اما نمیشه ازش استفاده مفیدی در client states کرد.البته میتونیم از این لایبرری برای مدیریت server states استفاده کنیم و برای client states از ریداکس یا context و.. استفاده کنیم اما باعث پیچیدگی بیشتر میشه.نظر شخصی خودم اینه که بهترین گزینه redux toolkit هستش که اگه مقاله ای که دربارش گذاشتم رو مطالعه کرده باشید(بخش redux query)، متوجه میشید که اکثر قابلیت هایی که react query برای مدیریت ریکوئست ها و کش کردن دیتا داره رو ریداکس تولکیت هم داره به علاوه اینکه همه ی استیت ها هم هندل میکنه.ولی با اینحال با توجه به پروژه ای که دارید خودتون میتونید تصمیم بگیرید که دوس دارید از کدوم پکیج استفاده کنید و من فقط میخواستم با این لایبرری خفن که حرف زیادی برای گفتن داره آشناتون کنم. امیدوارم مفید واقع بوده باشه.خدانگهدار و موفق باشی ?