تصورات غلط در مورد انتقال دید

Bramus

View Transition API یک تغییر دهنده بازی توسعه وب است. چه وب‌سایت شما تک صفحه‌ای باشد یا چند صفحه‌ای، این API قدرتمند به شما این امکان را می‌دهد که انتقال یکپارچه بین نماها ایجاد کنید، و در نتیجه تجربیاتی شبیه بومی ایجاد کنید که کاربران را مجذوب خود می‌کند. در حال حاضر در Chrome در دسترس است، با همان انتقال‌های نمای سند به زودی در Safari در دسترس خواهد بود.

با توجه به اینکه افراد بیشتری شروع به بررسی View Transition API کرده‌اند، زمان آن رسیده است که برخی تصورات غلط را از بین ببریم.

تصور اشتباه 1: View Transition API از صفحه نمایش عکس می گیرد

هنگام اجرای یک انتقال view، API از وضعیت قدیمی و جدید محتوا عکس‌های فوری می‌گیرد. سپس این عکس‌های فوری متحرک می‌شوند، همانطور که در بخش «این انتقال‌ها چگونه کار می‌کنند» مستندات توضیح داده شده است.

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

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root) 👈 Screenshot
      └─ ::view-transition-new(root) 👈 Live representation

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

یک ویدیوی در حال پخش که در یک دموی حداقلی انتقال مشاهده شرکت می‌کند. منبع .

منطق و CSS مورد استفاده برای این کار به تفصیل در مستندات ما آمده است.

تصور نادرست 2: گرفتن بیش از یک عنصر منجر به اجرای چندین انتقال نمایش می شود

هنگامی که چندین عنصر را می گیرید، فرآیند عکس فوری تمام حالت های قدیمی و جدید را ثبت می کند. هنگامی که علاوه بر عنصر :root یک .box را می گیرید، این درخت شبه را دریافت می کنید:

::view-transition
└─ ::view-transition-group(root)
|  └─ ::view-transition-image-pair(root)
|     ├─ ::view-transition-old(root)
|     └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
   └─ ::view-transition-image-pair(box)
      ├─ ::view-transition-old(box)
      └─ ::view-transition-new(box)

در حالی که این درخت شامل چندین جفت عکس فوری است، تنها یک انتقال نمای واحد اجرا می شود.

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

توجه: در آینده، با انتقال‌های با دامنه عنصر، می‌توانید یک انتقال را بر روی زیر درخت DOM اجرا کنید و همچنین امکان انتقال همزمان در یک سند وجود خواهد داشت - تا زمانی که عکس‌های فوری را به اشتراک نگذارند. عناصر.

تصور اشتباه 3: به دلیل پشتیبانی مرورگر نمی‌توانید انتقال view را اجرا کنید

بسیاری از توسعه دهندگان نگران هستند که نتوانند انتقال view را اجرا کنند زیرا فقط در Chrome پشتیبانی می شود. برخی از خبرهای خوب در اینجا این است که سافاری در حال کار بر روی این است و آن را در نسخه بعدی Safari 18 گنجانده است.

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

function handleClick(e) {
    // Fallback for browsers that don't support this API:
    if (!document.startViewTransition) {
        updateTheDOMSomehow();
        return;
    }

    // With a View Transition:
    document.startViewTransition(() => updateTheDOMSomehow());
}

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

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

این رویکرد همانطور که در این مطالعه موردی به تفصیل شرح داده شد ، با موفقیت در تجارت الکترونیک پیاده سازی شد

توجه: فراموش نکنید که به ترجیحات حرکتی کاهش یافته کاربر نیز احترام بگذارید. این را می توان در جاوا اسکریپت یا در CSS با قرار دادن همه آن نام ها یا انیمیشن ها در @media (prefers-reduced-motion: no-reduce) شرطی انجام داد. اگر هیچ عنصری ضبط نشده باشد یا انیمیشنی برای اجرا وجود نداشته باشد، تغییر view DOM قدیمی را با DOM جدید عوض می‌کند بدون اینکه هیچ انیمیشنی اتفاق بیفتد. درباره حرکت و دسترسی بیشتر بیاموزید .

تصور غلط 4: مشاهده انتقال ها رندر افزایشی را می شکند

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

مرورگرها زمانی شروع به رندر کردن یک صفحه می کنند که محتوای «به اندازه کافی» داشته باشند. این - در اکثر مرورگرها - پس از بارگیری همه شیوه نامه ها در <head> ، تجزیه همه جاوا اسکریپت مسدود کننده رندر در <head> و بارگیری نشانه گذاری کافی است. انتقال نمای متقابل اسناد این را تغییر نمی دهد: محتوای مورد نیاز برای First Contentful Paint بدون تغییر است. پس از اولین رندر، مرورگر می‌تواند – و خواهد – به صورت تدریجی محتوای تازه دریافت‌شده را ارائه کند.

می‌توانید تا زمانی که عنصر خاصی در DOM وجود داشته باشد، رندر را مسدود کنید. این در شرایطی راحت است که می‌خواهید مطمئن شوید که عناصر شرکت‌کننده در انتقال view در صفحه جدید وجود دارند.

برای این کار از این تگ لینک استفاده کنید:

<link rel="expect" blocking="render" href="#elementId">

این روش اکتشافی مرورگر مورد استفاده برای تصمیم‌گیری زمان اجرای اولین رندر را لغو می‌کند: اولین رندر تا زمانی که عنصر مشخص‌شده در درخت DOM وجود داشته باشد به تأخیر می‌افتد.

این مسدود کردن دستی دارای برخی حفاظت‌های داخلی است. به عنوان مثال، وقتی برچسب بسته شدن </html> دیده می‌شود اما عنصر مسدودکننده دیده نمی‌شود، رندر دیگر مسدود نخواهد شد. علاوه بر این، می‌توانید منطق زمان‌بندی خود را اضافه کنید که ویژگی مسدود کردن را در هر نقطه از زمان حذف می‌کند.

بدیهی است که مسدود کردن رندر باید با احتیاط استفاده شود. تاثیر مسدود کردن رندر باید به صورت موردی ارزیابی شود. به طور پیش‌فرض، از استفاده از blocking=render اجتناب کنید، مگر اینکه بتوانید به طور فعال تأثیر آن را بر روی کاربران خود، با اندازه‌گیری تأثیر آن بر معیارهای عملکرد خود، اندازه‌گیری و اندازه‌گیری کنید.

تصور اشتباه 5: فرآیند عکس برداری کند یا گران است

در حالی که View Transition API نمای جدید را آماده می کند و عکس های فوری آن را دریافت می کند، نمای قدیمی برای کاربر قابل مشاهده باقی می ماند. به همین دلیل، کاربر می تواند صفحه قدیمی را کمی طولانی تر از بدون انتقال مشاهده ببیند. اگرچه این تاخیر ناچیز است، در واقعیت فقط چند فریم است. برای مثال، در کروم، تأثیر pageswap حداکثر دو فریم قدیمی است: یکی برای اجرای منطق به علاوه یک فریم اضافی برای اطمینان از ترکیب و ذخیره‌سازی عکس‌های فوری.

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

تصور اشتباه پاداش: این API View Transitions است

هنگام صحبت در مورد انتقال view، مردم اغلب به "View Transitions API" مراجعه می کنند. این نادرست است. API "View Transition API" نامیده می شود - به "Transition" مفرد توجه کنید.

این تصور نادرست از برخی مقاله ها ناشی می شود - از جمله در یک نقطه اسناد خودمان در مورد DCC - از اصطلاح اشتباه استفاده می کنند.

ترفند به خاطر سپردن نام صحیح این است که از (یک) View Transition API برای ایجاد (یک یا چند) ترانزیشن view استفاده می کنید.