Less.js: "डिफ़ॉल्ट" चर के लिए समर्थन जोड़ें (एसएएसएस में डिफ़ॉल्ट के समान)

दस्तावेज़ीकरण देखें।

अद्यतन: भविष्य के आगंतुकों को भ्रमित न करने के लिए इस पोस्ट की मेरी पिछली टिप्पणी को हटा दिया (यहां मैं "एक चर को परिभाषित करने के लिए कैसे परिभाषित करें" प्रश्न का उत्तर देने का प्रयास कर रहा था और इस बिंदु को याद किया कि यह एक "XY समस्या" है और एक के लिए सही उत्तर है Sass-like !default है: कम में आपको ऐसा कुछ भी नहीं चाहिए क्योंकि आवश्यक कार्यक्षमता ("(पुनः) उपयोग के बाद परिभाषा") पहले से ही कम चर काम करने के तरीके से प्रदान की जाती है)।

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

पुस्तकालय.विहीन

<strong i="7">@width</strong>: 0;
.mixin {
  width: @width;
}

उपयोगकर्ता रहित:

<strong i="11">@import</strong> "library.less"; //first declaration of <strong i="12">@width</strong>
<strong i="13">@width</strong>: 1; //this will override <strong i="14">@width</strong> defined previously
.class {
  .mixin();
}

में संकलित करता है:

.mixin {
  width: 1;
}
.class {
  width: 1;
}

हमारे पीआर पर प्रतिक्रिया के लिए धन्यवाद। ये समाधान काम करने योग्य होंगे यदि हमारे पास उपभोग करने के लिए एक ही चीज़ या कुछ छोटी चीज़ें हों। तो मुझे विस्तार से बताएं कि ये समाधान हमारे मामले में व्यावहारिक क्यों नहीं हैं।

हम एक वर्ग पदानुक्रम के रूप में कार्यान्वित घटकों का एक बड़ा ढांचा बनाते हैं। हम अपने मूल विषय में प्रत्येक घटक के लिए अपनी फ़ाइल... में चर घोषित करते हैं। फिर हम यहां से उन विषयों को "व्युत्पन्न" करते हैं जो इस चर को संशोधित करना चाहते हैं। उपयोगकर्ता किसी थीम को अपनी आवश्यकताओं के अनुसार ट्यून करने के लिए आगे ऐसा कर सकते हैं।

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

इन समस्याओं का अब तक का सबसे अच्छा समाधान _always_ चर को "! डिफ़ॉल्ट" (Sass शब्दों में) के रूप में परिभाषित करना है। यह उपयोगकर्ताओं को केवल पहले प्रवेश करने और आगे के मूल्यों की गणना करने के लिए इन मूल्यों का उपयोग करने से पहले अपने मूल्यों को निर्धारित करने की अनुमति देता है। तब हमारे उपयोगकर्ताओं के लिए समय का प्रबंधन करना काफी सरल है। चूंकि यह हमेशा हमारे सभी विषयों में प्रत्येक चर के लिए होता है, ऊपर सुझाए गए सिंटैक्स संघर्ष काफी बोझ और त्रुटि प्रवण भी होंगे।

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

मुझे आशा है कि आप इसे विलय करने पर विचार करेंगे या कुछ ऐसे विकल्प प्रदान करेंगे जो प्रकृति में अधिक घोषणात्मक हों। स्कोप ट्रिक्स का शोषण करना वास्तव में हमारे काम नहीं आएगा।

आपके समय और विचार के लिए फिर से धन्यवाद!

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

बस स्पष्ट करने के लिए हम यहां केवल चर के बारे में बात कर रहे हैं। और हमारे पास मुख्य स्टाइलशीट नहीं है - हमारे पास प्रति विषय प्रति वर्ग एक है। :)

हो सकता है कि मैं आपके सुझाव का पालन नहीं कर रहा हूं, लेकिन उदाहरण के तौर पर, हमारी थीम वैरिएबल फाइलों में से एक इस तरह दिखती है:

$panel-base-color: $neutral-light-color !default;
$panel-header-color: $base-color !default;
$panel-frame-border-width: 1px !default;
$panel-header-font-size: round($font-size * 1.15) !default;
$panel-body-border-color: $neutral-dark-color !default;

$panel-light-header-color: #000 !default;
$panel-light-header-background-color: #fff !default;
$panel-light-tool-background-image: 'tools/tool-sprites-dark' !default;
$panel-light-body-border-color: $neutral-dark-color !default;
$panel-ignore-frame-padding: true !default;

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

यह पैटर्न _a बहुत_ दोहराया जाता है :)

ठीक है, क्यों न सिर्फ अपनी मुख्य कम शीट में @panel-base-color को ओवरराइड करें? LESS वेरिएबल्स वैश्विक हैं इसलिए जो भी अंतिम होता है वह विजेता होता है।

<strong i="7">@import</strong> 'theme.less';

@panel-base-color: red;

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

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

मैं उत्सुक हूं कि क्या इसका मतलब यह है कि यह पुल अनुरोध या कुछ समान व्युत्पन्न कभी स्वीकार किया जाएगा? यदि आपत्तिजनक है तो हमें वाक्य रचना में बदलाव करने में खुशी होगी।

हमारे पास "मुख्य कम शीट" नहीं है :)

बस ऊपर दिए गए उत्तरों में "आपकी मुख्य कम शीट" को "किसी भी उपयोगकर्ता की कम शीट" से बदलें। अब तक ऐसा लगता है कि SASS !default (इसका जो भी सिंटैक्स है) का आविष्कार एक ऐसी समस्या को हल करने के लिए किया गया है जो LESS में मौजूद नहीं है।
@dongryphon , मैं निश्चित रूप से गलत हो सकता हूं, लेकिन आपने अभी तक यह नहीं बताया है कि आप @SomMeri और @Soviut द्वारा सुझाए गए समाधान का उपयोग क्यों नहीं कर सकते।

इसे दूसरे तरीके से रखने के लिए, कल्पना करें कि क्या आप आयात नहीं कर रहे थे और इसके बजाय आपके सभी चर एक ही शीट में थे। यह वही है जो आयात करता है। तो उस स्थिति में, यदि आपके पास एक ही नाम के साथ दो चर घोषणाएँ थीं, तो शीट में अंतिम जीत होगी।

@base-color: green;

div {
    background: @base-color;
}

@base-color: red;

चूंकि आधार रंग अंत में फिर से घोषित किया जाता है, इसलिए div में उपयोग किया जाने वाला आधार रंग लाल होगा। यह इसके लिए संकलित होगा:

div {
    background: red;
}

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

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

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

यह काउंटर है जो एक जावास्क्रिप्ट प्रोग्रामर सोच सकता है, लेकिन इसके पीछे का विचार यह है कि यह सीएसएस के करीब है।

कृपया क्या आप विस्तार से बता सकते हैं कि उपभोक्ताओं को आदेश पर विचार करने के लिए कहना संभव या वांछनीय क्यों नहीं है? हम मजबूत उपयोग के मामलों के साथ सुविधाओं को स्वीकार करेंगे लेकिन भाषा और जटिलता ब्लोट से बचने के लिए हमें कठोर होना होगा।

देखें #1109 #1104 #313

और केवल स्पष्ट करने के लिए, हम किसी भी खिंचाव से "नहीं" नहीं कह रहे हैं। हम उसे दिखाने की कोशिश कर रहे हैं कि यह सुविधा पहले से मौजूद हो सकती है।

मैंने कम-दस्तावेज़ों में कुछ जानकारी जोड़ी

पहले से उपलब्ध के रूप में बंद करना ("कम तरीके से") सुविधा (http://lesscss.org/features/#variables-feature-default-variables)।

मुझे लगता है कि यह भ्रम अक्सर सामने आता है क्योंकि ओवरलैपिंग _syntax_ है, SASS ऊपर से नीचे तक "निष्पादित" करता है लेकिन LESS नहीं करता है, और इसके बजाय CSS की तरह अधिक संचालित होता है। LESS CSS+ (अतिरिक्त सुविधाओं के साथ CSS) की तरह है, और SASS "CSS सिंटैक्स के साथ PHP" जैसा है। मुझे आश्चर्य है कि अगर कोई रास्ता है (यदि आवश्यक हो) तो हम उस भेद को बना सकते हैं।

कृपया क्या आप विस्तार से बता सकते हैं कि उपभोक्ताओं को आदेश पर विचार करने के लिए कहना संभव या वांछनीय क्यों नहीं है? हम मजबूत उपयोग के मामलों के साथ सुविधाओं को स्वीकार करेंगे लेकिन भाषा और जटिलता ब्लोट से बचने के लिए हमें कठोर होना होगा।

क्योंकि हम पुस्तकालय उपयोगकर्ताओं (और उपभोक्ताओं) को स्वयं पुस्तकालय कोड को कभी भी संपादित नहीं करना सिखाते हैं। लापता !default फीचर का मतलब है कि हमें उन दो चीजों में से एक करना है - दोनों समान रूप से खराब आईएमओ:

• उपयोगकर्ताओं को उन चरों को संपादित करने के लिए स्वयं पुस्तकालय स्टाइलशीट को संपादित करना होगा जहां उन्हें घोषित किया गया है (जो एक वर्जित चीज है, पुस्तकालय अद्यतन को कठिन बना देता है) या,
• पुस्तकालय को दो स्टाइलशीट प्रदान करनी होती है: एक डिफ़ॉल्ट चर के लिए और दूसरा वास्तविक नियमों के लिए। फिर उपयोगकर्ता को पहले वाले को @import करना होगा, फिर अपने स्वयं के चर घोषित करना होगा, फिर @import दूसरे को। यह जितना होना चाहिए उससे कहीं अधिक जटिल है, खासकर उन दो फाइलों को एक ही संस्करण में रखने के लिए।

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

my-color: red;
<strong i="15">@import</strong> "./my-library.less";

के बजाय:

<strong i="19">@import</strong> "./my-library-variables.less";
my-color: red;
<strong i="20">@import</strong> "./my-library-rules.less";

मुझे लगता है कि आपको इस मुद्दे पर पुनर्विचार करना चाहिए।

@arcanis वास्तव में मैं नहीं देख सकता कि आप ऐसा क्यों सोचते हैं:

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

कम में यह बिल्कुल वही पुस्तकालय डिजाइन है:

<strong i="11">@import</strong> "./my-library.less";
@my-color: red;

मुझे लगता है कि आप बस "आलसी-लोडिंग" चीज़ को याद कर रहे हैं (और ठीक उसी उदाहरण का उपयोग दस्तावेज़ों में no, thanks! से !default कहने के लिए किया जाता है)।

मुझे लगता है कि आप बस "आलसी-लोडिंग" चीज़ को याद कर रहे हैं

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

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

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

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

हो सकता है कि कम में !default सुविधा के लिए हमें इतने अनुरोध प्राप्त होने का कारण यह है कि कुछ लोग इस सुविधा को समझते हैं या इसे दस्तावेज़ों से संक्षिप्त उदाहरण से समझते हैं (मेरे सहित, जाहिर है)।

कम से कम, इसे फिर से समझाने के लिए धन्यवाद @ सात-चरण-अधिकतम!

वूप्स। अच्छा, तुम सही हो। मैंने डॉक्स को भी गलत समझा, मेरा बुरा!

@ सोवियत आप एक गोश- रफ़ जीनियस हैं! मुझे नहीं पता था कि एसएएसएस/कम में परिवर्तनीय घोषणाएं उस तरह काम करती हैं। शुक्रिया!

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

साथ ही, ध्यान दें: @spikesagal जहां तक ​​आपका कथन है: "मुझे नहीं पता था कि परिवर्तनीय घोषणाएं एसएएसएस/कम में काम करती हैं" - मेरे सर्वोत्तम ज्ञान के लिए, चर का व्यवहार दो भाषाओं के बीच समान नहीं है, क्योंकि SASS और LESS चीजों का बहुत अलग तरीके से मूल्यांकन करते हैं।

और Sass में जाने के कारण वे BS4 में इस सुविधा को समाप्त कर रहे हैं...:-1: उस कदम से अभी भी बहुत दुखी हैं।

तो यह शुरू होता है, अधिक के लिए लड़ाई! डिफ़ॉल्ट चर: [twbs/bootstrap#17418]

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

कुंआ। बूटस्ट्रैप का आधिकारिक v4-alpha Sass में चला गया। वह, कम से कम मेरी समझ में, उनके आधिकारिक दस्तावेज में कम मार रहा है - और इसका मतलब इस सुविधा के समर्थन को भी मारना है क्योंकि सैस के पास आलसी-लोडिंग चर जैसी कोई चीज नहीं है। वे केवल !Default का समर्थन करते हैं, जिसका एक तरह से अर्थ है: "अरे हाँ, हम आपको बाहर से केवल एक बार हमारे चरों को ओवरराइड करने की अनुमति देते हैं, और केवल तभी जब हम ऐसा करने की अनुमति देते हैं। इसलिए, यदि हम आपको एक्सेस देना भूल जाते हैं बस डिफ़ॉल्ट को छोड़ कर एक चर, आप बहुत ज्यादा खराब हो गए हैं और आपको अपनी फाइलों में पूरे रफ़ू चयनकर्ता को ओवरराइड करना होगा। इससे निपटें।"

और इसका मतलब इस सुविधा के लिए समर्थन को मारना भी है क्योंकि Sass में आलसी-लोडिंग चर जैसी कोई चीज नहीं है।

खैर, इसका मतलब केवल "वे इसे बूटस्ट्रैप में मारते हैं" (जो स्पष्ट रूप से इस थ्रेड स्कोप से बाहर है - जब तक बीएस का कोई कम संस्करण नहीं है, हमें _this_ रिपॉजिटरी में बूटस्ट्रैप सुविधाओं की परवाह नहीं करनी चाहिए, क्या हमें चाहिए?)

चूंकि यह चर्चा बूटस्ट्रैप में चरों को ओवरराइड करने के बारे में बहुत अधिक थी ...

हम कम से चिपके हुए हैं: मुस्कान:

मेरे पास मूल रूप से बताई गई दुविधा के लिए उपयोग का मामला है। निम्नलिखित सरलीकृत उदाहरण पर विचार करें:

1. मेरे पास एक कम फ़ाइल है जो h1 के फ़ॉन्ट आकार को परिभाषित करती है, कुछ इस तरह
   <strong i="8">@font_size__h1</strong> = 30px;
2. मेरे पास (बेहतर वाक्यांश की कमी के लिए) एक प्लगइन है जिसमें एक अलग LESS फ़ाइल है जो @font_size__h1 घोषणा का उपयोग करती है। तो मैं इसे <strong i="12">@import</strong> (reference) "path/to/file.less"; । कोई बात नहीं, यह अब उपलब्ध है।
3. अब मैं उस "प्लगइन" को एक नई साइट पर ले जाता हूं जिसमें @font_size__h1 कहीं भी परिभाषित नहीं है। इस बिंदु पर यह कहना बहुत अच्छा होगा "यदि @font_size__h1 परिभाषित किया गया है, तो उस मान का उपयोग करें। यदि यह परिभाषित नहीं है, तो मेरे द्वारा यहां परिभाषित मान का उपयोग करें।"

आइटम 3 वर्तमान में संभव नहीं है, जहाँ तक मैं देख सकता हूँ।

@theMikeD

आइटम 3 वर्तमान में संभव नहीं है, जहाँ तक मैं देख सकता हूँ।

ऐसा नहीं लगता कि आपने धागा पढ़ा है:

<strong i="10">@import</strong> "path/to/file.less";
<strong i="11">@import</strong> "here.less"; // if it's not defined <elsewhere>, then use the value I define <here>
<strong i="12">@import</strong> "elsewhere.less";

जो निश्चित रूप से कम किया जा सकता है:

<strong i="16">@import</strong> "path/to/file.less"; // <- define default value there
@font-size-h1: foo;          // if it's not defined here then use the value defined above

जो मूल रूप से http://lesscss.org/features/#variables -feature-default-variables जैसा ही उदाहरण है

हाँ मैंने धागा पढ़ा। ऐसा लगता है कि आप समझ नहीं पा रहे हैं कि मैं क्या पूछ रहा हूं, क्योंकि आपके उदाहरण में मेरा प्रश्न पीछे की ओर है।

जो निश्चित रूप से कम किया जा सकता है:
@import "पथ/से/file.less"; // <- वहां डिफ़ॉल्ट मान को परिभाषित करें
@ फ़ॉन्ट-आकार-एच 1: फू; // यदि इसे यहां परिभाषित नहीं किया गया है तो ऊपर परिभाषित मान का उपयोग करें

मुझे जो चाहिए वह इसके विपरीत है। यह स्थानीय मूल्य के साथ @font-size-h1 में path/to/file.less के मूल्य को अधिलेखित कर देगा चाहे कुछ भी हो। मुझे जो चाहिए वह स्थानीय फ़ाइल में केवल तभी उपयोग किया जा रहा है जब:
a) path/to/file.less लोड नहीं है, या
b) '@ font_size__h1 is not set in path/to/file.less` का मान

IOW @font-size-h1: foo; का स्थानीय मान हमेशा स्थानीय फ़ाइल में मौजूद रहेगा, लेकिन अगर इसे path/to/file.less में सेट किया गया है, तो इसे अतिभारित किया जाना चाहिए

किसी भी मामले में, मुझे कल रात समाधान मिला, जो पहले स्थानीय मूल्य निर्दिष्ट करना है, फिर फ़ाइल के अंत में @import कथन डालें, शुरुआत नहीं। यदि पाया जाता है, तो यह स्थानीय मान को अधिलेखित कर देगा।

फिर भी धन्यवाद।

ऐसा लगता है कि आप समझ नहीं पा रहे हैं कि मैं क्या पूछ रहा हूँ

इसके बजाय मैं आपको अपने विचार को ताज़ा करने के लिए कुछ कम परिवर्तनीय मूल बातें शुरू करने का सुझाव दूंगा:

• आलसी-मूल्यांकन
• चर शब्दार्थ
• दुनिया की सबसे गलत समझ...

(क्योंकि ऐसा लगता है कि आप इसे एक अनिवार्य सी/पीएचपी-जैसे तरीके से सोचने की कोशिश कर रहे हैं, जबकि कम/सीएसएस में यह पूरी तरह से "घोषणात्मक अप-साइड-डाउन" है)।
इन सभी वर्षों में मृत्यु के बारे में बात की गई है, देशी कम परिवर्तनीय ओवरराइडिंग की तुलना में !default _nothing_ नया जोड़ सकता है। अवधि। (हम पहले भी कई बार वहां जा चुके हैं: अगर कोई सोचता है कि उसे कम में !default के लिए कुछ उपयोग-मामला मिला, तो इसका मतलब कम परिवर्तनीय अर्थशास्त्र की उनकी गलतफहमी के अलावा कुछ भी नहीं है)।

मुझे जो चाहिए वह स्थानीय फ़ाइल में केवल तभी उपयोग किया जा रहा है जब:
a) path/to/file.less लोड नहीं है, या
b) @ font_size__h1 path/to/file.less में सेट नहीं है

तो यह बिल्कुल विपरीत है:

@font-size-h1: foo;
<strong i="27">@import</strong> "path/to/file.less"; 

टाडा!

... जहां मैं उतरा, जैसा कि मैंने कहा।

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

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

app.less
/ग्रिड/ग्रिड.विहीन

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

@ जीरी777

लेकिन अगर बाहर से एक निश्चित चर पहले से ही परिभाषित है कि प्राथमिकता होनी चाहिए।

सीएसएस की तरह कम मूल्यांकन।

.css {  
  --color: blue;
  color: var(--color);  // --color will be red
  --color: red;
  border-color: var(--color);  // --color will still be red, red is the scope's final value
}

.less {  
  <strong i="10">@color</strong>: blue;
  color: @color;  // <strong i="11">@color</strong> will be red
  <strong i="12">@color</strong>: red;
  border-color: @color;  // <strong i="13">@color</strong> will still be red, red is the scope's final value
}
````

Scss, instead, doesn't mimic CSS evaluation and instead evaluates more like, say, PHP.

```scss
.scss {  
  $color: blue;
  color: $color;  // $color will be blue
  $color: red;
  border-color: $color;  // $color will be red
}

तो, Sass/SCSS में, रूट वेरिएबल के मान को ओवरराइड करने के लिए, आपको दो चीजें करने के लिए मजबूर किया जाता है:

1. आपको अपनी सभी परिवर्तनीय घोषणाओं को !default के साथ टैग करना होगा
2. इन डिफ़ॉल्ट घोषणाओं से पहले आपको अपने वैश्विक संस्करण डालने होंगे।

जैसे की:

// main.scss
<strong i="22">@import</strong> "overrides.scss";
<strong i="23">@import</strong> "library.scss";

// overrides.scss
$color: red;

// library.scss
$color: blue !default;

.scss {
  color: $color;
}

कम में, थीमिंग बहुत आसान है। आपको (आमतौर पर) अपनी लाइब्रेरी के बारे में कुछ भी बदलने की ज़रूरत नहीं है, आपको बस अपने ओवरराइड को बाद में रखना होगा। आपको केवल एक काम करने की जरूरत है।

// main.less
<strong i="27">@import</strong> "library.less";
<strong i="28">@import</strong> "overrides.less";

// overrides.less
<strong i="29">@color</strong>: red;

// library.less
<strong i="30">@color</strong>: blue;

.less {
  color: @color;
}

इसलिए, आपको !default की आवश्यकता नहीं है क्योंकि कम हमेशा आपके अंतिम मूल्य को स्वीकार करेगा।

CSS के कैस्केड की तरह कम मूल्यांकन के बारे में सोचें। यह सिर्फ काम करता है। अंतिम घोषणा जीत जाती है।