תפיסות שגויות לגבי מעבר בין תצוגות מפורטות

View Transition API הוא שינוי משמעותי בפיתוח האינטרנט. בין אם האתר שלכם כולל דף אחד או כמה דפים, ה-API החזק הזה מאפשר לכם ליצור מעברים חלקים בין תצוגות, וכך ליצור חוויות משתמש מקוריות שמרתקות את המשתמשים. התכונה הזו זמינה כרגע ב-Chrome, והמעבר בין תצוגות המסמך יהיה זמין בקרוב גם ב-Safari.

יותר ויותר אנשים מתחילים לבדוק את 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> מוצג אבל הרכיב החוסם לא מוצג, המערכת לא תחסום יותר את העיבוד. בנוסף, אפשר להוסיף לוגיקה משלכם של זמן קצוב לתפוגה, שמסירה את מאפיין החסימה בכל שלב.

ברור שצריך להשתמש בחסימת רינדור בזהירות. צריך להעריך את ההשפעה של חסימה של עיבוד (render) על בסיס כל מקרה לגופו. כברירת מחדל, מומלץ להימנע משימוש ב-blocking=render אלא אם יש לכם אפשרות למדוד ולבחון באופן פעיל את ההשפעה שלו על המשתמשים, על ידי מדידת ההשפעה על מדדי הביצועים.

טעות מוטעית 5: תהליך יצירת קובצי snapshot איטי או יקר

בזמן ש-View Transition API מכין את התצוגה החדשה ומקבל את קובצי ה-snapshot שלה, התצוגה הישנה נשארת גלויה למשתמש. לכן, המשתמש רואה את הדף הישן למשך זמן קצר יותר מאשר ללא מעברים בין תצוגות. עם זאת, העיכוב הזה זניח, ובפועל הוא רק כמה פריימים. לדוגמה, ההשפעה של pageswap ב-Chrome היא שתי תמונות לא עדכניות לכל היותר: אחת להרצת הלוגיקה ועוד תמונה אחת כדי לוודא שתמונות המצב הסטטי (snapshots) אוחדו ונשמרו במטמון.

בנוסף, הנתונים של קובצי ה-snapshot נלקחים ישירות מה-composer, כך שאין צורך לבצע שלבים נוספים של פריסה או צביעה מחדש כדי לקבל את נתוני קובצי ה-snapshot.

טעות נוספת: זהו View Transitions API

כשמדברים על מעברים בין תצוגות, בדרך כלל מתכוונים ל-View Transitions API. המידע הזה שגוי. שם ה-API הוא 'View Transition API' (ממשק API למעברים של תצוגה). שימו לב ליחיד 'Transition'.

השגיאה נובעת מכך שבמאמרים מסוימים – כולל בשלב מסוים במסמכים שלנו בנושא DCC – נעשה שימוש במונח הלא נכון.

הטריק לזכור את השם הנכון הוא להשתמש ב-View Transition API (אחד) כדי ליצור View Transition (אחד או יותר).