Inertia live props؛ به‌روزرسانی وضعیت سفارش با Laravel Reverb

چرا مهم است

اگر با Inertia صفحهٔ وضعیت سفارش داری، این آموزش مسیر دریافت تغییرات بدون polling را نشان می‌دهد. همچنین روشن می‌کند چه زمانی هر صفحه request تازه می‌فرستد و چه زمانی مقدار مستقیماً از event می‌رسد.

قبل از خواندن، این‌ها را بدان۴ مفهوم
Closure

تابعی که می‌تواند به‌صورت یک مقدار منتقل شود و به متغیرهای محیط تعریف خود دسترسی داشته باشد.

بیشتر: Closure

Private Channel

یک channel برای دریافت پیام که پیوستن به آن نیازمند بررسی اجازهٔ دسترسی کاربر است.

در حال نگارش: Private Channel

queue

سازوکاری برای نگهداری کارها تا یک worker آن‌ها را جدا از جریان اصلی request اجرا کند.

در حال نگارش: queue

event payload

داده‌ای که همراه یک event ارسال می‌شود تا دریافت‌کننده بتواند از محتوای آن استفاده کند.

در حال نگارش: event payload

قابلیت live props که در Inertia نسخهٔ v3.11.0 اضافه شده، داده‌های صفحه را هنگام تغییر در server به‌روز نگه می‌دارد: یک prop به‌عنوان live مشخص می‌شود و با broadcast شدن event،؜ صفحه‌هایی که آن را نمایش می‌دهند مقدارش را دوباره دریافت می‌کنند. آموزش Laravel News این جریان را برای صفحهٔ وضعیت سفارش با Laravel Reverb پیاده می‌کند. پیش‌نیاز آن inertia-laravel نسخهٔ 3.7 و Inertia.js نسخهٔ 3.11 یا جدیدتر است.

راه‌اندازی با دستور php artisan install:broadcasting --reverb شروع می‌شود. این دستور Reverb و تنظیمات لازم را اضافه می‌کند و برای Vue و React،؜ package مرتبط با Echo را هم نصب می‌کند. در Svelte نصب package و افزودن configureEcho() باید دستی انجام شود.

در مثال، event با نام OrderUpdated از ShouldBroadcast استفاده می‌کند و روی Private Channel مخصوص همان سفارش منتشر می‌شود. قانون دسترسی در routes/channels.php فقط به صاحب سفارش اجازهٔ شنیدن event را می‌دهد. سپس controller مقدار order را داخل Inertia::live() قرار می‌دهد و نمونه‌ای از event را به آن می‌سپارد. ساختن این نمونه به‌معنای broadcast نیست؛ Inertia از آن برای تشخیص channel و نام event استفاده می‌کند. مقدار prop نیز باید با Closure تعریف شود تا هنگام نمایش اولیه و دریافت دوباره اجرا شود.

در سمت frontend،؜ اتصال echo() به createInertiaApp() کافی است و نیازی به تغییر component صفحه نیست. پس از تغییر سفارش و dispatch شدن event،؜ هر صفحهٔ مرتبط فقط prop سفارش را دوباره دریافت می‌کند. با toOthers() می‌توان tab کاربری را که تغییر را انجام داده کنار گذاشت. اجرای Reverb و یک worker برای queue هم لازم است، چون event‌های ShouldBroadcast وارد queue می‌شوند؛ ShouldBroadcastNow ارسال را در همان request انجام می‌دهد.

در حالت معمول، هر event از هر صفحهٔ شنونده یک request تازه به server ایجاد می‌کند. برای تعداد زیاد بیننده، broadcastProps() می‌تواند مقدار جدید را داخل event payload بفرستد و این request‌ها را حذف کند. این روش برای مقدارهایی که به هویت بیننده وابسته‌اند مناسب نیست، چون همهٔ اعضای channel همان payload را می‌گیرند.

Inertia به‌طور پیش‌فرض هر live prop را حداکثر یک‌بار در ثانیه دوباره دریافت می‌کند و امکان افزایش این فاصله وجود دارد. دریافت دوباره هنگام مخفی بودن tab متوقف می‌شود و با بازگشت کاربر انجام می‌گیرد؛ اما مقدارهای broadcastProps() در هر دو حالت روی صفحه نوشته می‌شوند.

نکته کلیدی

بین دریافت دوبارهٔ prop و ارسال مقدار با broadcastProps() تفاوت بگذار. اگر مقدار به هویت بیننده وابسته است، آن را در payload مشترک نفرست؛ برای event‌های ShouldBroadcast هم اجرای worker را فراموش نکن.

خواندن مقاله اصلی (در زبانه‌ی جدید باز می‌شود)
برچسب‌ها (۳)