अगर आपके पास Rhino रनटाइम का इस्तेमाल करने वाली स्क्रिप्ट है और आपको इसलिए, आपको स्क्रिप्ट को V8 पर माइग्रेट करना होगा.
Rhino रनटाइम का इस्तेमाल करके लिखी गई ज़्यादातर स्क्रिप्ट, V8 रनटाइम का इस्तेमाल करके बिना किसी बदलाव के काम कर सकती हैं. अक्सर V8 सिंटैक्स जोड़ने की ज़रूरत होती है और स्क्रिप्ट में दी जाने वाली सुविधाएं V8 रनटाइम चालू करके.
हालांकि, ऐसी रिसर्च टेक्नोलॉजी का एक छोटा सेट है. यह सुविधा किन मामलों में काम नहीं करती और ऐसे अन्य अंतर जिनकी वजह से स्क्रिप्ट तैयार हो सकती है V8 रनटाइम को चालू करने के बाद, अचानक कोई गड़बड़ी या गड़बड़ी होना. माइग्रेट करने पर अगर आपको V8 का इस्तेमाल करना है, तो आपको इन समस्याओं के लिए स्क्रिप्ट प्रोजेक्ट में खोजना होगा और सही करें.
V8 माइग्रेशन प्रोसेस
स्क्रिप्ट को V8 पर माइग्रेट करने के लिए, यह तरीका अपनाएं:
- स्क्रिप्ट के लिए, V8 रनटाइम चालू करें.
- अनियमितताओं की ध्यान से समीक्षा करें नीचे दी गई सूची उपलब्ध है. अपनी स्क्रिप्ट की जांच करके पता लगाएं कि साथ ही काम नहीं करता हो; अगर एक या उससे ज़्यादा साथ काम नहीं करता है, इस समस्या को हल करने या इससे बचने के लिए, अपने स्क्रिप्ट कोड में बदलाव करें.
- नीचे दिए गए अन्य अंतर ध्यान से पढ़ें. अपनी स्क्रिप्ट की जांच करके पता लगाएं कि क्या सूची में दिए गए किसी भी अंतर का असर पड़ता है का व्यवहार है. बिहेवियर ठीक करने के लिए, अपनी स्क्रिप्ट में बदलाव करें.
- आपके द्वारा पाई गई किसी भी असंगति या अन्य अंतर है, तो आप कोड अपडेट करना शुरू कर सकते हैं, ताकि आप V8 सिंटैक्स और अन्य सुविधाएं ज़रूरत के हिसाब से.
- कोड में बदलाव करने के बाद, अपनी स्क्रिप्ट की अच्छी तरह से जांच करें, ताकि यह पक्का किया जा सके कि यह उम्मीद के मुताबिक काम कर रही है.
- अगर आपकी स्क्रिप्ट कोई वेब ऐप्लिकेशन है या आपने ऐड-ऑन पब्लिश किया है, आपको ज़रूर नया वर्शन बनाएं की स्क्रिप्ट को V8 अडजस्टमेंट के साथ सेट किया है. V8 वर्शन को इन लोगों के लिए उपलब्ध कराने के लिए उपयोगकर्ताओं के लिए, आपको इस वर्शन के साथ स्क्रिप्ट को फिर से पब्लिश करना होगा.
साथ काम नहीं करती
माफ़ करें, Rhino आधारित Apps Script के ओरिजनल रनटाइम ने कई गैर-मानक ECMAScript व्यवहार. V8 स्टैंडर्ड का पालन करता है. इसलिए, ये माइग्रेशन के बाद, व्यवहार से जुड़ी सेटिंग काम नहीं करती है. इन समस्याओं को ठीक न करने पर, V8 रनटाइम चालू होने के बाद, गड़बड़ियां या स्क्रिप्ट के काम न करने की समस्याएं आ सकती हैं.
यहां दिए गए सेक्शन में, इन सभी कार्रवाइयों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि आपको ये काम करने होंगे का इस्तेमाल करें.
for each(variable in object) से बचें
कॉन्टेंट बनाने
for each (variable in object)
स्टेटमेंट को JavaScript 1.6 में जोड़ा गया और for...of के पक्ष में हटाया गया.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, for each (variable in object) का इस्तेमाल करने से बचें
स्टेटमेंट.
इसके बजाय, for (variable in object) का इस्तेमाल करें:
// Rhino runtime var obj = {a: 1, b: 2, c: 3}; // Don't use 'for each' in V8 for each (var value in obj) { Logger.log("value = %s", value); } |
// V8 runtime var obj = {a: 1, b: 2, c: 3}; for (var key in obj) { // OK in V8 var value = obj[key]; Logger.log("value = %s", value); } |
Date.prototype.getYear() से बचें
असल गैंडा के रनटाइम में,
Date.prototype.getYear()
1900 से 1999 तक के सालों के लिए दो अंकों वाला साल लौटाता है, लेकिन अन्य के लिए चार अंकों वाला साल लौटाता है
तारीखें शामिल होती हैं, जो JavaScript 1.2 और उससे पहले के व्यवहार में होती थी.
V8 रनटाइम में,
Date.prototype.getYear()
ज़रूरत के हिसाब से, साल 1900 को घटाता है
ECMAScript स्टैंडर्ड.
स्क्रिप्ट को V8 पर माइग्रेट करते समय, हमेशा
Date.prototype.getFullYear(),
जो तारीख पर ध्यान दिए बिना चार अंकों वाला साल दिखाता है.
नाम के तौर पर, रिज़र्व किए गए कीवर्ड का इस्तेमाल करने से बचें
ECMAScript, फ़ंक्शन और वैरिएबल के नामों में कुछ रिज़र्व किए गए कीवर्ड का इस्तेमाल करने की अनुमति नहीं देता. राइनो रनटाइम ने इनमें से कई शब्दों को अनुमति दी, इसलिए, अगर आपका कोड उनका इस्तेमाल करता है, तो आपको अपने फ़ंक्शन या वैरिएबल के नाम बदलने होंगे.
स्क्रिप्ट को V8 पर माइग्रेट करते समय, वैरिएबल या फ़ंक्शन का नाम रखने से बचें
किसी एक विकल्प का इस्तेमाल करके
रिज़र्व किए गए कीवर्ड का इस्तेमाल करें.
कीवर्ड के नाम का इस्तेमाल करने से बचने के लिए, किसी भी वैरिएबल या फ़ंक्शन का नाम बदलें. नाम के तौर पर कीवर्ड का इस्तेमाल करने के लिए, class, import, और export का इस्तेमाल किया जाता है.
const वैरिएबल को फिर से असाइन करने से बचें
मूल Rhino रनटाइम में, const का इस्तेमाल करके, वैरिएबल के बारे में बताया जा सकता है
इसका मतलब है कि प्रतीक का मान कभी नहीं बदलेगा और भविष्य में
चिह्नों को अनदेखा किया जाता है.
नए V8 रनटाइम में, const कीवर्ड स्टैंडर्ड के मुताबिक है. const के तौर पर घोषित किए गए वैरिएबल को असाइन करने पर, TypeError: Assignment to constant variable रनटाइम गड़बड़ी होती है.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय,
एक const वैरिएबल:
// Rhino runtime const x = 1; x = 2; // No error console.log(x); // Outputs 1 |
// V8 runtime const x = 1; x = 2; // Throws TypeError console.log(x); // Never executed |
एक्सएमएल लिटरल और एक्सएमएल ऑब्जेक्ट का इस्तेमाल न करें
यह नॉन-स्टैंडर्ड एक्सटेंशन को ECMAScript के साथ शेयर किया जाता है. इससे Apps Script प्रोजेक्ट, सीधे एक्सएमएल सिंटैक्स का इस्तेमाल कर पाते हैं.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, डायरेक्ट एक्सएमएल की लिटरल वैल्यू या एक्सएमएल का इस्तेमाल करने से बचें ऑब्जेक्ट ढूंढें.
इसके बजाय, XmlService का इस्तेमाल करके एक्सएमएल को पार्स करें:
// V8 runtime var incompatibleXml1 = <container><item/></container>; // Don't use var incompatibleXml2 = new XML('<container><item/></container>'); // Don't use var xml3 = XmlService.parse('<container><item/></container>'); // OK |
__iterator__ का इस्तेमाल करके, कस्टम इटरेटर फ़ंक्शन न बनाएं
JavaScript 1.7 में एक ऐसी सुविधा जोड़ी गई है जो किसी भी क्लॉज़ में कस्टम इटरेटर जोड़ने की अनुमति देती है
s उस क्लास के प्रोटोटाइप में __iterator__ फ़ंक्शन का एलान करके; यह था
इसे डेवलपर सुविधा के तौर पर Apps Script के Rhino रनटाइम में भी जोड़ा जा सकता है. हालांकि,
यह सुविधा कभी भी
ECMA-262 स्टैंडर्ड
और इसे ECMAScript का पालन करने वाले JavaScript इंजन से हटा दिया गया था. V8 का इस्तेमाल करने वाली स्क्रिप्ट, इस इटरेटटर कंस्ट्रक्शन का इस्तेमाल नहीं कर सकतीं.
स्क्रिप्ट को V8 पर माइग्रेट करते समय, __iterator__ फ़ंक्शन का इस्तेमाल न करें
कस्टम इटरेटर. इसके बजाय,
ECMAScript 6 के इटरेटर का इस्तेमाल करें.
नीचे दिए गए कलेक्शन का इस्तेमाल करें:
// Create a sample array var myArray = ['a', 'b', 'c']; // Add a property to the array myArray.foo = 'bar'; // The default behavior for an array is to return keys of all properties, // including 'foo'. Logger.log("Normal for...in loop:"); for (var item in myArray) { Logger.log(item); // Logs 0, 1, 2, foo } // To only log the array values with `for..in`, a custom iterator can be used. |
ये कोड उदाहरण दिखाते हैं कि राइनो रनटाइम और V8 रनटाइम में रीप्लेसमेंट इटरेटर बनाने का तरीका जानें:
// Rhino runtime custom iterator function ArrayIterator(array) { this.array = array; this.currentIndex = 0; } ArrayIterator.prototype.next = function() { if (this.currentIndex >= this.array.length) { throw StopIteration; } return "[" + this.currentIndex + "]=" + this.array[this.currentIndex++]; }; // Direct myArray to use the custom iterator myArray.__iterator__ = function() { return new ArrayIterator(this); } Logger.log("With custom Rhino iterator:"); for (var item in myArray) { // Logs [0]=a, [1]=b, [2]=c Logger.log(item); } |
// V8 runtime (ECMAScript 6) custom iterator myArray[Symbol.iterator] = function() { var currentIndex = 0; var array = this; return { next: function() { if (currentIndex < array.length) { return { value: "[${currentIndex}]=" + array[currentIndex++], done: false}; } else { return {done: true}; } } }; } Logger.log("With V8 custom iterator:"); // Must use for...of since // for...in doesn't expect an iterable. for (var item of myArray) { // Logs [0]=a, [1]=b, [2]=c Logger.log(item); } |
शर्तों के साथ इस्तेमाल होने वाले 'कैच' क्लॉज़ से बचना
V8 रनटाइम पर, catch..if कंडिशनल कैच क्लॉज़ काम नहीं करते, क्योंकि वे
जो मानक के मुताबिक नहीं हैं.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, कैच कंडिशनल को शरीर को पकड़ो:
// Rhino runtime try { doSomething(); } catch (e if e instanceof TypeError) { // Don't use // Handle exception } |
// V8 runtime try { doSomething(); } catch (e) { if (e instanceof TypeError) { // Handle exception } } |
Object.prototype.toSource() का इस्तेमाल करने से बचें
JavaScript 1.3 में एक ऐसा तरीका था, Object.prototype.toSource() जो कभी भी किसी ECMAScript स्टैंडर्ड का हिस्सा नहीं था. यह इन भाषाओं में काम नहीं करता V8 रनटाइम.
स्क्रिप्ट को V8 पर माइग्रेट करते समय, Object.prototype.toSource() हटाएं.
अन्य अंतर
ऊपर दी गई असंगतताओं के अलावा, जिनके कारण स्क्रिप्ट विफल हो सकती हैं, वहां कुछ ऐसे अंतर भी हैं जिन्हें ठीक न किए जाने पर, V8 रनटाइम स्क्रिप्ट व्यवहार.
नीचे दिए सेक्शन में बताया गया है कि इनसे बचने के लिए, स्क्रिप्ट कोड को कैसे अपडेट करें अचानक घटने-बढ़ने वाला खतरा हो सकता है.
स्थान-भाषा के हिसाब से, तारीख और समय की फ़ॉर्मैटिंग में बदलाव करना
Date
toLocaleString() तरीके,
toLocaleDateString(),
और toLocaleTimeString() ये काम करता है
V8 के रनटाइम में काफ़ी अंतर होता है.
Rhino में डिफ़ॉल्ट फ़ॉर्मैट लंबा फ़ॉर्मैट होता है और इसमें पास किए गए सभी पैरामीटर शामिल होते हैं इसे अनदेखा किया गया है.
V8 रनटाइम में, छोटा फ़ॉर्मैट और पैरामीटर, डिफ़ॉल्ट फ़ॉर्मैट होते हैं
को ECMA मानक के अनुसार हैंडल किया जाता है (देखें कि
toLocaleDateString() दस्तावेज़
देखें).
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, जांच करें और अपने कोड के मुताबिक काम करें स्थान-भाषा के हिसाब से तारीख और समय के आउटपुट के बारे में:
// Rhino runtime var event = new Date( Date.UTC(2012, 11, 21, 12)); // Outputs "December 21, 2012" in Rhino console.log(event.toLocaleDateString()); // Also outputs "December 21, 2012", // ignoring the parameters passed in. console.log(event.toLocaleDateString( 'de-DE', { year: 'numeric', month: 'long', day: 'numeric' })); |
// V8 runtime var event = new Date( Date.UTC(2012, 11, 21, 12)); // Outputs "12/21/2012" in V8 console.log(event.toLocaleDateString()); // Outputs "21. Dezember 2012" console.log(event.toLocaleDateString( 'de-DE', { year: 'numeric', month: 'long', day: 'numeric' })); |
Error.fileName और Error.lineNumber का इस्तेमाल करने से बचें
V8 untime में, स्टैंडर्ड JavaScript
Error
ऑब्जेक्ट, fileName या lineNumber को कन्स्ट्रक्टर पैरामीटर या ऑब्जेक्ट प्रॉपर्टी के तौर पर इस्तेमाल नहीं कर सकता.
स्क्रिप्ट को V8 पर माइग्रेट करते समय,
Error.fileName और Error.lineNumber पर निर्भर किसी भी शर्त को हटाएं.
इसका एक विकल्प यह है कि
Error.prototype.stack.
यह स्टैक स्टैंडर्ड के मुताबिक नहीं है. हालांकि, यह Rhino और V8, दोनों पर काम करता है. दोनों प्लैटफ़ॉर्म से जनरेट किए गए स्टैक ट्रेस का फ़ॉर्मैट थोड़ा अलग होता है:
// Rhino runtime Error.prototype.stack // stack trace format at filename:92 (innerFunction) at filename:97 (outerFunction) |
// V8 runtime Error.prototype.stack // stack trace format Error: error message at innerFunction (filename:92:11) at outerFunction (filename:97:5) |
स्ट्रिंगिफ़ाइड ईनम ऑब्जेक्ट की हैंडलिंग को अडजस्ट करें
JavaScript का इस्तेमाल करके, मूल Rhino रनटाइम में
JSON.stringify()
enum ऑब्जेक्ट पर तरीका सिर्फ़ {} दिखाता है.
V8 में, ईनम ऑब्जेक्ट पर एक ही तरीके का इस्तेमाल करने से, ईनम का नाम फिर से बदल जाता है.
स्क्रिप्ट को V8 पर माइग्रेट करते समय,
के आउटपुट के संबंध में आपके कोड की अपेक्षाओं की जांच और उन्हें समायोजित करेगा
JSON.stringify()
ईनम ऑब्जेक्ट पर:
// Rhino runtime var enumName = JSON.stringify(Charts.ChartType.BUBBLE); // enumName evaluates to {} |
// V8 runtime var enumName = JSON.stringify(Charts.ChartType.BUBBLE); // enumName evaluates to "BUBBLE" |
तय नहीं किए गए पैरामीटर की हैंडलिंग में बदलाव करना
ओरिजनल Rhino रनटाइम में, undefined को पैरामीटर के तौर पर, एक तरीके से पास किया जाता है
नतीजे के तौर पर, उस तरीके में "undefined" स्ट्रिंग पास की गई.
V8 में, undefined को तरीकों में पास करना, null को पास करने के बराबर है.
स्क्रिप्ट को V8 पर माइग्रेट करते समय,
undefined पैरामीटर के बारे में अपने कोड के हिसाब से जांच करें और उसमें बदलाव करें:
// Rhino runtime SpreadsheetApp.getActiveRange() .setValue(undefined); // The active range now has the string // "undefined" as its value. |
// V8 runtime SpreadsheetApp.getActiveRange() .setValue(undefined); // The active range now has no content, as // setValue(null) removes content from // ranges. |
ग्लोबल this की हैंडलिंग में बदलाव करें
Rhino रनटाइम, इसका इस्तेमाल करने वाली स्क्रिप्ट के लिए एक खास कॉन्टेक्स्ट के बारे में बताता है.
स्क्रिप्ट कोड इस इंप्लिसिट कॉन्टेक्स्ट में चलता है, जो असल ग्लोबल से अलग होता है
this. इसका मतलब है कि "ग्लोबल this" के रेफ़रंस कोड में
विशेष संदर्भ में मूल्यांकन करें, जिसमें केवल कोड और वैरिएबल होते हैं
स्क्रिप्ट में परिभाषित किया गया है. पहले से मौजूद Apps Script सेवाएं और ECMAScript ऑब्जेक्ट
को this के इस इस्तेमाल में शामिल नहीं किया जाता. यह स्थिति, इस JavaScript स्ट्रक्चर से मिलती-जुलती थी:
// Rhino runtime // Apps Script built-in services defined here, in the actual global context. var SpreadsheetApp = { openById: function() { ... } getActive: function() { ... } // etc. }; function() { // Implicit special context; all your code goes here. If the global this // is referenced in your code, it only contains elements from this context. // Any global variables you defined. var x = 42; // Your script functions. function myFunction() { ... } // End of your code. }(); |
V8 में, इंप्लिसिट स्पेशल कॉन्टेक्स्ट हटा दिया गया है. ग्लोबल वैरिएबल और फ़ंक्शन
स्क्रिप्ट में परिभाषित बिल्ट-इन के बगल में वैश्विक संदर्भ में रखे जाते हैं
Apps Script सेवाएं और ECMAScript बिल्ट-इन. जैसे, Math और Date.
अपनी स्क्रिप्ट को V8 पर माइग्रेट करते समय, जांच करें और अपने कोड के मुताबिक काम करें
दुनिया भर में this के इस्तेमाल पर बात करते हैं. ज़्यादातर मामलों में, अंतर सिर्फ़ तब दिखता है, जब आपका कोड ग्लोबल this ऑब्जेक्ट की कुंजियों या प्रॉपर्टी के नामों की जांच करता है:
// Rhino runtime var myGlobal = 5; function myFunction() { // Only logs [myFunction, myGlobal]; console.log(Object.keys(this)); // Only logs [myFunction, myGlobal]; console.log( Object.getOwnPropertyNames(this)); } |
// V8 runtime var myGlobal = 5; function myFunction() { // Logs an array that includes the names // of Apps Script services // (CalendarApp, GmailApp, etc.) in // addition to myFunction and myGlobal. console.log(Object.keys(this)); // Logs an array that includes the same // values as above, and also includes // ECMAScript built-ins like Math, Date, // and Object. console.log( Object.getOwnPropertyNames(this)); } |
लाइब्रेरी में instanceof की हैंडलिंग में बदलाव करें
लाइब्रेरी में instanceof का इस्तेमाल एक ऐसे ऑब्जेक्ट पर किया जा रहा है जिसे
किसी दूसरे प्रोजेक्ट का फ़ंक्शन, फ़ॉल्स नेगेटिव दे सकता है. V8 रनटाइम में, किसी प्रोजेक्ट और उसकी लाइब्रेरी को अलग-अलग एक्सीक्यूशन कॉन्टेक्स्ट में चलाया जाता है. इसलिए, इनमें अलग-अलग ग्लोबल और प्रोटोटाइप चेन होती हैं.
ध्यान दें कि ऐसा सिर्फ़ तब होता है, जब आपकी लाइब्रेरी किसी ऐसे ऑब्जेक्ट पर instanceof का इस्तेमाल करती है जो आपके प्रोजेक्ट में नहीं बनाया गया है. इसका इस्तेमाल ऐसे ऑब्जेक्ट में करना जिसमें बनाया गया है
चाहे आपके प्रोजेक्ट की स्क्रिप्ट उसी या किसी दूसरी स्क्रिप्ट में हो,
उम्मीद के मुताबिक काम करना चाहिए.
अगर V8 पर चल रहा कोई प्रोजेक्ट, आपकी स्क्रिप्ट को लाइब्रेरी के तौर पर इस्तेमाल करता है, तो देखें कि
स्क्रिप्ट उस पैरामीटर पर instanceof का इस्तेमाल करती है जिसे किसी दूसरे प्रोजेक्ट से पास किया जाएगा. अडजस्ट करें
instanceof का इस्तेमाल और अपने हिसाब से, अन्य विकल्प इस्तेमाल करें
केस.
a instanceof b का एक विकल्प यह हो सकता है कि a के कंस्ट्रक्टर का इस्तेमाल किया जाए
ऐसे मामले, जहां आपको पूरी प्रोटोटाइप चेन में खोजने की ज़रूरत नहीं है और सिर्फ़
कंस्ट्रक्टर है.
इस्तेमाल: a.constructor.name == "b"
प्रोजेक्ट A और प्रोजेक्ट B का इस्तेमाल करें, जहां प्रोजेक्ट A का इस्तेमाल लाइब्रेरी के तौर पर किया जाता है.
//Rhino runtime //Project A function caller() { var date = new Date(); // Returns true return B.callee(date); } //Project B function callee(date) { // Returns true return(date instanceof Date); } |
//V8 runtime //Project A function caller() { var date = new Date(); // Returns false return B.callee(date); } //Project B function callee(date) { // Incorrectly returns false return(date instanceof Date); // Consider using return (date.constructor.name == // “Date”) instead. // return (date.constructor.name == “Date”) -> Returns // true } |
इसके अलावा, एक और विकल्प यह है कि कोई ऐसा फ़ंक्शन बनाया जाए जो मुख्य प्रोजेक्ट में instanceof की जांच करता हो और लाइब्रेरी फ़ंक्शन को कॉल करते समय, अन्य पैरामीटर के साथ-साथ फ़ंक्शन को भी पास करता हो. इसके बाद, पास किए गए फ़ंक्शन का इस्तेमाल करके, लाइब्रेरी में instanceof की जांच की जा सकती है.
//V8 runtime //Project A function caller() { var date = new Date(); // Returns True return B.callee(date, date => date instanceof Date); } //Project B function callee(date, checkInstanceOf) { // Returns True return checkInstanceOf(date); } |
शेयर नहीं किए गए संसाधनों को लाइब्रेरी में भेजना एडजस्ट करें
शेयर नहीं किए गए संसाधन को मुख्य स्क्रिप्ट से लाइब्रेरी में पास करने का तरीका V8 रनटाइम में अलग तरह से काम करता है.
Rhino रनटाइम में, शेयर नहीं किए गए संसाधन को पास करने से काम नहीं होगा. इसके बजाय, लाइब्रेरी अपने संसाधन का इस्तेमाल करती है.
V8 रनटाइम में, शेयर नहीं किए गए संसाधन को लाइब्रेरी में पास किया जाता है. लाइब्रेरी, पास किए गए ऐसे संसाधन का इस्तेमाल करती है जो शेयर नहीं किया गया है.
शेयर नहीं किए गए संसाधनों को फ़ंक्शन पैरामीटर के तौर पर पास न करें. शेयर नहीं किए गए संसाधनों को हमेशा उसी स्क्रिप्ट में बताएं जो उनका इस्तेमाल करती है.
प्रोजेक्ट A और प्रोजेक्ट B का इस्तेमाल करें, जहां प्रोजेक्ट A का इस्तेमाल लाइब्रेरी के तौर पर किया जाता है. इस उदाहरण में, PropertiesService एक शेयर नहीं किया गया संसाधन है.
// Rhino runtime // Project A function testPassingNonSharedProperties() { PropertiesService.getScriptProperties() .setProperty('project', 'Project-A'); B.setScriptProperties(); // Prints: Project-B Logger.log(B.getScriptProperties( PropertiesService, 'project')); } |
// V8 runtime // Project A function testPassingNonSharedProperties() { PropertiesService.getScriptProperties() .setProperty('project', 'Project-A'); B.setScriptProperties(); // Prints: Project-A Logger.log(B.getScriptProperties( PropertiesService, 'project')); } |
स्टैंडअलोन स्क्रिप्ट का ऐक्सेस अपडेट करें
V8 रनटाइम पर चल रही स्टैंडअलोन स्क्रिप्ट के लिए, आपको कम से कम उपयोगकर्ताओं के लिए जानकारी देनी होगी ताकि स्क्रिप्ट के ट्रिगर ठीक से काम कर सकें, इसके लिए स्क्रिप्ट का ऐक्सेस देखें.