फ़्रेमवर्क का पालन

JavaScript फ़्रेमवर्क के ईकोसिस्टम के मुताबिक होना

Shubhie Panicker

Houssein Djirdeh

शुरुआती ब्लॉग पोस्ट में, हमने बताया था कि Google Search, Maps, Photos वगैरह जैसे बड़े वेब ऐप्लिकेशन को डेवलप और मैनेज करने के लिए, फ़्रेमवर्क और टूल बनाते और इस्तेमाल करते समय हमने बहुत कुछ सीखा. हमने डेवलपर को ऐसा कोड लिखने से बचाया है जिससे उपयोगकर्ता अनुभव पर बुरा असर पड़ सकता है. इससे हमने यह साबित किया है कि फ़्रेमवर्क, ऐप्लिकेशन की परफ़ॉर्मेंस और क्वालिटी को बेहतर बनाने में अहम भूमिका निभा सकते हैं.

Google में, हमने इस तरीके के बारे में बताने के लिए "अनुपालन" शब्द का इस्तेमाल किया है. इस लेख में, हमने बताया है कि हम JavaScript फ़्रेमवर्क के लिए, इस कॉन्सेप्ट को ओपन-सोर्स कैसे करेंगे.

नियमों का पालन करना क्या है?

Google में, नियमों का पालन करना एक प्रोसेस थी. टीमें, अनुभवी डेवलपर के छोटे ग्रुप पर निर्भर थीं. ये डेवलपर, कोड की बारीकी से समीक्षा करते थे. साथ ही, वे उन चीज़ों को फ़्लैग करते थे जिनसे ऐप्लिकेशन की क्वालिटी और उसे मैनेज करने की सुविधा पर असर पड़ता था. ऐप्लिकेशन डेवलपर की बढ़ती टीमों के लिए, इसे बड़े पैमाने पर उपलब्ध कराने के लिए, एक नीति पालन सिस्टम बनाया गया. इससे, सबसे सही तरीकों को इस तरह से कोड में बदला जा सकता है कि वे अपने-आप लागू हों और उन्हें लागू किया जा सके. इससे, कोड में योगदान देने वाले लोगों की संख्या के बावजूद, ऐप्लिकेशन की क्वालिटी और कोडबेस को मैनेज करने की सुविधा को बेहतर बनाने में मदद मिली.

नीति का पालन करने की सुविधा से यह पक्का होता है कि डेवलपर सही दिशा में काम कर रहे हैं. इससे, डेवलपर का भरोसा बढ़ता है और उन्हें उम्मीद के मुताबिक नतीजे मिलते हैं. इससे टीमें ज़्यादा बेहतर तरीके से काम कर पाती हैं. साथ ही, यह स्केल के लिए भी ज़रूरी है, क्योंकि टीमें बढ़ती हैं और एक साथ कई सुविधाएं डेवलप की जाती हैं. इससे डेवलपर, प्रॉडक्ट की सुविधाओं को बेहतर बनाने पर ध्यान दे पाते हैं. साथ ही, उन्हें परफ़ॉर्मेंस, ऐक्सेस, सुरक्षा वगैरह जैसे अलग-अलग क्षेत्रों में होने वाले बदलावों और छोटी-मोटी बातों से भी छुटकारा मिलता है. कोई भी व्यक्ति, किसी भी समय 'अनुपालन' से ऑप्ट-आउट कर सकता है. साथ ही, इसे इस तरह से कस्टमाइज़ किया जाना चाहिए कि टीमों के पास, अपनी ज़रूरत के हिसाब से इसे लागू करने का विकल्प हो.

नीति का पालन करने के लिए, डिफ़ॉल्ट तौर पर लागू होने वाले सख्त नियम और कार्रवाई करने के लिए नियम दिए जाते हैं. इन नियमों को कॉन्टेंट लिखते समय लागू किया जा सकता है. इसे इन तीन सिद्धांतों में बांटा गया है.

ध्यान दें: इस लेख में, वेबसाइट के लोड होने में लगने वाले समय की अनुमानित परफ़ॉर्मेंस और वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के स्कोर को बेहतर बनाने के लिए, कोडिंग के सबसे सही तरीकों पर फ़ोकस किया गया है. हालांकि, ये सिद्धांत सुरक्षा, ऐक्सेस करने की सुविधा वगैरह जैसे दूसरे पहलुओं पर भी लागू होते हैं.

1. डिफ़ॉल्ट तौर पर लागू होने वाले सख्त नियम

नीति का पालन करने के लिए, यह पक्का करना ज़रूरी है कि डेवलपर के इस्तेमाल किए जाने वाले टूल में, डिफ़ॉल्ट तौर पर मज़बूत सेटिंग लागू हों. इसका मतलब है कि फ़्रेमवर्क में न सिर्फ़ समाधान मौजूद होते हैं, बल्कि फ़्रेमवर्क के डिज़ाइन पैटर्न की मदद से सही काम करना आसान हो जाता है और गलत काम करना मुश्किल हो जाता है. यह फ़्रेमवर्क, ऐप्लिकेशन के डिज़ाइन और कोड के स्ट्रक्चर में डेवलपर की मदद करता है.

पेज लोड होने की परफ़ॉर्मेंस को बेहतर बनाने के लिए, हर रिसॉर्स (फ़ॉन्ट, सीएसएस, JavaScript, इमेज वगैरह) को ऑप्टिमाइज़ किया जाना चाहिए. यह एक मुश्किल चुनौती है. इसमें बाइट को छोटा करना, राउंड ट्रिप को कम करना, और पहले रेंडर, विज़ुअल रेडीनेस, और उपयोगकर्ता इंटरैक्शन के लिए ज़रूरी चीज़ों को अलग करना शामिल है. उदाहरण के लिए, ज़रूरी सीएसएस को निकालना और ज़रूरी इमेज पर प्राथमिकता सेट करना.

2. कार्रवाई करने के लिए नियम

बुनियादी ऑप्टिमाइज़ेशन लागू होने के बाद भी, डेवलपर को विकल्प चुनने होते हैं. डेवलपर के इनपुट की ज़रूरत के हिसाब से, ऑप्टिमाइज़ेशन के कई विकल्प होते हैं:

• डिफ़ॉल्ट सेटिंग, जिनके लिए डेवलपर को कोई इनपुट नहीं देना पड़ता. जैसे, ज़रूरी सीएसएस को इनलाइन करना.
• डेवलपर को ऑप्ट-इन करना होगा. उदाहरण के लिए, इमेज का साइज़ और स्केल तय करने के लिए, फ़्रेमवर्क से मिले इमेज कॉम्पोनेंट का इस्तेमाल करना.
• डेवलपर के ऑप्ट-इन और पसंद के मुताबिक बनाने की ज़रूरत होती है. उदाहरण के लिए, ज़रूरी इमेज को टैग करना, ताकि वे जल्दी लोड हो सकें.
• कोई खास सुविधा नहीं, बल्कि ऐसी चीज़ें जिनके लिए डेवलपर को फ़ैसला लेना होता है. उदाहरण के लिए, ऐसे फ़ॉन्ट या सिंक्रोनस स्क्रिप्ट का इस्तेमाल न करना जिनकी वजह से पेज जल्दी रेंडर नहीं होता.

जिन ऑप्टिमाइज़ेशन के लिए डेवलपर को कोई फ़ैसला लेना पड़ता है उनसे ऐप्लिकेशन की परफ़ॉर्मेंस पर असर पड़ सकता है. सुविधाएं जोड़ने और टीम के बड़े होने के साथ-साथ, सबसे अनुभवी डेवलपर भी लगातार बदलते रहने वाले सबसे सही तरीकों को अपना नहीं पाते. साथ ही, यह उनके समय का सबसे सही इस्तेमाल भी नहीं है. नीति का पालन करने के लिए, ज़रूरी नियमों को लागू करना उतना ही ज़रूरी है जितना कि डिफ़ॉल्ट तौर पर लागू होने वाले नियमों को लागू करना. इससे यह पक्का होता है कि डेवलपर बदलाव करते रहे, फिर भी ऐप्लिकेशन किसी खास स्टैंडर्ड को पूरा करता रहे.

3. लेखन का समय

डेवलपमेंट लाइफ़साइकल की शुरुआत में ही, परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाना और उन्हें समस्या बनने से पहले रोकना ज़रूरी है. कोड को कमिट करने से पहले, कोड लिखने के दौरान ही समस्याओं का पता लगाया जा सकता है और उन्हें ठीक किया जा सकता है. डेवलपमेंट लाइफ़साइकल में किसी समस्या का पता जितनी देर बाद चलता है, उसे ठीक करना उतना ही मुश्किल और महंगा होता है. यह बात, कोड के सही होने से जुड़ी समस्याओं के साथ-साथ परफ़ॉर्मेंस से जुड़ी समस्याओं पर भी लागू होती है. ऐसा इसलिए है, क्योंकि कोडबेस में बदलाव करने के बाद, इनमें से कई समस्याओं को पहले की तरह ठीक नहीं किया जा सकेगा.

फ़िलहाल, परफ़ॉर्मेंस के ज़्यादातर सुझाव, दस्तावेज़ या एक बार के ऑडिट के ज़रिए मिलते हैं. इसके अलावा, प्रोडक्शन में डिप्लॉय करने के बाद, मेट्रिक में गिरावट आने पर भी ये सुझाव मिलते हैं. हम इसे लेख लिखने के समय उपलब्ध कराना चाहते हैं.

फ़्रेमवर्क के मुताबिक होना

लोडिंग की परफ़ॉर्मेंस के लिए, उपयोगकर्ता अनुभव को बेहतर बनाए रखने के लिए, इन सवालों के जवाब देने होंगे:

1. पेज को तेज़ी से लोड होने के लिए क्या ज़रूरी है और कौनसी सामान्य समस्याएं इस पर बुरा असर डाल सकती हैं?
2. कौनसे समाधान पहले से शामिल किए जा सकते हैं, जिनके लिए डेवलपर के इनपुट की ज़रूरत नहीं होती?
3. हम यह कैसे पक्का कर सकते हैं कि डेवलपर इन समाधानों का इस्तेमाल करे और उनका ज़्यादा से ज़्यादा फ़ायदा ले?
4. डेवलपर के पास कौनसे अन्य विकल्प हैं जिनसे लोडिंग की परफ़ॉर्मेंस पर असर पड़ सकता है?
5. कोड के कौनसे पैटर्न, एडिट करने के समय ही इन विकल्पों (#3 और #4) के बारे में बता सकते हैं?
6. इन कोड पैटर्न का आकलन करने के लिए, हम कौनसे नियम बना सकते हैं? डेवलपर को, लेखन के समय ये सुझाव कैसे दिखाए जा सकते हैं, ताकि उन्हें अपने वर्कफ़्लो में आसानी से इंटिग्रेट किया जा सके?

Google में हमारे पास, कॉन्फ़ॉर्मेंस मॉडल के लिए एक मॉडल है. इसे ओपन-सोर्स फ़्रेमवर्क के लिए उपलब्ध कराने के लिए, हमारी टीम ने Next.js में बहुत प्रयोग किए हैं. हमें अपने बेहतर विज़न और प्लान शेयर करते हुए खुशी हो रही है. हमें पता चला है कि कोड पैटर्न का आकलन करने वाले नियमों का सबसे अच्छा सेट, स्टैटिक कोड विश्लेषण और डाइनैमिक जांच का कॉम्बिनेशन होना चाहिए. ये नियम कई प्लैटफ़ॉर्म पर लागू हो सकते हैं. जैसे:

• ESLint
• TypeScript
• उपयोगकर्ता के डेवलपमेंट सर्वर में डाइनैमिक जांच (डीएम बनाने के बाद)
• मॉड्यूल बंडलर (webpack)
• सीएसएस टूल (अभी एक्सप्लोरेशन के तौर पर उपलब्ध है)

अलग-अलग टूल की मदद से नियमों का फ़ायदा उठाकर, हम यह पक्का कर सकते हैं कि वे एक साथ काम करते हों. साथ ही, उनमें उपयोगकर्ता अनुभव से जुड़ी ऐसी समस्याएं भी शामिल हों जिनका सीधे तौर पर लोडिंग की परफ़ॉर्मेंस पर असर पड़ता हो. इसके अलावा, डेवलपर को ये नियम अलग-अलग समय पर भी दिखाए जा सकते हैं:

• डेवलपमेंट सर्वर में लोकल डेवलपमेंट के दौरान, ब्राउज़र और उपयोगकर्ता के आईडीई में चेतावनियां दिखेंगी. इनसे डेवलपर को कोड में छोटे बदलाव करने के लिए कहा जाएगा.
• बिल्ड के समय, उपयोगकर्ता के टर्मिनल में, हल न हुई समस्याएं फिर से दिखेंगी

खास तौर पर, टीमें उन नतीजों को चुनें जिनमें उनकी दिलचस्पी है. जैसे, वेबसाइट की परफ़ॉर्मेंस या लोड होने में लगने वाला समय. साथ ही, कोड में योगदान देने वाले सभी लोगों के लिए, काम के नियमों को चालू करें.

यह नए प्रोजेक्ट के लिए बहुत अच्छा काम करता है. हालांकि, बड़े कोडबेस को पूरे नियमों का पालन करने के लिए अपग्रेड करना आसान नहीं है. Google के पास अलग-अलग लेवल पर ऑप्ट-आउट करने के लिए एक बड़ा सिस्टम है. जैसे, सोर्स कोड की अलग-अलग लाइनें, पूरी डायरेक्ट्री, लेगसी कोडबेस या ऐप्लिकेशन के ऐसे हिस्से जिन पर फ़िलहाल काम नहीं किया जा रहा है. हम ओपन-सोर्स फ़्रेमवर्क का इस्तेमाल करके, टीमों के लिए इस सुविधा को उपलब्ध कराने के लिए, असरदार रणनीतियों पर काम कर रहे हैं.

Next.js में स्टैंडर्ड प्रोसेस और तौर-तरीकों का पालन करना

JavaScript डेवलपर के बीच, ESLint का काफ़ी इस्तेमाल किया जाता है. साथ ही, 50% से ज़्यादा Next.js ऐप्लिकेशन, अपने बिल्ड वर्कफ़्लो के किसी हिस्से में ESLint का इस्तेमाल करते हैं. Next.js v11 में, पहले से मौजूद ESLint की सुविधा को शामिल किया गया है. इसमें कस्टम प्लग इन और शेयर किया जा सकने वाला कॉन्फ़िगरेशन शामिल है. इससे डेवलपमेंट और बिल्ड के समय, फ़्रेमवर्क से जुड़ी सामान्य समस्याओं को आसानी से पकड़ा जा सकता है. इससे डेवलपर को लेख लिखते समय, अहम समस्याओं को ठीक करने में मदद मिल सकती है. उदाहरण के लिए, जब किसी कॉम्पोनेंट का इस्तेमाल इस तरह से किया जाता है या नहीं किया जाता है जिससे परफ़ॉर्मेंस पर असर पड़ सकता है, जैसे कि पेज के लिए कोई एचटीएमएल लिंक नहीं है. इसके अलावा, अगर कोई फ़ॉन्ट, स्टाइलशीट या स्क्रिप्ट, पेज पर रिसॉर्स लोड होने पर बुरा असर डाल सकती है. उदाहरण के लिए, कोई सिंक्रोनस स्क्रिप्ट नहीं.

ESLint के अलावा, TypeScript की मदद से, Next.js के वर्शन 9 से, डेवलपमेंट और प्रोडक्शन, दोनों में टाइप-चेकिंग की सुविधा काम करती है. फ़्रेमवर्क से मिले कई कॉम्पोनेंट (इमेज, स्क्रिप्ट, लिंक), एचटीएमएल एलिमेंट (<img>, <script>, <a>) के एक्सटेंशन के तौर पर बनाए गए हैं. इससे डेवलपर को वेब पेज में कॉन्टेंट जोड़ने के लिए बेहतर तरीका मिलता है. टाइप की जांच करने से, इन सुविधाओं का सही तरीके से इस्तेमाल करने में मदद मिलती है. इससे यह पक्का किया जाता है कि असाइन की गई प्रॉपर्टी और विकल्प, काम करने वाली वैल्यू और टाइप के दायरे में हों. उदाहरण के लिए, इमेज की ज़रूरी चौड़ाई और ऊंचाई देखें.

टॉस्ट और ओवरले की मदद से गड़बड़ियों की जानकारी देना

जैसा कि हमने पहले बताया था, नियमों का पालन करने से जुड़े नियम कई जगहों पर दिखाए जा सकते हैं. फ़िलहाल, उपयोगकर्ता के स्थानीय डेवलपमेंट एनवायरमेंट में, ब्राउज़र में सीधे तौर पर गड़बड़ियां दिखाने के लिए, टॉस्ट और ओवरले का इस्तेमाल किया जा रहा है.

गड़बड़ी की जांच करने और ऑडिटिंग करने वाले कई टूल, डेवलपर के लिए काम के होते हैं. जैसे, Lighthouse, Chrome DevTools के 'समस्याएं' टैब. हालांकि, ये टूल ऐक्टिव नहीं होते और जानकारी पाने के लिए, उपयोगकर्ता के इंटरैक्शन की ज़रूरत होती है. डेवलपर, गड़बड़ियों को ठीक करने के लिए ज़्यादा काम करते हैं, जब उन्हें अपने मौजूदा टूल में गड़बड़ियां दिखती हैं. साथ ही, जब उन्हें समस्या को ठीक करने के लिए, साफ़ तौर पर बताई गई कार्रवाइयां मिलती हैं.

ध्यान दें: Next.js में, अब भी टॉस्ट और ओवरले का इस्तेमाल, यूज़र इंटरफ़ेस (यूआई) के तौर पर, नीति का पालन करने के लिए किया जा रहा है.

अन्य फ़्रेमवर्क के मुताबिक होना

फ़िलहाल, Next.js में इस सुविधा को एक्सप्लोर किया जा रहा है. इसका मकसद, इसे दूसरे फ़्रेमवर्क (Nuxt, Angular वगैरह) में भी उपलब्ध कराना है. ESLint और TypeScript का इस्तेमाल, कई फ़्रेमवर्क में पहले से ही कई अलग-अलग तरीकों से किया जा रहा है. हालांकि, ब्राउज़र-लेवल के रनटाइम सिस्टम के कॉन्सेप्ट को लगातार एक्सप्लोर किया जा रहा है.

नतीजा

Conformance, सबसे सही तरीकों को नियमों के ऐसे सेट में बदल देता है जिन्हें डेवलपर, आसान कोड पैटर्न के तौर पर इस्तेमाल कर सकते हैं. Aurora की टीम ने लोड करने की परफ़ॉर्मेंस पर फ़ोकस किया है. हालांकि, ऐक्सेस और सुरक्षा जैसे अन्य सबसे सही तरीके भी लागू किए जा सकते हैं.

नियमों का पालन करने से, आपको अनुमानित नतीजे मिल सकते हैं. साथ ही, टेक्नोलॉजी स्टैक को बेहतर बनाने से, उपयोगकर्ता अनुभव को बेहतर बनाने में मदद मिल सकती है. दिशा-निर्देशों का पालन करने से टीमें ज़्यादा काम कर पाती हैं. साथ ही, यह पक्का होता है कि समय के साथ टीमों और कोडबेस के बढ़ने के बावजूद, ऐप्लिकेशन की क्वालिटी अच्छी बनी रहे.