Chrome 130 में, शेयर किए गए स्टोरेज एपीआई में बदलाव किए गए हैं. इससे, createWorklet() और addModule() के साथ क्रॉस-ऑरिजिन वर्कलेट स्क्रिप्ट का इस्तेमाल करने की सुविधा चालू की जा सकेगी. हम Chrome 132 में, शेयर किए गए स्टोरेज के साथ Select URL API में अपडेट भी ला रहे हैं. इसमें सेव की गई क्वेरी का इस्तेमाल किया जा सकता है.
Chrome 130 में, Shared Storage API के साथ क्रॉस-ऑरिजिन वर्कलेट
हमने Chrome 130 में, शेयर किए गए स्टोरेज एपीआई में बदलाव किए हैं. इससे, क्रॉस-ऑरिजिन वर्कलेट स्क्रिप्ट के साथ काम करते समय, आपको ज़्यादा सुविधाएं मिल पाएंगी.
क्या बदलाव हुए हैं
हमने addModule() के लिए, एक ही ऑरिजिन से जुड़ी पाबंदी हटा दी है. इसलिए, अब किसी भी ऑरिजिन से वर्कलेट स्क्रिप्ट लोड की जा सकती हैं. क्रॉस-ऑरिजिन वर्कलेट स्क्रिप्ट, इस्तेमाल के मुख्य उदाहरणों को चालू करती हैं. जैसे, सीडीएन पर वर्कलेट स्क्रिप्ट होस्ट करना. जब वर्कलेट स्क्रिप्ट, ब्राउज़िंग कॉन्टेक्स्ट को शुरू करने वाले कॉन्टेक्स्ट से अलग ऑरिजिन की होती है, तो शेयर किए गए स्टोरेज को ऐक्सेस करने के लिए, शुरू करने वाले कॉन्टेक्स्ट के ऑरिजिन का इस्तेमाल डेटा पार्टीशन के ऑरिजिन के तौर पर किया जाता है.
addModule() के नए व्यवहार से मैच करने और संभावित भ्रम को कम करने के लिए, createWorklet() कॉल में dataOrigin प्रॉपर्टी जोड़ी गई है. इससे, शेयर किए गए स्टोरेज के डेटा सेक्शन को पढ़ने और उसमें लिखने की अनुमति मिलती है, जो ब्राउज़िंग कॉन्टेक्स्ट से अलग होता है. इससे आपको यह कंट्रोल करने में मदद मिलती है कि हर वर्कलेट, किस ऑरिजिन के शेयर किए गए स्टोरेज को ऐक्सेस करता है. ऐसा, क्रॉस-ऑरिजिन वर्कलेट स्क्रिप्ट का इस्तेमाल करने पर भी किया जा सकता है.
इसमें क्या बदलाव हुआ है
Chrome 125 के बाद, किसी पेज पर तीसरे पक्ष की क्रॉस-ऑरिजिन स्क्रिप्ट, createWorklet(url) को कॉल करके क्रॉस-ऑरिजिन वर्कलेट बना सकती है. इसके लिए, क्रॉस-ऑरिजिन iframe की ज़रूरत नहीं होती. पहले, createWorklet(url) स्क्रिप्ट यूआरएल (url) ऑरिजिन का इस्तेमाल, डेटा पार्टिशन ऑरिजिन के तौर पर करता था. भले ही, उसे किसी भी कॉन्टेक्स्ट में शुरू किया गया हो.
Chrome 130 में, addModule() के नए व्यवहार के साथ अलाइन करने के लिए, createWorklet()
डेटा पार्टीशन के डिफ़ॉल्ट ऑरिजिन के तौर पर, कॉल करने वाले कॉन्टेक्स्ट का भी इस्तेमाल करता है. स्क्रिप्ट यूआरएल ऑरिजिन को डेटा पार्टिशन ऑरिजिन के तौर पर इस्तेमाल करना जारी रखने के लिए, एक नई प्रॉपर्टी dataOrigin लॉन्च की जा रही है. इससे, डेटा पार्टिशन ऑरिजिन को साफ़ तौर पर सेट किया जा सकेगा.
नई dataOrigin प्रॉपर्टी में "script-origin" का इस्तेमाल किया जा सकता है. यह डेटा के बंटवारे के ऑरिजिन को स्क्रिप्ट के ऑरिजिन के तौर पर सेट करता है. साथ ही, "context-origin" का इस्तेमाल किया जा सकता है. यह डेटा के बंटवारे के ऑरिजिन को, ब्राउज़िंग कॉन्टेक्स्ट के ऑरिजिन के तौर पर सेट करता है. आने वाले समय में, हम कस्टम डेटा पार्टिशन ऑरिजिन के साथ भी काम करने की सुविधा उपलब्ध कराएंगे. इसमें, ऑप्ट-इन करने पर, वर्कलेट स्क्रिप्ट किसी भी ऑरिजिन से शेयर किए गए स्टोरेज डेटा को ऐक्सेस कर सकती है.
डेटा ऑरिजिन को "script-origin" पर सेट करके, क्रॉस-ऑरिजिन स्क्रिप्ट लोड करते समय, ब्राउज़र से भेजी गई स्क्रिप्ट के अनुरोध में "Sec-Shared-Storage-Data-Origin: <origin>" हेडर शामिल होगा. इसे चालू करने के लिए, स्क्रिप्ट में "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" ऑप्ट-इन रिस्पॉन्स हेडर भी शामिल होना चाहिए.
कैसे इस्तेमाल करें
अगर आपने पहले से ही स्क्रिप्ट ऑरिजिन के साथ createWorklet() का इस्तेमाल, वर्कलेट के डेटा सेक्शन के ऑरिजिन के तौर पर किया है, तो dataOrigin को इस तरह सेट किया जा सकता है:
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
createWorklet() की मदद से, क्रॉस-ऑरिजिन डेटा पार्टिशन और कई वर्कलेट बनाए जा सकते हैं. इसलिए, हमारा सुझाव है कि आप addModule() के बजाय createWorklet() का इस्तेमाल करें.
इन बदलावों को दिखाने और ज़्यादा दिशा-निर्देश देने के लिए, हमने डेवलपर दस्तावेज़ को अपडेट कर दिया है.
Chrome 132 में, Select URL API की मदद से सेव की गई क्वेरी
हम Chrome 132 में, शेयर किए गए स्टोरेज के साथ Select URL API में अपडेट पेश कर रहे हैं. इसमें सेव की गई क्वेरी का इस्तेमाल किया जा सकता है.
क्या बदल रहा है
फ़िलहाल, Select URL API में हर पेज लोड के लिए दो बजट होते हैं. ये बजट, हर पेज लोड पर एपीआई को किए जाने वाले कॉल की संख्या को सीमित करते हैं. हम हर पेज के हिसाब से, क्वेरी सेव करने और उनका फिर से इस्तेमाल करने की सुविधा पेश कर रहे हैं. सेव की गई क्वेरी का इस्तेमाल करने पर, हर पेज लोड के लिए तय किए गए बजट का शुल्क, पहली बार सेव की गई क्वेरी के चलने पर लिया जाता है. हालांकि, उसी पेज लोड के दौरान सेव की गई क्वेरी के बाद के चलने पर शुल्क नहीं लिया जाता.
सेव की गई क्वेरी लागू करने का तरीका
Chrome 132 रिलीज़ से, selectURL() के विकल्पों में savedQuery पैरामीटर का इस्तेमाल किया जा सकता है. इसके लिए, क्वेरी का नाम इस्तेमाल करें:
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
selectURL() को किए जाने वाले हर कॉल के लिए, एक ही savedQuery नाम का इस्तेमाल करें. इससे यह पक्का किया जा सकेगा कि फ़ॉलो-अप क्वेरी के लिए, एक ही बजट का इस्तेमाल किया जाए.
इन बदलावों को दिखाने के लिए, हमने दस्तावेज़ को अपडेट किया है. साथ ही, selectURL() के लिए बजट बनाने के बारे में ज़्यादा जानकारी दी है.
दर्शकों से जुड़ना और सुझाव, राय या शिकायत शेयर करना
ध्यान दें कि Shared Storage API के प्रस्ताव पर फ़िलहाल चर्चा की जा रही है और इसे डेवलप किया जा रहा है. इसलिए, इसमें बदलाव हो सकते हैं.
हम शेयर किए गए स्टोरेज के एपीआई के बारे में आपके विचार जानना चाहते हैं.
- प्रस्ताव: ज़्यादा जानकारी वाले प्रस्ताव की समीक्षा करें.
- चर्चा: सवाल पूछने और अपनी अहम जानकारी शेयर करने के लिए, चल रही चर्चा में शामिल हों.
अप-टू-डेट रहना
- मेल सूची: Shared Storage API से जुड़े नए अपडेट और सूचनाओं के लिए, हमारी मेल सूची की सदस्यता लें.
क्या आपको मदद चाहिए?
- डेवलपर सहायता: दूसरे डेवलपर से जुड़ें और Privacy Sandbox के डेवलपर सहायता रिपॉज़िटरी में अपने सवालों के जवाब पाएं.