प्रतिनिधि इंटरव्यू विषय

फ़्रंटएंड इंटरव्यू: आपको CSS @property के साथ कस्टम प्रॉपर्टी कब रजिस्टर करनी चाहिए?

फ्रंटएंडमध्यम
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक कंपोनेंट लाइब्रेरी में एनिमेट करने योग्य रंग और आकार के वेरिएबल्स हैं। सामान्य CSS वेरिएबल्स बनाम @property की व्याख्या करें, फिर सुरक्षित रजिस्ट्रेशन, इनहेरिटेंस, फ़ॉलबैक और कम्पैटिबिलिटी नियम डिज़ाइन करें।

प्रॉम्प्ट और संदर्भ

एक कंपोनेंट लाइब्रेरी --accent, --progress और --card-size जैसी कस्टम प्रॉपर्टीज़ का उपयोग करती है। डिज़ाइन आवश्यकताओं में स्मूथ ट्रांज़िशन की आवश्यकता है, लेकिन वेरिएबल्स अनटाइप्ड स्ट्रिंग्स हैं, अमान्य मान चुपचाप आगे बढ़ जाते हैं, और चाइल्ड कंपोनेंट्स अनजाने में थीम मान इनहेरिट कर लेते हैं। डिफ़ॉल्ट, अमान्य मान, इनहेरिटेंस और ब्राउज़र कम्पैटिबिलिटी सहित समझाएं कि उन्हें CSS @property के साथ कब रजिस्टर करना चाहिए।

यह फ़्रंटएंड, डिज़ाइन-सिस्टम और वेब-परफ़ॉर्मेंस इंटरव्यू के लिए उपयुक्त है। परीक्षण हर वेरिएबल को रजिस्टर करने का नहीं, बल्कि CSS Properties and Values API की सीमाओं को समझने का है। सिंटैक्स, प्रारंभिक मान, इनहेरिटेंस, इंटरपोलेशन, स्कोप, प्रोग्रेसिव एन्हांसमेंट और परीक्षणों को कवर करें।

इंटरव्यूअर क्या जांच रहा है

एक मजबूत उत्तर बताता है कि सामान्य कस्टम प्रॉपर्टीज़ स्ट्रिंग्स के रूप में कंप्यूट होती हैं और डिफ़ॉल्ट रूप से इनहेरिट होती हैं; रजिस्टर्ड प्रॉपर्टीज़ एक प्रकार, प्रारंभिक मान और इनहेरिटेंस व्यवहार घोषित करती हैं, और कंप्यूटेड-वैल्यू समय (computed-value time) पर अमान्य मानों की जांच की जाती है। समझाएं कि syntax और inherits आवश्यक डिस्क्रिप्टर हैं, गैर-सार्वभौमिक सिंटैक्स को सामान्यतः एक कम्प्यूटेशनल रूप से स्वतंत्र initial-value की आवश्यकता होती है, और कब एनिमेशन, टाइप प्रतिबंध और नॉन-इनहेरिटेड कंपोनेंट स्थिति रजिस्ट्रेशन को उचित ठहराते हैं। @property को जावास्क्रिप्ट स्थिति या स्वचालित प्रदर्शन गारंटी के रूप में प्रस्तुत न करें।

पहले स्पष्ट करने योग्य प्रश्न

  • वेरिएबल किस प्रकार का मान रखता है: रंग (color), लंबाई (length), कोण (angle), संख्या (number), या एक ओपन टोकन स्ट्रिंग?
  • क्या इसे स्मूथ इंटरपोलेशन की आवश्यकता है, या केवल एक असतत (discrete) थीम स्वैप की?
  • क्या इसे चिल्ड्रेन में इनहेरिट होना चाहिए, या कंपोनेंट सीमा को इसे अलग (isolate) रखना चाहिए?
  • किसी अमान्य मान पर, क्या परिणाम प्रारंभिक मान, इनहेरिटेड मान, या कोई घोषणा नहीं (no declaration) होना चाहिए?
  • ब्राउज़र लक्ष्य, सर्वर-रेंडरिंग पाथ, फ़ॉलबैक और डिज़ाइन-टोकन रिलीज़ प्रक्रिया क्या हैं?

30-सेकंड का उत्तर

“सामान्य कस्टम प्रॉपर्टीज़ इनहेरिट होने वाली स्ट्रिंग्स हैं और ओपन टोकन के लिए अच्छा काम करती हैं। मैं किसी प्रॉपर्टी को तब रजिस्टर करूंगा जब उसे टाइप चेकिंग, नॉन-इनहेरिटेड डिफ़ॉल्ट या स्मूथ इंटरपोलेशन की आवश्यकता हो। रजिस्ट्रेशन में syntax, inherits और एक कम्प्यूटेशनल रूप से स्वतंत्र initial-value निर्दिष्ट होना चाहिए, जिससे अमान्य असाइनमेंट पूर्वानुमेय बन सकें। पुराने ब्राउज़र सामान्य वेरिएबल को फ़ॉलबैक के रूप में रखते हैं, और कंपोनेंट परीक्षण इनहेरिटेंस, अमान्य मान, एनिमेशन और थीम परिवर्तनों को कवर करते हैं; रजिस्ट्रेशन को अपने आप में तेज़ नहीं माना जाता है।”

चरण-दर-चरण उत्तर

चरण 1: सामान्य वेरिएबल्स को रजिस्टर्ड प्रॉपर्टीज़ से अलग करें

एक सामान्य --name कैस्केड में भाग लेता है और डिफ़ॉल्ट रूप से इनहेरिट होता है; ब्राउज़र इसके मान को टोकन अनुक्रम के रूप में मानता है। यह रंगों, स्पेसिंग टोकन और ओपन कंपोज़िशन के लिए उपयोगी है, लेकिन ब्राउज़र को यह नहीं पता होता कि मान रंग होना चाहिए या लंबाई। @property उसी वेरिएबल में टाइप, इनहेरिटेंस और डिफ़ॉल्ट-वैल्यू मेटाडेटा जोड़ता है।

चरण 2: एक स्पष्ट सिंटैक्स चुनें

केवल उन्हीं मानों को रजिस्टर करें जिन्हें प्रतिबंधों या इंटरपोलेशन की आवश्यकता है। मिलान करने वाले मानों के लिए CSS रंग, संख्या और कोण सिंटैक्स प्रकारों का उपयोग करें। केवल सख्त दिखने के लिए मल्टी-टोकन प्रयोगात्मक मान को किसी एक प्रकार में बाध्य न करें; ऐसा करने पर मान्य थीम मान भी खारिज हो जाएंगे।

चरण 3: inherits और initial-value सेट करें

inherits को स्पष्ट करें। एक थीम रंग आमतौर पर इनहेरिट होता है; एक आंतरिक कंपोनेंट आकार या एनिमेशन प्रगति इनहेरिट नहीं हो सकती है। गैर-सार्वभौमिक सिंटैक्स के लिए कम्प्यूटेशनल रूप से स्वतंत्र initial-value की आवश्यकता होती है, जैसे पैरेंट पर निर्भर प्रतिशत के बजाय एक निश्चित इकाई। आवश्यक डिस्क्रिप्टर गायब होने पर रजिस्ट्रेशन अमान्य हो जाता है।

चरण 4: अमान्य मानों और फ़ॉलबैक को समझें

रजिस्टर्ड प्रॉपर्टीज़ कंप्यूटेड-वैल्यू समय पर मान्य (validate) होती हैं। गलत प्रकार वाला मान लागू नहीं होता है और प्रॉपर्टी inherits और घोषणा स्थान के आधार पर अपने रजिस्टर्ड प्रारंभिक मान, इनहेरिटेंस, या किसी अन्य मान्य कैस्केड परिणाम के माध्यम से हल होती है। initial, inherit, unset और revert जैसे ग्लोबल कीवर्ड्स के अभी भी विशेष सिमेंटिक्स हैं और उनके लिए अलग परीक्षणों की आवश्यकता है।

चरण 5: इंटरपोलेबल एनिमेशन का उपयोग करें

अन-रजिस्टर्ड कस्टम प्रॉपर्टीज़ आमतौर पर असतत (discretely) रूप से बदलती हैं क्योंकि ब्राउज़र मनमानी स्ट्रिंग्स को इंटरपोलेट नहीं कर सकता है। एक बार रंग, लंबाई या संख्या के रूप में रजिस्टर होने के बाद, ब्राउज़र जानता है कि ग्रेडिएंट, प्रगति और रोटेशन को कैसे इंटरपोलेट किया जाए। फिर भी अवधि, कंपोज़िटिंग, रिड्यूस्ड-मोशन व्यवहार और कई तत्वों को अपडेट करने की वास्तविक लागत का परीक्षण करें।

चरण 6: कंपोनेंट सीमाओं को नियंत्रित करें

ग्लोबल थीम टोकन्स को आंतरिक स्थिति से अलग नाम दें। इनहेरिट होने वाले मान थीम के लिए उपयोगी होते हैं; एक नॉन-इनहेरिटेड प्रॉपर्टी एक कंपोनेंट को अपने स्वयं के प्रारंभिक मान का उपयोग करने देती है और पैरेंट के समान नाम वाले वेरिएबल को आंतरिक एनिमेशन को दूषित करने से रोकती है। यदि कोई प्रॉपर्टी शैडो DOM या कंटेनर सीमाओं को पार करती है, तो उसे रजिस्टर करने का निर्णय लेने से पहले नेमस्पेस और सार्वजनिक API को परिभाषित करें।

चरण 7: प्रोग्रेसिव एन्हांसमेंट प्रदान करें

पहले एक सामान्य कस्टम प्रॉपर्टी और एक स्थिर अंतिम स्थिति भेजें, ताकि @property के बिना वाले ब्राउज़र भी उपयोग योग्य UI रेंडर कर सकें। समर्थित ब्राउज़र टाइप प्रतिबंध और इंटरपोलेशन जोड़ सकते हैं। महत्वपूर्ण लेआउट को केवल रजिस्ट्रेशन पर निर्भर न बनाएं; एन्हांसमेंट पाथ का चयन करते समय @supports (property: --x) या क्षमता पहचान (capability detection) का उपयोग करें।

चरण 8: त्रुटियों और ब्राउज़र व्यवहार को सत्यापित करें

मान्य मान, गलत प्रकार, छूटे हुए प्रारंभिक मान, इनहेरिटेंस टॉगल, थीम ओवरराइड, मिड-एनिमेशन अपडेट और सर्वर-रेंडर किए गए फ़र्स्ट पेंट का परीक्षण करें। पुराने ब्राउज़र, डेवलपर टूल्स में कंप्यूटेड मान और विज़ुअल रिग्रेशन की जांच करें। MDN नोट करता है कि रजिस्ट्रेशन कंप्यूटेड-वैल्यू समय पर मान्य होता है और एक विकृत नियम को पूरी तरह से अनदेखा किया जा सकता है, इसलिए बिल्ड जांच और रनटाइम उदाहरण दोनों मायने रखते हैं।

समझौते और सीमाएं

रजिस्ट्रेशन से घोषणा और डिज़ाइन-टोकन रखरखाव लागत बढ़ जाती है, और API से अपरिचित योगदानकर्ता यह मान सकते हैं कि हर मान स्वतंत्र रूप से प्रतिस्थापन योग्य बना रहता है। स्पष्ट प्रकार, एनिमेशन आवश्यकता, डिफ़ॉल्ट या इनहेरिटेंस सीमा वाले मानों को रजिस्टर करें; ओपन-एंडेड कंटेंट टोकन्स को सामान्य कस्टम प्रॉपर्टीज़ के रूप में रखें।

टाइप चेकिंग कोई सुरक्षा सीमा या क्रॉस-ब्राउज़र स्थिरता की गारंटी नहीं है। समर्थन, पार्सिंग समय और एनिमेशन कंपोज़िटिंग के लिए अभी भी लक्ष्य मैट्रिक्स का परीक्षण किया जाना आवश्यक है। महत्वपूर्ण एक्सेसिबिलिटी स्थितियों के लिए स्थिर शैलियों और एक रिड्यूस्ड-मोशन पाथ की आवश्यकता होती है।

रोलआउट योजना और प्रमाण

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

प्रत्येक syntax या inherits परिवर्तन को व्यवहार परिवर्तन के रूप में मानें और चाइल्ड ओवरराइड, थीम स्विचिंग और स्थायी स्नैपशॉट का निरीक्षण करें। यदि उपयोगकर्ता रंग में झटके या आकार के फ़ॉलबैक की रिपोर्ट करते हैं, तो एनिमेशन अवधि बदलने से पहले कंप्यूटेड मानों और क्षमता पथों का निरीक्षण करें।

सामान्य गलतियाँ और अनुवर्ती प्रश्न

हर CSS वेरिएबल को रजिस्टर करना

ओपन टोकन, समग्र मान (composite values) और प्रयोगात्मक स्ट्रिंग्स का स्थिर सिंटैक्स नहीं हो सकता है। केवल उन्हीं मानों को रजिस्टर करें जिन्हें प्रकार, डिफ़ॉल्ट, इनहेरिटेंस नियंत्रण या इंटरपोलेशन की आवश्यकता है।

initial-value की कम्प्यूटेशनल स्वतंत्रता को भूलना

गैर-सार्वभौमिक सिंटैक्स के लिए, प्रारंभिक मान संदर्भ पर निर्भर नहीं हो सकता है। प्रतिशत या em रजिस्ट्रेशन को अमान्य कर सकता है; कम्प्यूटेशनल रूप से स्वतंत्र इकाई का उपयोग करें या सार्वभौमिक सिंटैक्स के साथ कमजोर प्रतिबंधों को स्वीकार करें।

यह मानना कि अमान्य मान पिछली मान्य घोषणा को बनाए रखते हैं

रजिस्टर्ड प्रॉपर्टीज़ कंप्यूटेड-वैल्यू समय पर मान्य होती हैं। एक अमान्य असाइनमेंट पुराने निकटवर्ती मान के बजाय प्रारंभिक या इनहेरिटेड परिणाम में हल हो सकता है। केवल सोर्स क्रम ही नहीं, कंप्यूटेड शैलियों का परीक्षण करें।

inherits को पूर्ण कैस्केड अलगाव मानना

inherits: false डिफ़ॉल्ट इनहेरिटेंस को नियंत्रित करता है; ऑथर्स अभी भी inherit लिख सकते हैं, और दूसरा टोकन पैरेंट मान को कंपोनेंट में ले जा सकता है। नामकरण, दस्तावेज़ीकरण और परीक्षणों को मिलकर सीमा को लागू करना चाहिए।

आप @property के बिना वाले ब्राउज़रों का समर्थन कैसे करते हैं?

एक स्थिर अंतिम स्थिति और समझदार डिफ़ॉल्ट के साथ एक सामान्य वेरिएबल रखें, फिर एन्हांसमेंट के रूप में रजिस्ट्रेशन और एनिमेशन जोड़ें। क्रिटिकल पाथ्स के लिए @supports या क्षमता पहचान का उपयोग करें और लक्ष्य ब्राउज़र मैट्रिक्स में फ़र्स्ट पेंट, थीम और रिड्यूस्ड मोशन का परीक्षण करें।

सार्वजनिक स्रोत

संबंधित प्रश्न