वर्कफ़्लो में कस्टम सीएसएस और जेएस से अलग विक्रेता सीएसएस और जेएस क्यों?

Question

मैं कस्टम जेएस & सीएसएस से विक्रेता जेएस & सीएसएस को अलग करने के फ्रंट एंड वर्कफ़्लोज़ में मानक अभ्यास बनने के पीछे तर्क निर्धारित करने का प्रयास कर रहा हूं। मुझे यकीन नहीं है कि अतिरिक्त HTTP अनुरोध के नुकसान के लाभ क्या हैं, यह केवल एक सीएसएस & जेएस फ़ाइल को विक्रेता.css, main.css & vendor.js, main.js. के बजाय क्लीनर प्रतीत होता है।

क्या कोई इस पर कुछ प्रकाश डाल सकता है?

Answer 1

विक्रेता कोड आमतौर पर आपके एप्लिकेशन के कोड से कम बार-बार बदलता है। इस प्रकार जब आप अपना आवेदन अपडेट करते हैं, तो विक्रेता कोड अपरिवर्तित और आपके उपयोगकर्ता के ब्राउज़र में कैश किया जा सकता है।

परिदृश्य में जहां विक्रेता कोड को एप्लिकेशन कोड के साथ बंडल किया गया है, उपयोगकर्ता को एप्लिकेशन अपडेट करने पर हर बार विक्रेता कोड डाउनलोड करना होगा।

अलग विक्रेता बंडल से अतिरिक्त HTTP अनुरोध इस तथ्य से कम हो गया है कि उपयोगकर्ता प्रत्येक एप्लिकेशन अपडेट पर कम कोड डाउनलोड करेगा।

Answer 2

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

Answer 3

मैं दो कारणों से सोच सकता हूं।

1. अपने कोड चिंताओं में से (जैसे Google Hosted Libraries)
2. पृथक्करण से अलग विक्रेता कोड होस्टिंग: विक्रेता कोड बड़े हो सकता है और अपने कस्टम कोड की स्वतंत्र रूप से अद्यतन किया जाता है। एक अलग फ़ाइल में अपना कोड बनाए रखने से विक्रेता कोड को आपके स्रोत नियंत्रण में रखने की आवश्यकता से बचा जाता है, जिससे आपके कोड को नेविगेट करना आसान हो जाता है, जिससे नए विक्रेता कोड में अपग्रेड करना आसान हो जाता है क्योंकि आप जानते हैं कि विक्रेता कोड को tweaked नहीं किया गया है।

आप grunt साथ सवाल में चिह्नित खासकर के बाद से, अंत उपयोगकर्ता कभी नहीं इस परिवर्तन देख सकते हैं क्योंकि आप निर्माण के दौरान विक्रेता और उपयोगकर्ता शैलियों/लिपियों विलय कर सकते हैं।

हालांकि, यदि विक्रेता कोड बड़ा है और बार-बार बदलता है, तो आपको एक छोटी, तेजी से बदलती कस्टम कोड फ़ाइल के साथ शायद ही कभी बदलती, बड़ी विक्रेता फ़ाइल होने से कैशिंग लाभ मिलता है। बड़ी साइटों के लिए जो सीडीएन का उपयोग नहीं करते हैं (उम्मीद है कि, आपका नहीं), प्रभाव ध्यान देने योग्य हो सकता है।

Answer 4

विभिन्न जवाब पहले से ही इस संबोधित लेकिन मुझे यह बहुत विशिष्ट बनाती हूँ:

1. विक्रेता कोड अपने कोड से अधिक या कम बार बदल सकता है। यदि विक्रेता कोड अधिक बार बदलता है, उदा। बग फिक्स के लिए, आप नए संस्करणों का उपयोग करना चाहते हैं और एक बेहतर समग्र वेबसाइट चाहते हैं। यदि विक्रेता कोड आपके कोड से अक्सर कम होता है, तो आप अपने कोड w/o को काम करने वाली सामग्री को स्पर्श करने के लिए की इच्छा कर सकते हैं।

2. विक्रेता कोड अक्सर CDNs पर होस्ट की है, उदाहरण के https://cdnjs.com/#q=ajax या https://developers.google.com/speed/libraries/ के लिए ये फास्ट लोड हो रहा है कर रहे हैं।वे भी बदल नहीं पाएंगे, इसलिए उपयोगकर्ता फ़ाइलों पर भरोसा कर सकता है और इस प्रकार आपकी वेबसाइट तेज़ी से लोड हो जाएगी।

3. कोड में पुनरावृत्त परिवर्तन करना आम तौर पर बेहतर होता है। कोड को प्रबंधित करना भी आसान है, स्रोत नियंत्रण के साथ esp जब विशिष्ट चीजें बदल रही हैं। नहीं होने पर बड़ी फ़ाइलों को स्वैप करने की आवश्यकता नहीं है। चीजों को अलग रखने से वृद्धिशील परिवर्तन करना आसान हो जाता है, अगर दो चीजों में अलग-अलग परिवर्तन होते हैं तो वेग।