View Transition API הוא שינוי משמעותי בפיתוח האינטרנט. בין אם האתר שלכם כולל דף אחד או כמה דפים, ה-API החזק הזה מאפשר לכם ליצור מעברים חלקים בין תצוגות, וכך ליצור חוויות משתמש ייחודיות שמרתקות את המשתמשים. התכונה הזו זמינה כרגע ב-Chrome, ובקרוב תהיה זמינה ב-Safari עם אותם מעברים בין תצוגות של מסמכים.
יותר ויותר אנשים מתחילים לבדוק את View Transition API, ולכן הגיע הזמן לנפץ כמה מיתוסים.
תפיסה שגויה 1: View Transition API מצלם צילומי מסך
כשמריצים מעבר תצוגה, ה-API יוצר קובצי snapshot של המצב הישן והחדש של התוכן. לאחר מכן, התמונות הסטטיות האלה מקבלות אנימציה, כפי שמתואר בקטע 'איך פועלים המעברים האלה' במסמכי העזרה.
אפשר להשתמש במונח 'צילום מסך' לגבי קובץ ה-snapshot הישן, אבל קובץ ה-snapshot החדש הוא לא צילום מסך אלא ייצוג חי של הצומת. אפשר לחשוב עליו כאל אלמנט שהוחלף.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
בזכות המאפיין הזה של שידור חי, דמואים כמו זה פועלים: הסרטון – שמגיע מתמונת המצב החדשה – ממשיך לפעול בזמן מעבר התצוגה.
הלוגיקה וה-CSS שנעשה בהם שימוש לצורך כך מפורטים במסמכי העזרה שלנו.
טעות מוטעית 2: צילום של יותר מרכיב אחד גורם להפעלה של כמה מעברים בין תצוגות
כאשר אתם מצלמים מספר רכיבים, תהליך יצירת ה-snapshot יאסוף את כל המצבים הישנים והחדשים. כשמצלמים .box בנוסף לרכיב :root, מקבלים פסאודו עץ:
::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)
העץ הזה מכיל כמה זוגות של קובצי snapshot, אבל רק מעבר תצוגה אחד מופעל.
בשלב הזה, Chrome מוגבל להפעלת מעבר תצוגה אחד בכל מסמך בו-זמנית. כדאי לנסות ללחוץ במהירות בהדגמה הזו כדי להתחיל מעבר חדש לתצוגה. תבחינו שהמעבר הנוכחי ידלג אל הסוף כשמעבר חדש יתחיל.
תפיסה שגויה 3: לא ניתן להטמיע מעברים בין תצוגות מפורטות בגלל התמיכה בדפדפן
הרבה מפתחים חוששים שהם לא יכולים לבצע מעבר בין תצוגות מפורטות כי האפשרות הזו נתמכת רק ב-Chrome. יש חדשות טובות: דפדפן Safari עובד על זה ויכלול אותו בגרסה הקרובה של Safari 18.
עם זאת, אל תתנו לתמיכה הלא עקבית בדפדפנים למנוע מכם להטמיע מעברים בין תצוגות כבר היום. מעברים בין תצוגות הם החומר המושלם לשיפור הדרגתי. בתיעוד המקורי מוסבר איך מוסיפים את המתודולוגיה הזו לקוד.
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 בזמן ניתוח גיליון סגנונות.
הגישה הזו הופעלה בהצלחה במסחר אלקטרוני, כפי שמתואר במחקר המקרה הזה.
טעות מוטעית 4: מעברים באתר משבשים את העיבוד המצטבר
יש טענות לכך שקטעי מעבר בין תצוגות משבשים את העיבוד המצטבר. המצב הזה לא נכון: מעברים בין תצוגות של מסמכים שונים צוינו כדי שלא יפרו את ההיבט הבסיסי הזה של האינטרנט.
דפדפנים מתחילים לעבד דף כשיש להם 'כמות מספקת' של תוכן. ברוב הדפדפנים, זה קורה אחרי טעינת כל גיליונות הסגנון ב-<head>, ניתוח כל קוד ה-JavaScript שגורם לחסימת הרינדור ב-<head> וטעינת מספיק תגי עיצוב. מעברים בין תצוגות במסמכים שונים לא משנים את זה: התוכן הנדרש להצגת תוכן ראשוני לא משתנה. אחרי העיבוד הראשוני, הדפדפן יכול לעבד תוכן חדש באופן מצטבר, ויעשה זאת.
אפשר לבחור לחסום את העיבוד עד שרכיב מסוים יופיע ב-DOM. האפשרות הזו נוחה במצבים שבהם רוצים לוודא שהרכיבים שמשתתפים במעבר התצוגה נמצאים בדף החדש.
לשם כך, צריך להשתמש בתג הקישור הבא:
<link rel="expect" blocking="render" href="#elementId">
ההגדרה הזו מבטלת את שיטת הניתוח ההסתברותי של הדפדפן שמשמשת להחלטה מתי לבצע את העיבוד הגרפי הראשון: העיבוד הגרפי הראשון מתעכב עד שהרכיב שצוין יופיע בעץ ה-DOM.
לחסימה הידנית יש כמה אמצעי הגנה מובנים. לדוגמה, אם התג הסגור </html> מוצג אבל הרכיב החוסם לא מוצג, המערכת לא תחסום יותר את העיבוד. בנוסף, אפשר להוסיף לוגיקה משלכם של זמן קצוב לתפוגה, שמסירה את מאפיין החסימה בכל שלב.
ברור שצריך להשתמש בחסימת רינדור בזהירות. צריך להעריך את ההשפעה של רינדור החסימה על בסיס כל מקרה לגופו. כברירת מחדל, מומלץ להימנע משימוש ב-blocking=render אלא אם יש לכם אפשרות למדוד באופן פעיל את ההשפעה שלו על המשתמשים ולקבוע את מידת ההשפעה על מדדי הביצועים.
טעות מוטעית 5: תהליך יצירת קובצי snapshot איטי או יקר
בזמן ש-View Transition API מכין את התצוגה החדשה ומקבל את קובצי ה-snapshot שלה, התצוגה הישנה נשארת גלויה למשתמש. לכן, המשתמש רואה את הדף הישן למשך זמן קצר יותר מאשר ללא מעברים בין תצוגות. עם זאת, העיכוב הזה הוא זניח, בפועל מדובר בכמה פריימים בלבד. לדוגמה, ההשפעה של pageswap ב-Chrome היא שתי תמונות לא עדכניות לכל היותר: אחת להרצת הלוגיקה ועוד תמונה אחת כדי לוודא שתמונות המצב הסטטי (snapshots) אוחדו ונשמרו במטמון.
בנוסף, הנתונים של תמונות המצב נלקחים ישירות מהמרכיב, כך שאין צורך לבצע פעולות נוספות של פריסה או צביעה מחדש כדי לקבל את נתוני תמונת המצב.
טעות נוספת: זהו View Transitions API
כשמדברים על מעברים בין תצוגות, בדרך כלל מתכוונים ל-View Transitions API. זה שגוי. שם ה-API הוא 'View Transition API' (ממשק API למעבר בין תצוגות). שימו לב ליחיד 'Transition'.
השגיאה נובעת מכך שבמאמרים מסוימים – כולל בשלב מסוים במסמכים שלנו בנושא DCC – נעשה שימוש במונח הלא נכון.
הטריק לזכור את השם הנכון הוא להשתמש ב-View Transition API (אחד) כדי ליצור View Transition (אחד או יותר).