10 PostCSS प्लगइन्स जो आपके लेआउट समय को बचाएंगे

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

प्रचार लहर लंबे समय से गुजर रही है, हाल के वर्षों में PostCSS के बारे में बहुत कम कहा गया है। कई शुरुआती लोगों को यह भी पता नहीं है कि यह क्या है। मुझे लगता है कि इस उपकरण को सबसे साधारण परियोजनाओं में व्यावहारिक उपयोग के दृष्टिकोण से देखने का समय है, जहां लोग फैशनेबल प्रौद्योगिकियों के साथ खेलने के बजाय समस्याओं को हल करते हैं।

PostCSS बनाम SASS

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

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

लेकिन अगर हम इन तुलनाओं को छोड़ देते हैं, तो PostCSS एक उपकरण है जो हमें हमारे CSS को लेने और इसके साथ कुछ करने की अनुमति देता है। कोई भी वाक्य रचना के लिए SASS का उपयोग करने के लिए परेशान नहीं करता है, और विधानसभा के बाद, PostCSS को चिपकाएं और परिणाम के साथ कुछ करें। वे एक-दूसरे का खंडन नहीं करते हैं।

पुराने का मतलब बेकार नहीं है

हाल ही में, हमारे लिए यह संयोजन बनाने के लिए फैशनेबल रहा है कि वह सब कुछ कर सकता है जो केवल दिमाग में आता है, और उनका विकास कभी भी नहीं रुकता है। और अगर कुछ महीनों के लिए रिपॉजिटरी में कोई ताजा कमिट नहीं हैं, तो सब कुछ - हम यह मान सकते हैं कि यह पुराना है और अब इसका इस्तेमाल करते हैं - आईएल फेट नहीं। मैं अतिशयोक्ति करूंगा, निश्चित रूप से, लेकिन मुझे लगता है कि आपने खुद देखा कि यह कभी-कभी कितना बेतुका है।

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

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

नंबर 1। Doiuse

https://github.com/anandthakker/doiuse

मुझे लगता है कि हम सभी को इस समस्या का सामना करना पड़ा: आप कोड लिखते हैं, क्रोम में जांचते हैं - सब कुछ ठीक है। आप एफएफ में जांच करते हैं - लगभग। और फिर मोबाइल सफारी में सब कुछ बिखर जाता है। या एज में। और आप बैठते हैं और यह नहीं समझते कि क्या गलत है। फिर आप एक लंबे समय के लिए कोड को घूरते हैं, चाय पीते हैं, और अचानक एक अंतर्दृष्टि आती है कि कुछ ब्राउज़र में कुछ संपत्ति समर्थित नहीं है। आप कैनिअस पर जाते हैं और आप स्पष्ट की पुष्टि देखते हैं।

बेशक, अनुभव के साथ, हाथ खुद याद करते हैं कि क्या गुणों से बचा जाना चाहिए, लेकिन कुछ भी होता है। आप पर्याप्त नींद नहीं ले सकते, तंग समय सीमा और तंत्रिकाएं हो सकती हैं, ब्राउज़रों की सूची जिसे बदलने की आवश्यकता है बदल सकती है। और तब अनुभव असफल होने लगेगा। Doiuse एक उपकरण है जो ऐसी स्थितियों में बहुत मदद करता है।

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

हम सीधे पैकेज.जॉसन में ब्राउज़रों की सूची सेट कर सकते हैं। सरल और सुविधाजनक। PostCSS ब्राउज़र सूची का उपयोग करता है और, यदि आपने इसे पहले नहीं देखा है, तो यह कुछ इस तरह दिखता है:

"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ] 

स्वयं doiuse का एक विन्यास भी है, जिसमें आप इसे कुछ संपत्ति समूहों को अनदेखा करने के लिए मजबूर कर सकते हैं यदि आप सुनिश्चित हैं कि यह कुछ भी प्रभावित नहीं करता है। उदाहरण के लिए, यदि आप पॉलीफ़ाइल्स का उपयोग करते हैं या कुछ संपत्ति के समर्थन के नुकसान से, तो कुछ भी नहीं बदलेगा:

 ignore: [ 'will-change', 'object-fit' ] 

प्लगइन द्वारा प्रदान किया गया मानक लॉग बहुत पठनीय नहीं है। इसमें बहुत सारी जानकारी शामिल है और इसे समझना बहुत सुविधाजनक नहीं है। लेकिन यह निश्चित है। उसी कॉन्फ़िगरेशन में, हम लॉग बनाने के लिए अपना कार्य कर सकते हैं।

कंसोल का उपयोग करें। यह पता लगाने के लिए कि इस फ़ंक्शन में पोस्टसीएसएस को पारित करने वाली वस्तु कैसे काम करती है। कई दिलचस्प बातें हैं।

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

 onFeatureUsage(info) { const selector = info.usage.parent.selector; const property = `${info.usage.prop}: ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`); } 

कंसोल में रंगों के लिए वर्णों के विशेष अनुक्रम नहीं लिखने के लिए, आप रंगों के पैकेज को कनेक्ट कर सकते हैं, यह इसके साथ अधिक सुविधाजनक होगा।

निर्माण करते समय, कंसोल में ऐसा कुछ होगा:

 NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; } 

नंबर 2। Autoprefixer

https://github.com/postcss/autoprefixer

उसके बारे में बात करना और भी शर्मनाक है, लेकिन अक्सर मैं ऐसे लोगों को देखता हूं जो 2019 में अपने हाथों से उपसर्ग लिखते हैं और फिर भी दूसरों को आश्वस्त करते हैं कि वे वास्तव में जानते हैं कि किन लोगों की जरूरत है और जो नहीं हैं। इस तरह की कार्रवाइयाँ इस तथ्य को जन्म देती हैं कि कोड अनावश्यक उपसर्गों के एक समूह के साथ उखाड़ फेंका जाता है और पूरी तरह से अपठनीय हो जाता है। इससे श्रम उत्पादकता प्रभावित होती है। दूसरी ओर, यदि आपको डायनासोर के समर्थन की आवश्यकता है, तो आप हमेशा कुछ भूल सकते हैं। इसलिए इस समस्या को हल करते समय यह मैनुअल श्रम से छुटकारा पाने के लायक है।

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

नंबर 3। Stylelint

https://github.com/stylelint/stylelint

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

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

नंबर 4। Postcss-flexbugs-फिक्स

https://github.com/luisrudge/postcss-flexbugs-fixes

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

कैल्क उदाहरण में, यह कोड में इस तरह के टुकड़े पाएंगे:

 .foo { flex: 1 0 calc(1vw – 1px); } 

और उन्हें तैनात करें:

 .foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); } 

सरल और सुविधाजनक।

नंबर 5। Postcss-पूर्व निर्धारित-env

https://github.com/csstools/postcss-preset-env

चूंकि हम ब्राउज़र समर्थन के बारे में बात कर रहे हैं, इसलिए यह पोस्टस्कैट-प्रीसेट-एनवी के बारे में कहने के लिए जगह से बाहर नहीं होगा। इससे पहले, cssnext ने एक ही भूमिका निभाई थी। यदि आप CSS में नए रुझानों में रुचि रखते हैं तो यह प्लगइन उपयोगी होगा।

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

जैसा कि आप साधन के नाम से अनुमान लगा सकते हैं, यह बबेल के समान नाम प्रीसेट जैसा दिखता है। यहां, सब कुछ समान है - एक स्थिर सेट में कई कन्वर्टर्स इकट्ठे होते हैं। कुछ परिवर्तनों को क्लाइंट पर पॉलीफाइल स्क्रिप्ट के बाद के कनेक्शन की आवश्यकता होती है, लेकिन अधिकांश को सीएसएस द्वारा पूरी तरह से लागू किया जाता है। जहां तक ​​मैं समझता हूं, स्टेज 2 के लिए + स्क्रिप्ट की जरूरत नहीं है। किसी भी मामले में, मैं उनकी जरूरत पर नहीं आया। अगर मुझे वहां कुछ याद आ गया तो मुझे सुधारो।

नंबर 6। Postcss-एनीमेशन

https://github.com/zhouwenbin/postcss-animation

अक्सर मैं अलग-अलग लोगों से सुनता हूं (ज्यादातर बैकएंड जो CSS में बहुत मजबूत नहीं हैं) कि वे animate.css से अलग एनिमेशन का उपयोग करना चाहते हैं, लेकिन इसे पूरे पुस्तकालय को जोड़ने के लिए एक बुरा विचार मानते हैं। यह काफी तार्किक है। लेकिन परिणामस्वरूप, वे इन एनिमेशनों को अपने दम पर दोहराने की कोशिश में बहुत समय बिताते हैं।

Postcss- एनीमेशन प्लगइन इस प्रक्रिया को बहुत तेज करता है। हम उदाहरण के लिए केवल एनीमेशन का नाम लिखते हैं:

 .foo { animation-name: bounce; } 

और वह animate.css से कार्यान्वयन को खींचता है और इसे कोड में सम्मिलित करता है।

 .foo { animation-name: bounce; } @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); } } 

अंक 7। सूची-चयनकर्ताओं

https://github.com/davidtheclark/list-selectors

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

Doiuse की तरह, यह प्लगइन आपको प्रदर्शन के लिए जानकारी तैयार करने के लिए इसके फ़ंक्शन का उपयोग करने की अनुमति देता है। आप केवल वही दिखा सकते हैं जो आपकी रुचि है, या सब कुछ अलग-अलग रंगों में पेंट करें। एक उदाहरण के रूप में:

 require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red); }) 

यह उदाहरण चयनकर्ताओं की एक लंबी, लंबी सूची तैयार करता है:

 SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . . ', SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . . 

अंक 8। अपरिवर्तनीय-सीएसएस

https://github.com/johno/immutable-css

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

सामान्य तौर पर, इसके काम का सिद्धांत सरल है: यह शैलियों के साथ फाइल लेता है, अगर यह चयनकर्ताओं पर मिलान पाता है, तो यह महत्वहीन होने लगता है:

 ! .button was mutated 2 times [line 93, col 1]: /css/basscss.css [line 3, col 1]: /css/custom.css [immutable-css] ! .left was mutated 2 times [line 291, col 1]: /css/basscss.css [line 4, col 1]: /css/custom.css [immutable-css] 

इस उपकरण के साथ एकमात्र समस्या यह है कि यह गैर-सीएसएस सिंटैक्स का समर्थन नहीं करता है। इसलिए यदि प्रोजेक्ट में प्रीप्रोसेसरों का उपयोग किया जाता है, तो पहले से ही इकट्ठी फाइलों की तुलना की जानी चाहिए। लेकिन सामान्य तौर पर, यदि कार्य केवल यह सुनिश्चित करने के लिए है कि कोई भी गलती से तीसरे पक्ष के पुस्तकालय से शैलियों को फिर से नहीं लिखता है, तो यह इतना महत्वपूर्ण नहीं है।

नंबर 9। उप-बाय!

https://github.com/AoDev/css-byebye

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

इस मुद्दे पर अलग-अलग दृष्टिकोण हैं। अनकन्स तुरंत दिमाग में आ जाता है । यह उपकरण स्वचालित रूप से पता लगाता है कि कौन सी शैलियों का उपयोग पृष्ठों पर किया जाता है और अनावश्यक को हटा देता है। लेकिन व्यवहार में, यह लगभग हमेशा इस तथ्य की ओर जाता है कि कोई नहीं जानता कि वास्तव में क्या उपयोग किया जा रहा है और क्या नहीं है। मुझे हर समय यह भी संदेह रहता है कि क्या इस उपकरण ने कुछ भी नहीं किया है। लेकिन यह शायद मेरा व्यामोह है। हालांकि ...

बाय-बाय एक सरल उपकरण है, जिसे हम स्वयं CSS से हटाने के लिए चयनकर्ताओं की एक सूची खिलाते हैं। और आप नियमित अभिव्यक्ति का उपयोग कर सकते हैं। यदि आप बीईएम या कुछ और का उपयोग करते हैं, तो एक साधारण नियमित के साथ आप उस चीज से एक ब्लॉक को हटा सकते हैं जो उससे संबंधित है। अलविदा अलविदा!

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

नंबर 10। PostCSS-trolling

https://github.com/juanfran/postcss-trolling

पिछले सभी उपकरण आपके लेआउट डिजाइनरों की उत्पादकता को थोड़ा बढ़ा सकते हैं, लेकिन यह केवल अभूतपूर्व परिणाम देता है। मैं इसकी अत्यधिक अनुशंसा करता हूं।

निष्कर्ष

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