עדכונים של Shared Storage וכתובות URL נבחרות: worklets ממקורות שונים ושאילתות שמורות

Tara Agyemang
Tara Agyemang

ב-Chrome 130 נוספו שינויים ב-Shared Storage API כדי לאפשר שימוש בסקריפטים של רכיבי worklet ממקורות שונים באמצעות createWorklet() ו-addModule(). בנוסף, אנחנו משיקים עדכונים ל-Select URL API עם אחסון משותף ב-Chrome 132, עם תמיכה בשאילתות שמורות.

תרשים שבו מוצגים אתרים רשומים שיכולים לכתוב כל סוג של נתוני מפתח/ערך ב-Shared Storage, אבל קריאת הנתונים מוגבלת לממשקי API ספציפיים של פלט.
ממשק Shared Storage API מאפשר לאתרים רשומים לכתוב כל סוג של נתוני מפתח/ערך ב-Shared Storage, אבל קריאת הנתונים מוגבלת לממשקי API ספציפיים של פלט.

‏worklets ממקורות שונים באמצעות Shared Storage API ב-Chrome 130

שינינו את Shared Storage API בגרסה 130 של Chrome כדי לתת לכם גמישות רבה יותר בעבודה עם סקריפטים של רכיבי worklet ממקורות שונים.

מה השתנה

הסרנו את ההגבלה של מקור זהה עבור addModule(), כך שאפשר עכשיו לטעון סקריפטים של רכיבי worklet מכל מקור. סקריפטים של רכיבי worklet במקורות שונים מאפשרים תרחישים לדוגמה של שימוש במפתחות, כמו אירוח סקריפטים של רכיבי worklet ב-CDN. כשסקריפט ה-worklet הוא ממקור שונה מההקשר של הגלישה שמפעיל אותו, המקור של ההקשר שמפעיל את ה-worklet משמש כמקור של מחיצה של נתונים כדי לגשת לאחסון המשותף.

כדי להתאים להתנהגות החדשה של addModule() ולצמצם את הבלבול הפוטנציאלי, הנכס dataOrigin נוסף לקריאה createWorklet() כדי לאפשר קריאה וכתיבה למחיצה משותפת של נתוני אחסון, ששונה מההקשר של הגלישה שממנו נקראת הקריאה. כך תוכלו לשלוט בצורה פרטנית יותר באחסון המשותף של המקור שאליו כל וורקלט יקבל גישה, גם אם משתמשים בסקריפטים של וורקלט ממקורות שונים.

מה השתנה

החל מגרסה 125 של Chrome, סקריפט של צד שלישי ממקורות שונים בדף יכול ליצור רכיבי worklet ממקורות שונים ללא צורך ברכיבי iframe ממקורות שונים, על ידי קריאה ל-createWorklet(url). בעבר, createWorklet(url) השתמש במקור של כתובת ה-URL של הסקריפט (url) כמקור של מחיצה של נתונים, ללא קשר להקשר ההפעלה.

ב-Chrome 130, כדי להתאים את ההתנהגות החדשה של addModule(), גם createWorklet() משתמש בהקשר ההפעלה כמקור ברירת המחדל של מחיצה לנתונים. כדי להמשיך להשתמש במקור של כתובת ה-URL של הסקריפט כמקור של חלוקת הנתונים, אנחנו משיקים מאפיין חדש dataOrigin שמאפשר להגדיר במפורש את המקור של חלוקת הנתונים.

הנכס החדש dataOrigin מקבל את הערך "script-origin", שמגדיר את המקור של מחיצות הנתונים כמקור הסקריפט, ואת הערך "context-origin", שמגדיר את המקור של מחיצות הנתונים כמקור של הקשר הגלישה שמפעיל את הסקריפט. במהדורה עתידית אנחנו מתכננים גם לתמוך במקורות מותאמים אישית של מחיצות נתונים, שבהם סקריפט של ווירטואל וויטץ' יכול לגשת לנתוני אחסון משותפים ממקור שרירותי על בסיס הסכמה מפורשת.

כשאתם מעמיסים סקריפט בין מקורות עם מקור הנתונים שמוגדר כ-"script-origin", הבקשה לסקריפט שנשלחת מהדפדפן תכלול את הכותרת "Sec-Shared-Storage-Data-Origin: <origin>". כדי לעשות זאת, הסקריפט צריך לכלול גם את כותרת התגובה "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" של הסכמה.

אופן השימוש

אם אתם כבר משתמשים ב-createWorklet() עם מקור הסקריפט כמקור של מחיצה לנתונים של ה-worklet, תוכלו להגדיר את dataOrigin באופן הבא:

sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});

מכיוון ש-createWorklet() מאפשר ליצור מחיצה של נתונים ממקורות שונים וליצור כמה וורקלטס, מומלץ לעבור ל-createWorklet() במקום להשתמש ב-addModule().

עדכנו את מסמכי התיעוד למפתחים כך שישקפו את השינויים האלה ויספקו הנחיות נוספות.

שאילתות שמורות באמצעות Select URL API ב-Chrome 132

אנחנו משיקים עדכונים ל-Select URL API עם אחסון משותף ב-Chrome 132, עם תמיכה בשאילתות שמורות.

מה עומד להשתנות

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

איך מטמיעים שאילתות שמורות

החל מהגרסה 132 של Chrome, אפשר להשתמש בפרמטר savedQuery באפשרויות של selectURL() עם שם השאילתה:

await sharedStorage.selectURL('experiment', urls, {
  savedQuery: 'control_or_experiment',
  keepAlive: true
});

כדי לוודא שהחיוב על שאילתות המשך יתבצע מאותו תקציב, צריך להשתמש באותו שם savedQuery בכל קריאה ל-selectURL().

עדכנו את המסמכים כך שישקפו את השינויים האלה, והוספנו פרטים נוספים לגבי תכנון תקציב ב-selectURL().

יצירת מעורבות ושיתוף משוב

חשוב לזכור שההצעה ל-Shared Storage API נמצאת כרגע בשלבי פיתוח ודיון, ולכן היא כפופה לשינויים.

נשמח לשמוע את דעתכם על Shared Storage API.

אפשר להתעדכן

  • רשימת תפוצה: כדאי להירשם לרשימת התפוצה שלנו כדי לקבל את העדכונים וההודעות האחרונים שקשורים ל-Shared Storage API.

רוצה לקבל עזרה?