نسخه 3.6.0-rc.11 در ۱۰ اکتبر، ده روز پس از rc.10، منتشر شد. این یک پیشانتشار است و صفحه releases همچنان 3.5.43 را آخرین نسخه پایدار نشان میدهد. changelog نسخه 3.6 یک قابلیت، دو مورد بهبود کارایی و فهرست بلندی از اصلاحات Vapor دارد. نکته جالب حجم تغییرات نیست. چند مورد باعث میشوند Vapor بگوید کجا بیصدا کاری متفاوت از رندرر vdom انجام میدهد.
تنها قابلیت: Transition در مرز دو رندرر
تنها مورد بخش Features شماره #15758 است: محتوای slot در Vapor اکنون میتواند داخل یک Transition در vdom انیمیت شود. این کار interop است. در یک اپلیکیشن ترکیبی، قرار دادن محتوای slot یک کامپوننت Vapor داخل <Transition> در یک کامپوننت vdom کار طبیعی است که هنگام تبدیل تدریجی از برگها پیش میآید و تا امروز باید از آن پرهیز میکردید.
اصلاحات اطراف آن هم در همین جهتاند: v-show در interop اکنون از چرخه عمر mount المان پیروی میکند (#15806)، slot در Vapor که مستقیماً توسط render function فراخوانی شود بهعنوان outlet رندر میشود (#15743) و محتوای slot چندریشهای vdom زیر ریشه transition در Vapor فوروارد میماند (#15754).
هشدار برای رفتارهای نادیدهگرفتهشده
سه مورد هشدار زمان توسعه اضافه میکنند:
v-memoدر قالبهای Vapor نادیده گرفته میشود و کامپایلر اکنون هشدار میدهد (#15788).- دسترسی به global properties از قالب Vapor در زمان اجرا هشدار میدهد (#15789).
- هوکهای
@vue:*روی المانها نادیده گرفته میشوند و اکنون هشدار داده میشود (#15807).
پست rc.10 بر اساس یک راهنمای شخص ثالث، v-memo و globalProperties را جزو قابلیتهای پشتیبانینشده آورد. changelog اکنون دستکم برای v-memo تأیید میکند که کامپایلر آن را نادیده میگیرد، نه اینکه شکست بخورد. قالبی که قبلاً کامپایل میشد و اجرا میشد همچنان کار میکند، فقط بدون memoize که به آن تکیه داشتید. هشدار بهتر از سکوت است، اما فقط سیگنال زمان توسعه است؛ پیش از تبدیل یک کامپوننت، تستهایتان را طوری اجرا کنید که هشدارها خطا حساب شوند.
<script setup vapor lang="ts">
import { ref } from "vue";
const rows = ref<{ id: number; label: string }[]>([]);
</script>
<template>
<!-- rc.11 warns that v-memo is ignored here -->
<li v-for="row in rows" :key="row.id" v-memo="[row.label]">{{ row.label }}</li>
</template>
اگر فهرستی برای جلوگیری از رندر مجدد ردیفهای سنگین به v-memo وابسته بود، پس از تبدیل اندازهگیری کنید و فرض نکنید بهروزرسانیهای ریزدانه Vapor جبران میکنند. من این را benchmark نکردهام و changelog هم درباره کارایی چیزی نمیگوید.
بررسیهای سختگیرانهتر در زمان کامپایل
چند مورد دیگر کامپایلر خطاها را زودتر گزارش میکنند:
- اسکریپتهای Vapor بدون
<script setup>رد میشوند (#15790). صفتvaporروی یک<script>ساده اکنون خطای کامپایل است. v-modelروی بایندینگهایconst(#15779) و روی متغیرهای scope درv-forیاv-slot(#15810) گزارش میشود.- ترتیب جستوجوی کامپوننت setup با vdom همتراز شد (#15786) و بایندینگهای setup میتوانند globalهای شناختهشده را shadow کنند (در changelog شماره PR ذکر نشده است).
موارد v-model مهمتریناند. انتساب به const یا متغیر حلقه در هر دو رندرر باگ است، اما کامپایلری که مستقیماً کد DOM تولید میکند باید تصمیم بگیرد چه چیزی تولید کند. گزارش دادن انتخاب امنتر است.
اصلاحات parity که ارزش مرور دارند
بیشتر نسخه همان الگوی RCهای قبلی را دارد، پس فقط مواردی را میآورم که به کد رایج اپلیکیشنها مربوط میشوند:
- فرمها: مقدار
selectپس از بهروزرسانی option همگام میشود (#15827)، تغییر مقدار checkbox در effectهای model ردیابی میشود (#15815)، مقدار input بعد از سایر propهایش تنظیم میشود (#15722) و مقدار symbol مانند vdom به رشته تبدیل میشود (#15830). - Hydration: slotهای فورواردشده زیر ریشههای transition (#15812)، anchorهای شاخه خالی
once(#15821) و هوکهایmountedاپلیکیشن اکنون بعد از پایان hydration اجرا میشوند (#15753). - کامپوننتهای async: ورودیهای تغییرکرده به کامپوننتهای async بهتعویقافتاده فوروارد میشوند (#15809).
- Namespace: ریشه کامپوننتهای پویای SVG و MathML در namespace خودشان ساخته میشوند (#15797).
- HMR: state زنجیره ریشه پس از rerender در HMR دوباره اعمال میشود (#15750).
- ابزار: import آدرس asset در propهای کامپوننت و اشیای
v-bindپشتیبانی میشود (#15799).
اگر در RCهای قبلی برای رفتار Vapor راهحل موقتی داشتید، در گروه فرمها و hydration بررسی کنید هنوز لازم است یا نه. این فهرست بخش breaking change ندارد.
بهبودهای کارایی
دو مورد هستند و هر دو کوچکاند. compiler-sfc اکنون matcherهای glob مربوط به tsconfig را کش میکند و فیلدهای private را در بیلد CJS بومی نگه میدارد (#15784). runtime-vapor کش منبع slot استفادهنشده را tree-shake میکند (#15838). مورد دوم runtime را برای اپهایی که از آن قابلیت استفاده نمیکنند اندکی کوچک میکند، اما changelog عددی نمیدهد و من هم عددی نقل نمیکنم.
چه باید کرد
- اپلیکیشنهای production: روی 3.5.x بمانید. خط پایدار تغییری نکرده و نسخهای که هنوز همگامسازی
selectو ترتیبv-modelرا اصلاح میکند برای انتشار مناسب نیست. - تیمهایی که Vapor را در اپ ترکیبی امتحان میکنند: روی یک branch به rc.11 ارتقا دهید و کنسول را ببینید. سه هشدار تازه یک ممیزی رایگان از قالبهاییاند که به قابلیتهای نادیدهگرفتهشده وابستهاند.
- نویسندگان کتابخانه: کامپوننتهایتان را با هر دو رندرر اجرا کنید. اصلاحات interop این نسخه نشان میدهد slotها و
v-showدر مرز دو رندرر هنوز جای باگاند. - کاربران Nuxt: یکپارچگی Nuxt با Vapor را بررسی نکردم، پس آن را آزموننشده در نظر بگیرید.
مصالحهها
مدل Vapor APIهای دوران vdom را با کار کمتر در زمان اجرا معاوضه میکند. نسخهای که برای v-memo، global properties و هوکهای @vue:* هشدار اضافه میکند، صادقانه همین مصالحه را نشان میدهد. rc.11 فهرست را کوتاه نمیکند. هر هشدار قابلیتی است که در vdom داشتید و در Vapor ندارید، پس تبدیل هر کامپوننت تصمیمی است که باید با این فهرست در دست بگیرید.