View Transit API הוא כלי לשינוי משחקים לפיתוח אתרים. לא משנה אם האתר שלכם הוא דף יחיד או מספר דפים, ה-API העוצמתי הזה מאפשר לכם לעבור בין תצוגות בצורה חלקה וליצור חוויות בסגנון מקורי שמושכות את תשומת הלב של המשתמשים. כרגע זמין ב-Chrome, ובקרוב גם מעברים בין תצוגות מסמכים יהיו זמינים ב-Safari.
יותר ויותר אנשים מתחילים לבחון את View Transition API, והגיע הזמן להפריך כמה תפיסות שגויות.
תפיסה שגויה 1: View Transition API מצלם צילומי מסך
כשמבצעים מעבר בין תצוגות, ה-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: לכידת יותר מרכיב אחד מובילה להפעלה של מעברים מרובים בין תצוגות
כאשר אתם מצלמים מספר רכיבים, תהליך יצירת ה-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)
למרות שעץ זה מכיל מספר צמדים של תמונות מצב, מופעל רק מעבר אחד של תצוגה.
נכון לעכשיו, 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: תהליך יצירת תמונת המצב הוא איטי או יקר
בעוד ש-View מעבר API מכין את התצוגה החדשה ומקבל את תמונות המצב שלה, התצוגה הישנה נשארת גלויה למשתמש. לכן, משתמש יכול לראות את הדף הישן קצת יותר זמן מאשר ללא מעברים בין תצוגות. עם זאת, העיכוב הזה הוא זניח, במציאות רק כמה פריימים. ב-Chrome, ההשפעה של pageswap היא לכל היותר שתי פריימים לא פעילים: אחד להפעלת הלוגיקה ופריים נוסף אחד שיבטיח שקובצי ה-snapshot נוצרו ונשמרו במטמון.
בנוסף, הנתונים של תמונות המצב נלקחים ישירות מהמרכיב, כך שאין צורך לבצע פעולות נוספות של פריסה או צביעה מחדש כדי לקבל את נתוני תמונת המצב.
בונוס תפיסה שגויה: מדובר בממשק API של View Transits
כשמדברים על מעבר בין תצוגות, אנשים בדרך כלל מתייחסים ל-"View Transitions API". זה שגוי. ה-API נקרא 'View Transition API' – חשוב לזכור את 'מעבר' אחד.
התפיסה השגויה נובעת ממאמרים מסוימים – כולל בנקודה מסוימת המסמכים שלנו בנושא DCC – שמשתמשים במונח הלא נכון.
הטריק לזכור את השם הנכון הוא להשתמש בממשק ה-API למעבר של התצוגה (אחד או יותר) כדי ליצור מעברים בין תצוגות (אחת או יותר).