رفتن به محتوا
triplem.dev
بلاگvue

Vue 3.6.0-rc.10: جریان اصلاحات Vapor چه چیزی را نشان می‌دهد

۵ دقیقه مطالعه
vue
vapor

نسخه 3.6.0-rc.10 در ۳۰ سپتامبر، دو هفته پس از rc.9، منتشر شد. این یک پیش‌انتشار است و آخرین نسخه پایدار در صفحه releases در زمان نگارش، 3.5.43 است. تقریباً همه تغییرات rc.10 در پکیج‌های Vapor هستند. این نشان می‌دهد ریسک باقی‌مانده در 3.6 کجاست، هرچند خود انتشار پرزرق‌وبرق نیست.

در rc.10 چه چیزی تغییر کرد

بر اساس changelog نسخه 3.6، موارد rc.10 در سه گروه قرار می‌گیرند.

کامپایلر (compiler-vapor)

  • کلیدهای on* روی المان‌های بومی اکنون مانند کامپایلر vdom به‌صورت listener بایند می‌شوند (#15695).
  • المان‌های SVG در تولید کد prop بر اساس namespace شناسایی می‌شوند (#15656).
  • رمزگشایی attribute و prop folding اصلاحات بیشتری گرفتند.

زمان اجرا (runtime-vapor)

  • propهای ارزیابی‌شده و slotهای پویا اکنون به کامپوننت‌ها تحویل داده می‌شوند (#15708).
  • listenerهای خود ریشه با listenerهای fallthrough ادغام می‌شوند (#15688).
  • hydration و interop با vdom بهبودهای بیشتری گرفتند، از جمله رندر slot، patch کامپوننت و متغیرهای CSS.

رندر سمت سرور

  • فوروارد slot خالی Vapor و رندر slot outlet اصلاح شدند.

تنها مورد مربوط به کارایی این است که class و style قالب ریشه اکنون در اولین استفاده resolve می‌شوند.

rc.9 (۱۸ سپتامبر) همین الگو را داشت: caching عبارت‌ها، مدیریت selector در v-for، hydration، هم‌ترازی v-show، KeepAlive و #15506 که propها را shallow علامت می‌زند تا watch کردن props دیگر عمیق نباشد. changelog برای این چرخه انتشار هیچ breaking change‌ای فهرست نکرده است.

چرا اهمیت دارد

به چیزهایی که اصلاح شده‌اند نگاه کنید: fallthrough attributeها، ادغام listenerها، تحویل slot، hydration و SVG. این‌ها جاهایی هستند که کامپایلری که مستقیماً عملیات DOM تولید می‌کند باید رفتار رندرر vdom را تقلید کند. مسیر اصلی reactivity در این فهرست نیست. دو نتیجه می‌گیریم.

  1. باگ‌های هم‌ترازی رفتاری در مرز کامپوننت‌ها هستند. اگر کامپوننت‌های شما به fallthrough attribute همراه با listener روی ریشه، slotهای پویا یا hydration در SSR تکیه دارند، همین مسیرها هنوز در حال اصلاح‌اند. آن‌ها را تست کنید.
  2. معنای listenerها در rc.10 هنوز در حال تغییر بود. بایند کردن کلیدهای on* مثل vdom یک تغییر معنایی است، نه پاکسازی. اگر برای رفتار قبلی Vapor راه‌حل موقت نوشته‌اید، دوباره بررسی‌شان کنید.

چگونه فعالش کنیم

Vapor اختیاری است. یک راهنمای ارتقای RC از منبع ثالث سه سطح را توصیف می‌کند. من نتوانستم صفحه رسمی Vapor را بارگذاری کنم، پس پیش از استفاده این‌ها را با مستندات Vue تطبیق دهید.

یک اپ Vapor خالص از runtime مربوط به vdom بی‌نیاز است:

ts
import { createVaporApp } from "vue";
import App from "./App.vue";

createVaporApp(App).mount("#app");

یک اپ ترکیبی پلاگین interop را نصب می‌کند و برای هر کامپوننت جداگانه فعال می‌شود:

ts
import { createApp, vaporInteropPlugin } from "vue";
import App from "./App.vue";

createApp(App).use(vaporInteropPlugin).mount("#app");
vue
<script setup vapor lang="ts">
// this component compiles in Vapor mode
</script>

این راهنما از <script vapor> و <template vapor> هم به‌عنوان شکل‌های جایگزین نام می‌برد.

برای اپ موجود، مسیر ترکیبی واقع‌بینانه است. ابتدا کامپوننت‌های برگ را تبدیل می‌کنید و بقیه را روی vdom می‌گذارید، بنابراین بیشترین مواجهه شما با لایه interop است. این لایه همان جایی است که اصلاحات rc.10 بیشتر به آن می‌پردازند.

Vapor هنوز چه چیزهایی را پشتیبانی نمی‌کند

همین راهنما این محدودیت‌ها را فهرست می‌کند که در برنامه‌ریزی مهاجرت از هر اصلاحی مهم‌ترند:

  • Options API پشتیبانی نمی‌شود.
  • getCurrentInstance() مقدار null برمی‌گرداند.
  • app.config.globalProperties در دسترس نیست.
  • render functionها و JSX فقط با vdom کار می‌کنند.
  • v-memo پشتیبانی نمی‌شود.
  • template refها به کامپوننت‌های Vapor مقادیر $el، $props، $attrs یا $slots را در دسترس نمی‌گذارند.

مورد آخر محتمل‌ترین چیزی است که شما را گیر می‌اندازد. کد والدی که از طریق template ref به فرزند دسترسی دارد و $el را می‌خواند، وقتی فرزند تبدیل شود می‌شکند. کتابخانه‌هایی که از getCurrentInstance() یا globalProperties استفاده می‌کنند هم همین‌طور می‌شکنند؛ پس درخت وابستگی‌ها را هم بررسی کنید، نه فقط کد خودتان.

این راهنما همچنین می‌گوید 3.6 لایه انتشار وابستگی را بر پایه alien-signals بازسازی کرده، با API عمومی‌ای که آن را بدون تغییر توصیف می‌کند و کاهش حافظه‌ای حدود ۱۳٪. این عدد از خود راهنما آمده و هیچ workload یا روش اندازه‌گیری‌ای ندارد، پس برنامه‌تان را بر آن بنا نکنید. اپ خودتان را اندازه بگیرید.

هشداری که بین RCها آسیب می‌زند

همین راهنما می‌گوید rc.1 رویدادها را خودکار به document تفویض می‌کرد، در حالی که rc.2 به‌طور پیش‌فرض listenerها را مستقیم بایند می‌کند. توصیه می‌کند modifier ‏.delegate را فقط وقتی تفویض در سطح document می‌خواهید به کار ببرید و هر پیکربندی compilerOptions.eventDelegation باقی‌مانده از rc.1 را حذف کنید. اگر زود Vapor را امتحان کرده‌اید و تنظیماتتان را دوباره بررسی نکرده‌اید، این گزینه را چک کنید.

با این اطلاعات چه کنیم

  • اپ‌های production: روی 3.5.x بمانید. این نسخه هنوز candidate است و changelog اصلاحاتی را در بخش‌های پایه‌ای مثل تحویل prop و ادغام listener نشان می‌دهد.
  • پروژه‌های جدید یا ابزارهای داخلی: یک اپ Vapor خالص معقول است، به شرط آنکه فهرست پشتیبانی‌نشده بالا را بپذیرید و بتوانید RC دقیق را pin کنید.
  • نویسندگان کتابخانه: الان زمان اجرای کامپوننت‌هایتان زیر هر دو رندرر است. هر چیزی که بر proxy نمونه، getCurrentInstance() یا globalProperties بنا شده باشد، اول از همه می‌شکند.
  • کاربران Nuxt: یکپارچگی با Nuxt را بررسی نکردم، پس آن را در اینجا آزمون‌نشده در نظر بگیرید.

بده‌بستان‌ها

استدلال به نفع Vapor، کار کمتر زمان اجرا در هر به‌روزرسانی و runtime کوچک‌تر است، اما این نوشته به هیچ benchmarkی برای آن تکیه نمی‌کند. هزینه‌اش مدتی اکوسیستم دوپاره است: دو مدل کامپوننت، یک لایه interop و فهرستی از APIهای دوران vdom که اعمال نمی‌شوند. جریان پیوسته اصلاحات هم‌ترازی در این مرحله قابل انتظار است. این هم یعنی برچسب RC دقیق است.

منابع