Faragiri

همهٔ زبان‌ها

آموزش ری‌اکت (React) فریم‌ورک‌های فرانت‌اند

دو بار صدا زدن تابع تنظیم وضعیت در یک رویداد، شمارنده را فقط یکی جلو می‌برد. شکل تابعی همان دو فراخوانی، دو تا جلو می‌برد.

۴بخش
۳دقیقه خواندن
۴عمق

دو پرسش، چهار خانه

هر مقدار کجا باید بنشیند

دو محور این شبکه دو پرسش جدا هستند و جواب ترکیبشان تعیین می‌کند مقدار در کدام سازوکار می‌نشیند.

با تغییرش صفحه عوض می‌شودبا تغییرش صفحه عوض نمی‌شود

بین رندرها می‌ماند

وضعیتتغییرش رندر می‌گیرد و مقدارش بین رندرها می‌ماند
  • تعداد فروخته‌شده
مرجعبین رندرها می‌ماند و تغییرش هیچ رندری نمی‌گیرد
  • شناسه یک تایمر

بین رندرها نمی‌ماند

متغیر محلی رندراز روی بقیه حساب می‌شود و ذخیره کردنش اشتباه است
  • مبلغ کل، از تعداد و قیمت
وضعیت سرورشبیه وضعیت به نظر می‌رسد و در واقع یک کش است
  • فهرست سفارش‌ها از یک رابط برنامه‌نویسی

خانه آخر در خود کتابخانه سازوکاری ندارد و همان است که چهار وضعیت دستی می‌سازد. جایش یک لایه کش جداست.

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

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

هر دو حالت فقط یک رندر دوباره می‌سازند. ری‌اکت تغییرهای یک رویداد را دسته می‌کند و در پایان یک بار رندر می‌گیرد؛ این ربطی به تعداد فراخوانی ندارد.

هر مقدار یک خانه دارد

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

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

اثر جانبی برای چیزی است که بیرون از ری‌اکت است

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

و هر اثری که چیزی می‌سازد باید تابع پاک‌سازی برگرداند، وگرنه شنونده‌ها روی هم انباشته می‌شوند. در حالت سخت‌گیرانه توسعه، ری‌اکت هر اثر را دو بار اجرا می‌کند تا همین را نشان دهد؛ این یک باگ نیست و اگر کد شما با آن می‌شکند، پاک‌سازی ندارد.

جایی که کار گیر می‌کند، وضعیت سرور در وضعیت کامپوننت است

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

ابزار، و سالی که این حرف درست است

در سال ۲۰۲۶، ری‌اکت ۱۹ نسخه‌ای است که یک پروژه تازه رویش ساخته می‌شود و متن‌باز و رایگان است. برای شروع پروژه، ابزار ساخت پیشنهادی Vite است و جای ابزار قدیمی‌تر شروع پروژه را گرفته که سال‌هاست نگهداری نمی‌شود. ابزار توسعه ری‌اکت به‌شکل افزونه مرورگر، درخت کامپوننت‌ها و دلیل هر رندر دوباره را نشان می‌دهد و رایگان است؛ همان است که جای گذاشتن console.log در بدنه کامپوننت را می‌گیرد.

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

کنار این

بالای این