कम शब्दों में कहें, तो एक्सटेंशन एपीआई को अपडेट किया गया है, ताकि बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल किया जा सके. नेविगेशन पहले से लोड किया जा रहा है. ज़्यादा जानकारी के लिए नीचे पढ़ें.
Chrome, नेविगेशन को तेज़ बनाने के लिए लगातार काम कर रहा है. झटपट नेविगेशन बैक/फ़ॉरवर्ड कैश मेमोरी जैसी टेक्नोलॉजी (इन्हें डेस्कटॉप पर शिप किया गया Chrome 96) और अनुमान लगाने के नियम (Chrome 103 में शिप किया गया) पिछले वर्शन और आने वाले समय में आगे बढ़ने, दोनों को बेहतर बनाता है अनुभव. इस पोस्ट में हम ब्राउज़र में किए गए अपडेट के बारे में जानेंगे एक्सटेंशन एपीआई का इस्तेमाल करें, ताकि इन नए वर्कफ़्लो को शामिल किया जा सके.
अलग-अलग तरह के पेजों को समझना
बैक/फ़ॉरवर्ड कैश मेमोरी और प्रीरेंडरिंग की सुविधा के इस्तेमाल से पहले, टैब में सिर्फ़ एक चालू पेज था. हमेशा यही मैसेज दिखता था. अगर कोई उपयोगकर्ता पिछले पेज पर वापस जाता है, तो चालू पेज खत्म हो जाएगा (पेज B) और इतिहास में पिछले पेज को पूरी तरह से बनाया जाएगा (पेज A). एक्सटेंशन को इस बात की चिंता करने की ज़रूरत नहीं थी कि लाइफ़ साइकल के पेजों का कौनसा हिस्सा क्योंकि एक टैब के लिए केवल एक ही था, यानी सक्रिय/दृश्यमान स्थिति.
बैक/फ़ॉरवर्ड कैश मेमोरी और प्रीरेंडरिंग के साथ, अब एक-एक करके टैब और पेजों के बीच संबंध. अब, हर टैब में कई सारे पेजों और पेजों को खत्म होने के बजाय, एक से दूसरी स्थिति में फिर से बनाया गया.
उदाहरण के लिए, कोई पेज अपना लाइफ़, पहले से रेंडर किए गए (न दिखने वाले) पेज के तौर पर शुरू कर सकता है, उपयोगकर्ता के किसी लिंक पर क्लिक करने पर, किसी ऐक्टिव (दिखने वाले) पेज पर ले जाने के लिए और उपयोगकर्ता के यहां नेविगेट करने पर बैक/फ़ॉरवर्ड कैश मेमोरी (दिखाई नहीं देने वाली) में सेव की जानी चाहिए वह दूसरा पेज हो, वह भी पेज को नष्ट किए बिना. इस लेख में आगे का हिस्सा हम उन नई प्रॉपर्टी पर नज़र डालते हैं, जो एक्सटेंशन की सहायता करने के लिए स्थिति वाले पेज में हैं.
ध्यान दें कि किसी टैब में पहले से रेंडर किए गए पेजों की सीरीज़ (सिर्फ़ एक नहीं) हो सकती है. active (दिखने वाला) पेज और बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किए गए पेजों की सीरीज़.
एक्सटेंशन डेवलपर के लिए क्या बदलाव हो रहे हैं?
फ़्रेम आईडी == 0
Chromium में, हम सबसे ऊपर/मुख्य फ़्रेम को सबसे बाहरी फ़्रेम मानते हैं.
frameId का इस्तेमाल करने वाले एक्सटेंशन लेखक
सबसे बाहरी फ़्रेम में 0 है (जो पिछला सबसे सही तरीका है) में समस्याएं हो सकती हैं.
किसी टैब में अब एक से ज़्यादा बाहरी फ़्रेम (पहले से रेंडर किए गए और कैश मेमोरी में सेव किए गए) हो सकते हैं
पेज) पर हो, तो यह अनुमान लगाना कि वह
टैब का फ़्रेम गलत है. frameId == 0
अब भी प्रतिनिधित्व करता रहेगा
सक्रिय पेज का बाहरी फ़्रेम, लेकिन आपकी सबसे बाहरी फ़्रेम
एक ही टैब में मौजूद अन्य पेज शून्य नहीं होंगे. एक नए फ़ील्ड frameType में
को इस समस्या को ठीक करने के लिए जोड़ा गया है. “मैं कैसे पता करूं कि कोई फ़्रेम सबसे बाहरी फ़्रेम है या नहीं?”
सेक्शन में जाएं.
फ़्रेम बनाम दस्तावेज़ों की लाइफ़ साइकल
एक्सटेंशन के साथ समस्या पैदा करने वाली एक और अवधारणा है, जिसमें फ़्रेम. फ़्रेम एक दस्तावेज़ को होस्ट करता है (जो एक तय यूआरएल से जुड़ा हुआ है). दस्तावेज़ बदल सकता है (जैसे कि नेविगेट करके). हालांकि, frameId नहीं बदल सकता. इसलिए, यह यह संबद्ध करना मुश्किल है कि किसी ख़ास दस्तावेज़ में कुछ हुआ है सिर्फ़ frameIds हैं. हम documentId का कॉन्सेप्ट इस्तेमाल कर रहे हैं जो हर दस्तावेज़ का यूनीक आइडेंटिफ़ायर होता है. अगर किसी फ़्रेम पर नेविगेट किया जाता है और एक नया दस्तावेज़ खोलता है, जिसमें आइडेंटिफ़ायर बदल जाएगा. यह फ़ील्ड इनके लिए काम का है यह तय करना कि पेज की लाइफ़ साइकल की स्थिति कब बदलती है (समयावधि के बीच प्रीरेंडरिंग/ऐक्टिव/कैश मेमोरी में सेव किया जाएगा, क्योंकि यह पहले जैसा ही रहेगा.
वेब नेविगेशन इवेंट
chrome.webNavigation
नेमस्पेस में इवेंट
कई बार फ़ायर हो सकता है,
अपनी लाइफ़ साइकल के हिसाब से, उसे एक जैसा ही रखा जा सकता है. यहां जाएं:
“मैं कैसे पता करूं कि पेज किस लाइफ़ साइकल में है?”
और “मैं कैसे तय करूं कि किसी पेज का ट्रांज़िशन कब होता है?”.
मैं यह कैसे पता करूं कि पेज किस लाइफ़ साइकल में है?
DocumentLifecycle
टाइप को ऐसे कई एक्सटेंशन एपीआई में जोड़ा गया है जिनमें frameId
जो पहले उपलब्ध थे. अगर किसी इवेंट में DocumentLifecycle
टाइप मौजूद है
(जैसे कि onCommitted
),
इसकी वैल्यू वह स्थिति होती है जिसमें इवेंट जनरेट किया गया था. कभी भी क्वेरी की जा सकती है
WebNavigation
getFrame()
से मिली जानकारी
और getAllFrames()
तरीकों का इस्तेमाल करते हैं, लेकिन इवेंट के मान का इस्तेमाल करना हमेशा बेहतर माना जाता है. अगर आपको
दोनों में से किसी भी तरीके से यह जान लें कि इवेंट के बीच में फ़्रेम की स्थिति बदल सकती है
जनरेट किया गया था. साथ ही, जब दोनों तरीकों से किए गए वादों को वापस करने की समस्या हल हो गई हो.
DocumentLifecycle
में ये वैल्यू होती हैं:
"prerender
" : फ़िलहाल, यह उपयोगकर्ता को नहीं दिखाया जा रहा है, लेकिन इसे उपयोगकर्ताओं को दिखाए जाने के लिए तैयार किया जा रहा है."active"
: इस समय उपयोगकर्ता को दिखाया जा रहा है."cached"
: बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किया जाता है."pending_deletion"
: दस्तावेज़ को नष्ट किया जा रहा है.
मैं कैसे तय करूं कि कोई फ़्रेम सबसे बाहरी फ़्रेम है या नहीं?
हो सकता है कि पहले एक्सटेंशन ने यह जांच की हो कि frameId == 0
को यह पता लगाने के लिए
सबसे बाहरी फ़्रेम के लिए है या नहीं. एक से ज़्यादा पेजों के साथ
अब हमारे पास कई बाहरी फ़्रेम हैं, तो frameId की परिभाषा
समस्या होती है. बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किए गए किसी इवेंट की जानकारी आपको कभी नहीं मिलेगी
फ़्रेम. हालांकि, पहले से रेंडर किए गए फ़्रेम के लिए, frameId
बाहरी फ़्रेम के लिए नॉन-ज़ीरो. इसलिए, frameId == 0
का इस्तेमाल सिग्नल के तौर पर किया जा रहा है
यह तय करना कि क्या यह सबसे बाहरी फ़्रेम गलत है.
इसमें मदद करने के लिए, हमने नाम का एक नया टाइप जोड़ा है
FrameType
इसलिए यह तय करना अब आसान है कि फ़्रेम वाकई सबसे बाहरी फ़्रेम है या नहीं.
FrameType
की वैल्यू ये हैं:
"outermost_frame"
: आम तौर पर, इसे सबसे ऊपरी फ़्रेम कहा जाता है. ध्यान दें कि कई तरीके हैं. उदाहरण के लिए, अगर आपने पहले से रेंडर किया गया हो और कैश मेमोरी में सेव किया हो है, तो हर पेज का एक बाहरी फ़्रेम होता है, जिसे उसका सबसे ऊपरी फ़्रेम कहा जा सकता है."fenced_frame"
: आने वाले समय में इस्तेमाल के लिए रिज़र्व किया गया."sub_frame"
: आम तौर पर, एक iframe.
हम DocumentLifecycle
को FrameType
से जोड़कर, यह तय कर सकते हैं कि फ़्रेम
बाहरी फ़्रेम को ऐक्टिवेट करें. जैसे:
tab.documentLifecycle === “active” && frameType === “outermost_frame”
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
मैं फ़्रेम के इस्तेमाल के समय से जुड़ी समस्याओं को कैसे हल करूं?
जैसा कि हमने ऊपर बताया है कि फ़्रेम एक दस्तावेज़ को होस्ट करता है और फ़्रेम नए
दस्तावेज़ सेट अप करने के लिए किया जा सकता है, लेकिन frameId
में कोई बदलाव नहीं होगा. इससे समस्याएं पैदा होती हैं जब
सिर्फ़ frameId
से इवेंट पाएं. अगर आप यूआरएल देखते हैं
जिस समय यह इवेंट घटने के समय से अलग हो सकता है, उसे
इस्तेमाल के समय की समस्या है.
इस समस्या को हल करने के लिए, हमने documentId
को लॉन्च किया
(और parentDocumentId
).
webNavigation.getFrame()
अगर documentId
दिया गया है, तो इस तरीके से अब frameId
को ज़रूरी नहीं माना जाएगा. कॉन्टेंट बनाने
जब भी फ़्रेम पर नेविगेट किया जाएगा, documentId
बदल जाएगा.
मैं यह कैसे तय करूं कि किसी पेज का ट्रांज़िशन कब होता है?
यह पता करने के लिए अश्लील सिग्नल होते हैं कि कोई पेज कब राज्यों के बीच बदलता है.
आइए, WebNavigation
इवेंट पर नज़र डालते हैं.
किसी भी पेज पर सबसे पहले नेविगेशन करने के लिए, आपको क्रम में चार इवेंट दिखेंगे
नीचे दी गई सूची उपलब्ध है. ध्यान दें कि ये चार इवेंट,
DocumentLifecycle
की स्थिति "prerender"
या "active"
है.
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
इसे नीचे दिए गए डायग्राम में दिखाया गया है. इसमें documentId
को बदलते हुए दिखाया गया है
"xyz"
तक, पहले से रेंडर किया गया पेज ऐक्टिव पेज बन जाने पर.
जब किसी पेज का ट्रांज़िशन, बैक/फ़ॉरवर्ड कैश मेमोरी या प्रीरेंडरिंग से
चालू स्थिति में तीन और इवेंट होंगे (लेकिन DocumentLifecyle
के साथ
"active"
है).
onBeforeNavigate
onCommitted
onCompleted
documentId
, ओरिजनल इवेंट जैसा ही रहेगा. यह है
ऊपर दी गई इमेज तब दिख रही है, जब documentId
== xyz चालू हो जाता है. ध्यान दें कि
onDOMContentLoaded
को छोड़कर, सभी नेविगेशन इवेंट ट्रिगर होते हैं
इवेंट शामिल है, क्योंकि पेज पहले ही लोड हो चुका है.
अगर आपकी कोई टिप्पणी या सवाल है, तो कृपया बेझिझक Chromium एक्सटेंशन ग्रुप.