Less.js: السماح للحراس بالعمل باستخدام متغيرات غير محددة

+1
يمكن أيضًا استخدام هذا لتعيين الألوان الأساسية في المكتبات.
تخيل الحالة التالية:
لديك ملف أقل لتطبيق معين ، مثل القائمة الرئيسية لموقع الويب.
يمكنك استيراد هذا الملف الأقل في ملف أقل رئيسي ، حيث يتم تعريف الألوان الأساسية الخاصة بك على أنها متغيرات.
الآن إذا كنت تستخدم هذه الألوان الأساسية في ملف أقل بالقائمة الرئيسية ، فإنها تعتمد على الملف الرئيسي.
إذا كان بإمكانك التحقق من المتغيرات من أجل الوجود ، فيمكنك الرجوع إلى الألوان المحددة بالوحدة النمطية.
فيما يلي مثال على كيفية تخيل ملف أقل من القائمة:

@menu-base-color: white;
@menu-base-color: @base-color when (@base-color);
...or...
@menu-base-color: @base-color when isset(@base-color);

+1 ، لدينا بالفعل istext ، isnumber وجود isdefined و isundefined سيساعد كثيرًا في استخدامهم بأقل.

أي استخدم value أو userValue إذا كان isdefined

أواجه هذه المشكلة كثيرًا عند محاولة إعداد اصطلاحات السمات لواجهة المستخدم الدلالية مع أقل.

إجراء 1+ على هذا - سيكون رائعًا حقًا.

+1 على هذا بالنسبة لي أيضًا

ليست صفقة كبيرة لإضافة وظيفة is-defined (أتوقع ظهورها في أحد المكونات الإضافية الأولى بمجرد إصدار v2). على الرغم من الصدق ، فإن الشيء المحزن هو أن أولئك الذين يريدون هذه الميزة يفوتون حقًا حقيقة أن كلتا حالات الاستخدام المذكورة أعلاه قابلة للحل (في كثير من الحالات حتى مع وجود كود أكثر إحكاما) بدون أي ميزة من هذا القبيل.

حالة استخدام InitArt :

// library.less
<strong i="9">@variable</strong>: false;

a when (@variable) {
    color: red;
}

// ......................................
// user.less
<strong i="10">@import</strong> "library.less"
<strong i="11">@variable</strong>: true;

حالة استخدام @ nemesis13 :

// library.less
@base-color: green;
@menu-base-color: @base-color;

.menu {
    background-color: @menu-base-color;
}

// ......................................
// user.less
<strong i="16">@import</strong> "library.less"
@base-color: white;
// or:
@menu-base-color: black;
// or whatever...

أي باختصار: بدلاً من اختبار ما إذا كان المتغير محددًا فقط قم بتوفير قيمة افتراضية لذلك المتغير لأن القيم المتغيرة يمكن تجاوزها بحرية.

يمكن لأي شخص أن يجيب لماذا مثال ماكس غير قادر بالنسبة لهم؟ استطيع فقط
افترض أن السبب هو أنك لا تعرف ما إذا كان المتغير معرّفًا أعلاه أم
دون الاستيراد؟ أو انه شيء اخر؟
لن نفكر في شيء ليس به حالات استخدام.
الجانب السلبي للقيام بذلك هو أن الأشخاص الذين يخطئون في كتابة متغير لن يروا ملف
خطأ. يمكننا حل هذا مع تحذير ولكن بعد ذلك إذا قمت بذلك
الغرض أنك لا تريد تحذيرًا .. هذه مشكلتي الوحيدة مع هذا
اقتراح.

هذا مفيد بشكل خاص عند تحديد السمات لتقليل حجم CSS الناتج. عند إنشاء السمات بشكل عام ، قد يرغب المرء في تمكين تعيين الكثير من الخصائص. ومع ذلك ، قد يرغب المستخدمون في تعيين بعضهم فقط مع ترك باقي الخصائص بدون ضبط. بالطبع ، سيعمل تعيينها على القيم الافتراضية بشكل عام ، ومع ذلك ، فإن هذا يؤدي إلى تضخيم CSS النهائي.

ضع في اعتبارك الموضوع الأساسي التالي (نموذج):

.my-class {
    color: @text-color;
    background-color: @background-color;
    border-color: @border-color;
}

قد يرغب مستخدم السمة في تعيين لون النص فقط مع ترك باقي الخصائص بدون ضبط. بالطبع من الممكن تعيين القيم على "أولية" و "شفافة" و "ترث" وما إلى ذلك ، ومع ذلك ، فإن هذا يزيد من حجم CSS النهائي. تميل السمات إلى امتلاك المئات من هذه الخصائص ، لذا قد يزيد الحجم بشكل كبير.

تضمين التغريدة

أعتقد أنك تفتقد الهدف من طلب الميزة هذا ، لاحظ أنه بالنسبة لحالة الاستخدام الخاصة بك ، ما زلت بحاجة إلى وضع حماية لكل من هذه الخصائص (ومن ثم لا يزال الأساس المنطقي الذي اقترحته منشورين أعلاه ساريًا). لذلك لا أعتقد أن حالة الاستخدام تضيف شيئًا جديدًا إلى # 1400 (يبدو أنك تقترح ميزة مختلفة مثل "خاصية التخطي إذا تم تعيين جميع قيمها بمتغيرات غير محددة" أو شيء من هذا القبيل ولكنه شيء آخر قصة كبيرة).

@ سبع مراحل كحد أقصى

ربما يكون من الأفضل إذا كان من الممكن تعيين متغير على قيمة "غير محددة" أو "غير محددة". تعيين خاصية إلى مثل هذه القيمة يعني أن الخاصية لا يتم عرضها في CSS النهائي. هذا يبسط بناء الجملة ويجعل من الممكن التحقق من أن المتغير قد تم التصريح به.

تضمين التغريدة

ربما يكون من الأفضل إذا كان من الممكن تعيين متغير على قيمة "غير محددة" أو "غير محددة".

كما ذكرت ، فهذه ميزة أخرى تحتاج إلى تذكرتها الخاصة (مع مناقشتها الخاصة).

فقط بعض التوضيحات لخارطة الطريق: تم وضع علامة "ReadyForImplementation" على هذا ، ولكن لا يبدو أن هناك إجماعًا في هذا الموضوع ، ويبدو أن @ Seven-stage-max اقترح بديلاً لائقًا. هل يجب إزالةlukeapage @ seven-stage-max ، على استعداد للتنفيذ؟

@ ماثيو دين ليس لدي فكرة. أفترض هنا أن "ReadyForImplementation" لا يزال صالحًا نوعًا ما ، مما يعني شيئًا مثل "يبدو أن هذه الميزة ليست ضرورية حقًا ولكن إذا توصل شخص ما إلى علاقات عامة تنفذ مثل هذا الشيء فلن تكون هناك مقاومة" أو نوع من :)

كيف ذلك؟ (في الحسبان)

بالنسبة لي ، تعني عبارة "جاهز للتنفيذ" أن هناك إجماعًا عامًا (ولكن ليس بالضرورة إجماعيًا) على أنه _يجب_ معالجته أو تنفيذه. أعتقد أن عبارة "قيد النظر" تفي بتعريفك.

لا تزال تواجه هذه المشكلة عند استخدام النطاق

<strong i="6">@foo</strong>: 'bar';
& { 
  // not sure if <strong i="7">@foo</strong> is defined
}

أحب القدرة على استخدام isDefined

في حين أن شيئًا مثل is-defined منطقي (كسكر نحوي) ، فإنه ليس مطلوبًا حقًا. فقط _ دائمًا_ حدد @foo (بأي قيمة افتراضية تحتاجها) ، بعد كل شيء إذا كنت تستخدم متغيرًا ضمن أنماطك - يمكنك توقع أنك بحاجة إلى تعريفه ، على سبيل المثال:

// in a far far away galaxy of your library default variables:
<strong i="8">@foo</strong>: undefined;

// the code where you need it
& when not(<strong i="9">@foo</strong> = undefined) { 
    // <strong i="10">@foo</strong> is defined by user    
}

// some user code
<strong i="11">@foo</strong>: bar;

على الرغم من أنني أعتقد أنني كتبت هذا بالفعل في الأمثلة أعلاه (أحاول فقط التأكد من التعبير عن حقيقة أن عدم وجود هذه الميزة لا يمكن أن يكون بمثابة توقف لأي شيء. إذا كنت تعرف أي حالة استخدام حيث توجد واحد ، من فضلك شارك).

أحاول إعداد معاينات السمات في المتصفح.

هذا يعني أنه يجب علي استخدام less.js واستبدال المتغير الافتراضي @theme بإعدادات وقت التشغيل.

علاء

window.less.modifyVars({
  theme: 'someOtherValue'
})

في أقل ، أقوم باستيراد ملف theme.less شامل يتضمن ملفات

<strong i="14">@theme</strong>: undefined;

.setTheme {
  <strong i="15">@theme</strong> : 'default';
}
.setTheme;

لقد حاولت أيضًا

<strong i="19">@theme</strong>: 'default';

في الحالة الأولى ، القيمة الناتجة هي undefined في الحالة الثانية تكون دائمًا default بغض النظر عن ما تم ضبطه في modifyVars

انقر فوق موضوع القائمة المنسدلة هنا للحصول على مثال.

يتمثل العمل الحالي (الموجود على الموقع المباشر) في الاستيلاء يدويًا على مسار الاستيراد المتغير ، وتحليله باستخدام regexp ثم استيراد كل هذه المتغيرات باستخدام modifyVars ، كما يمكنك تخمين هذا أمر فوضوي جدًا

@ Seven-stage-max لقد قمت بتضييقها إلى حالة اختبار محددة للغاية مع وجود @import تسبب في حدوث مشكلات.

في كلتا الحالتين نفترض:

جافا سكريبت

window.less.modifyVars({
  theme: 'changedValue'
});

في الحالة الأولى في theme.less ، تم تعيين outer بشكل صحيح على changedValue

مكون

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

موضوع

<strong i="22">@theme</strong>: 'default';
.outer {
  value: @theme; // value is set to changedValue
}

في هذه الحالة الفاشلة ، في theme.less @theme تم تعيينه إلى default وليس changedValue

مكون

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

موضوع

<strong i="37">@theme</strong>: 'default';
<strong i="38">@import</strong> "@{theme}"; // theme is set to default not changedValue

في حالة "var in mixin" ، يتحول المقتطف إلى:

// defaults:
.setTheme {
   <strong i="6">@theme</strong>: undefined;
}

// custom:
.setTheme {
  <strong i="7">@theme</strong>: 'default';
}
.setTheme;

على الرغم من أنه بالنسبة إلى modifyVars ، يجب أن ينتج عنه دائمًا 'someOtherValue' لأي من المقتطفين اللذين جربتهما (لأن modifyVars يعمل ببساطة عن طريق إلحاق سطر <strong i="14">@theme</strong>: 'someOtherValue'; في نهاية المترجم مباشرة مصدر الرمز). لذلك إذا لم تعمل المشكلة modifyVars الأرجح في أي مكان آخر ، إذا لم تنجح المشكلة في حل المشكلة.
لقد ألقيت نظرة على رمز الصفحة button ولكن من المعقد جدًا أن أقول بسرعة ما يمكن أن يكون خطأ. للوهلة السريعة ، لا يمكنني رؤية (أو ربما لا أفهم) كيف تتم إعادة ترجمة الكود الأقل وإعادة تطبيق CSS الناتج بعد modifyVars (في مقتطفات بسيطة يتم ذلك عبر less.refreshStyles بعد $ # $ 8 $ # $ بعد $ # $ 7 $ # modifyVars ).

راجع للشغل ، فقط في حالة ، هل أنت متأكد من أنك لا تخطط لاستخدام is-default كشيء مثل:

.setTheme when not(is-defined(@theme)) {
  <strong i="26">@theme</strong>: 'default';
}
.setTheme;

؟ إذا كان الأمر كذلك ، فإن المشكلة تكمن في أن هذا الرمز سينتهك بشكل مباشر مبدأ التقييم الكسول (يجب أن يُرجع is-defined خطأ إذا لم يتم تعريف المتغير ، ولكن نظرًا لأنه _ سيتم تعريفه في هذا النطاق على الفور ، فإن , is-defined لديه أيضًا لإرجاع صحيح -> العودية غير القابلة للحل. (لمزيد من التفاصيل حول سبب عدم السماح بإعادة التعريفات الشرطية الشبيهة بالأمر بأمان في Less see # 2072).
أي أنه يمكن أن يعمل بالفعل كما هو متوقع (ما لم يتم ترميز is-defined للكشف صراحة عن مثل هذا التكرار والإنقاذ منه) ولكن فقط كنوع من السلوك غير المحدد / غير المحدد ، بدون الاتساق مع قواعد الرؤية المتغيرة العادية وبالتالي إنشاء حتى المزيد من الفوضى.

تضمين التغريدة

<strong i="8">@theme</strong>: 'default';
<strong i="9">@import</strong> "@{theme}"; // theme is set to default not changedValue

نعم ، كان هذا أحد شكوكي أيضًا (لسوء الحظ لا يمكنني اختبار هذا الآن ، ولا يمكنني تخمين كيف يمكن أن يحدث هذا ، ولكن نعم ، هذا ممكن لأن الاستخدام المتغير في الواردات هو سحر أسود حقيقي. سأقوم بإنشاء ملف مخصص تقرير المشكلة إذا كانت هذه هي المشكلة).

أنا متأكد تمامًا من أن له علاقة بهذا السحر الأسود الرائع.

لقد كنت أعمل مع عدد أقل من الملفات البسيطة جدًا لتصحيح الأخطاء ، ولكن لم تتح لي الفرصة لإنشاء إعادة شراء حالة اختبار حتى الآن.

في الاختبارات التي أجريتها ، يقتصر الفشل على استخدام قيم {@variable} في الاستيراد ، ولكن ليس في خصائص css.

استمتع حقًا بالاستمتاع بها بأقل من ذلك ، وأحب تجاوز هذه المشكلات. إليك مثال ممتع عن السمات مع LESS الذي عرضته للتو في Meteor DevShop الأسبوع الماضي (انقر فوق أيقونة Paintbucket في أعلى اليمين)

jlukic لقد اختبرته و modifyVars يعمل مع vars في الواردات كما هو متوقع مع lessc ومع less.js (انظر العرض التوضيحي لـ codepen ، إنه رمز صعب بعض الشيء لأنه كان مضطرًا إلى ذلك استيراد من عنوان url المخيف للجوهر ، لكنني أفترض أنه مساوٍ لما يفترض أن تؤديه صفحاتك ... لذلك يبدو في الواقع أن المشكلة تكمن في مكان آخر).

شكرًا على الوقت الذي استغرقته لتقديم حالة الاختبار لي. هذا قطع واضح جدا. لست متأكدًا مما يحدث بالنسبة لي .. سأضطر إلى التحقيق

هل كان هناك أي تحرك على هذا الطلب؟ لقد كنت متشوقًا لفحص متغير غير محدد لبعض الوقت الآن. في الوقت الحالي ، لدي عمل بعيد عن المثالية ...

p {
  & when not (@body-text-color = null) {
    color: @body-text-color;
  }
}

ولكن ، لكي يعمل هذا ، يجب أن يكون المتغير موجودًا ويتم تعريفه افتراضيًا على أنه null . سيكون هذا أكثر فعالية / مرونة إذا كان بإمكاني بدلاً من ذلك التحقق مما إذا كان المتغير موجودًا في المقام الأول.

+1

إذن باختصار: يتطلب تنفيذ وظيفة is-defined(name) (و / أو get-value-of(var-name, fallback-value-if-not-defined) ) داخل مكون إضافي أقل من 15 سطرًا من التعليمات البرمجية. لذا افعل ذلك فقط إذا كنت شجاعًا بما فيه الكفاية.

+1 لهذا. هل هناك أي تقدم في هذا كمكوِّن إضافي؟ أعني ، @ seven-stage-max ، فأنت تعرف الكود أفضل من معظم المساهمين ، على ما أعتقد. إذا كان يتطلب حوالي 15 سطرًا من التعليمات البرمجية ، فلماذا لم يتم إجراؤها بعد؟

إذا كان يتطلب حوالي 15 سطرًا من التعليمات البرمجية ، فلماذا لم يتم إجراؤها بعد؟

لأنه لا أحد مهتم حقًا ؟ كل ميزة رائعة و "مفيدة للغاية" عندما يقوم شخص آخر بذلك نيابة عنك ... لكنها بطريقة سحرية لا تصبح مهمة جدًا عندما يتعلق الأمر بوقتك ؛)

أنت تعرف الكود أفضل من معظم المساهمين

هذا لا يعني أنني يجب أن أضع أي شيء من مصلحتي بعد أي شيء يثير اهتمام شخص آخر ، آسف (خاصة إذا كان هذا شيئًا مشجعًا لما أعامله شخصيًا على أنه أسلوب سوء استخدام / رمز سيء).

لكي لا تبدو فارغة ، بالنسبة إلى حالة استخدام ashenden : إليك الطريقة الصحيحة لجعل أي مجموعة من القواعد الخاصة بك قابلة للتخصيص من خلال "مجهولات" (من الواضح على افتراض حالة يكون فيها تجاوز CSS العادي غير قابل للتطبيق لسبب ما) بدون الخطأ فكرة "عمياء تحرك كل قيمة CSS إلى متغير بالإضافة إلى استخدام شيء ما لا تستخدمه" (لن أخوض في تفاصيل سبب تعطلها فعليًا لأنها قصة تدوينة طويلة).

عادة ما يكون هناك مفهوم يسمى "الخطافات" ، لذا فإن ما يلي "لا يمكن أن يجعلني أفكر في المهرجان":

// .............................................
// base code:

p {
    & when not (is-defined(@body-text-color)) {
        color: @body-text-color;
    }
    & when not (is-defined(@body-text-color)) {
        background-color: @body-back-color;
    }
}

span {
    & when not (is-defined(@body-text-color)) {
        color: @body-text-color;
    }
    & when not (is-defined(@body-text-color)) {
        background-color: @body-back-color;
    }
}

// .............................................
// customization:

@body-back-color: blue; // how about gradient?

يجب استبداله بـ:

// .............................................
// base code:

p {
    .body-text();
    .body-back();
    // ^ it's actually better to group all this into a singe entity, e.g. .p()
    // so that as you don't know WHAT or HOW to be customized
    // you don't pre-enforce any limitations and/or hardcoded approach
    // for something YOU do not even write
}

span {
    .body-text();
    .body-back();
}

.body-text() {}
.body-back() {}

// .............................................
// customization:

.body-back() {background-color: blue}

عد الخطوط ، احسب الاحتمالات ، احسب القيود.
أي حقًا ، إذا كنت لا تستخدم بعض خصائص CSS ، فالرجاء تركها بمفردها لمن سيفعل ذلك .

يا رفاق ، هنا حيث واجهت هذا ، يرجى إلقاء نظرة على هذا المثال وإخباري ما إذا كانت حالة صالحة ولا يمكن إصلاحها بدون تعريف غير محدد.

أريد تحميل موضوعات في مكتبة مثل وحدة مثل هذا:

في تطبيقي الأساسي ، أحدد متغير theme : "أصفر" ثم أستورد مكتبة أقل.

وإليك ما يمكن أن تبدو عليه المكتبة الأقل في هذه الحالة:

import 'theme / @ {theme}' ؛

الجسم {
الخلفية:primaryColor ؛
}

بهذه الطريقة يمكنني الحصول على yellow.less و default.less مع @ primaryColor : أصفر و @ primaryColor : أحمر.

في النهاية ، يمكنني كتابة مكتبتي باستخدام أسماء المتغيرات الدلالية مثل PrimaryColor وتقديم مجموعة من السمات مع تحديد تلك المتغيرات. وسيقوم مستخدم المكتبة فقط بتعريف اسم السمة في تطبيقه واستيراد أنماط المكتبة.

حسنًا ، فما باللك ، يبدو أنني حصلت عليه ، أنا فقط بحاجة إلى مزيج استيراد مثل هذا:

<strong i="6">@theme</strong>: 'default';

.imports(@theme) when (<strong i="7">@theme</strong> = 'yellow') {
    <strong i="8">@import</strong> "themes/yellow";
}
.imports(@theme) when (<strong i="9">@theme</strong> = 'default') {
    <strong i="10">@import</strong> "themes/default";
}
.imports(@theme);

Waterplea @ يمكنك تبسيط التعليمات البرمجية الخاصة بك إلى:

<strong i="7">@theme</strong>: default;

.imports(yellow) {<strong i="8">@import</strong> "themes/yellow";}
.imports(default) {<strong i="9">@import</strong> "themes/default";}
.imports(@theme);

لاحظ أيضًا اقتباسات مخفضة تمت إزالتها.

على الرغم من أن لأكون صادقًا ، لا أستطيع أن أرى كيف أن <strong i="13">@theme</strong>: yellow; (+ كل كود mixins) أفضل من مجرد خط <strong i="15">@import</strong> "themes/yellow"; الصريح. أي قبل كل شيء ، هل أنت على علم بالتجاوز ؟ أي أنك لست بحاجة إلى إخفاء <strong i="18">@import</strong> "themes/default"; الافتراضي ، إذا احتاج مستخدم مكتبتك إلى تطبيق yellow الأشياء - فهي تستورد المظهر الأصفر فقط (في أي مكان بعد ملف المكتبة الرئيسي ، ومرة ​​أخرى يكون نفس السطر الواحد) و voilà - تستخدم مكتبتك قيمًا متغيرة محددة في الملف الأصفر.

انتهى بي الأمر باستيراد اختياري لملف يتجاوز النسق أو يتحول إلى سمة معدة مسبقًا. في المشروع الذي يستخدم المكتبة ، نقوم بعد ذلك بتهيئة حزمة الويب لاستخدام الاسم المستعار لهذا الملف كوحدة عقدة إذا كان المشروع يحتاج إلى سمة مختلفة. ما كتبته من قبل أو ما كتبته لن ينجح في حالتنا لأننا نبني مجموعة أدوات واجهة المستخدم لـ Angular وهي معيارية للغاية. يمكننا استيراد زر واحد فقط أو تحديد عنصر تحكم ويجب أن يكون على دراية بالموضوع الذي نستخدمه بكل تغليف الأنماط. الحل سهل الإعداد لذلك أنا سعيد به.

ما كتبته لن ينجح في حالتنا لأننا نبني مجموعة أدوات واجهة المستخدم لـ Angular وهي معيارية للغاية.

_{لقد رأيت هذه الأوقات اللانهائية من قبل - إنها واحدة من أكثر المشاكل حزنًا (سوء الفهم) - يفتقد الناس فقط مبدأ التقييم الأقل كسولًا ، وبدلاً من استخدام أقل تجاوز طبيعي ، قم ببناء مكتبات ذات حقن ثقيل للملفات- أنماط التخصيص المستوحاة من عادات من لغات ذات دلالات متغيرة معاكسة مباشرة (مثل PHP و Sass وما إلى ذلك). يجب أن يكون الأمر أكثر من مجرد صراخ رجل باستمرار "يا رفاق ، لقد ارتكبتموه خطأ!"}

أحب أن أفهمها بشكل صحيح ، فأنا لا أدعي أنني أفهم كل شيء :) هل تهتم بشرح اقتراحك في المثال الخاص بي؟ هذا ما حصلنا عليه:

إليك مثال هيكلي أدنى:

مكتبة:

• استيراد
  <strong i="10">@import</strong> 'theme-default';
<strong i="13">@import</strong> 'mixins';
• الخلطات
  some mixins here like resetting default browser button styles
• موضوع - default.less
  <strong i="20">@primary</strong>: red;
<strong i="23">@secondary</strong>: blue;
• موضوع ثانوي
  <strong i="27">@primary</strong>: green;
<strong i="30">@secondary</strong>: yellow;
• زر مكون
  <strong i="34">@import</strong> 'import';
.button { color: @primary; }

المشروع 1 (يجب استخدام النسق الافتراضي):

• عنصر
  <strong i="42">@import</strong> 'import';
body { background: @secondary; }

المشروع 2 (يجب استخدام موضوع ثانوي):

• عنصر
  <strong i="50">@import</strong> 'import';
body { background: @secondary; }

تمت إضافة مكتبتنا كوحدة نمطية للعقدة وداخل المشروعات نقوم باستيراد مكون الزر فقط من المكتبة. نظرًا لأنها وحدة نمطية Angular لهذا الزر مع وجود ملف أقل خاص بها ، يتم تجميعها بشكل منفصل عن بقية المشروع 1 أو المشروع 2.

لقد كنت أفكر في هذا لفترة من الوقت ولم أتمكن من التوصل إلى طريقة لتنظيم ملفات أقل للسماح للمشروع 1 أو المشروع 2 بتعيين ملف السمة الذي يجب استخدامه عند تجميع كل من المكونات والتعليمات البرمجية الخاصة بالمشروعات. لا أرى طريقة لتجاوز أنماط مكون الزر من داخل كود المشروع.

لذا ، بدلاً من ذلك ، إليك بشكل أساسي ، كيف كتبت import.less:
<strong i="58">@import</strong> 'theme-default';
<strong i="61">@import</strong> 'mixins';
<strong i="64">@import</strong> (optional) '~custom-theme';

وضمن المشاريع ، إذا كنت أرغب في تجاوز متغيرات السمة لكل من كود المشاريع ومكونات المكتبة ، فأنا أطلق اسم مستعار على هذا الملف كوحدة نمطية باستخدام حزمة الويب. يمكن أن يحتوي هذا الملف على تجاوز صريح لـ sayprimary أو مجرد تبديل إلى سمة ثانوية:
<strong i="69">@import</strong> '~myLibrary/styles/theme-secondary';

لذا فأنا أعرف شيئًا عن التجاوز ، المشكلة هي - ليس لدى مستخدم المكتبة طريقة للدخول بين "أي مكان بعد ملف مكتبتك الرئيسية" ورمز مكون المكتبة. أفهم أن ما تقوله سيعمل مع أطر بدون تغليف للأنماط ، لكن بالنسبة إلى Angular ، إما أنه لن يعمل أو أساء فهم شيء ما في الحل الخاص بك.

أنا أرى. ثم نتحدث في الواقع عن نفس الشيء (فقط بكلمات مختلفة). بمجرد أن يتم تجميع buttonComponent (أو أي مكون آخر) بشكل منفصل ، يظل "مدير تخصيص المشروع" هو الملف import.less وقد فعلت بالضبط ما اقترحته. (بينما يتحول Project 1 و Project 2 ليكونا مجرد مكونات "أي شيء آخر" (أو "الكل في واحد"؟) من نفس المستوى مثل buttonComponent وليس تماما "المشاريع").

وبهذه الطريقة أقول إنك "فعلت ذلك بالشكل الصحيح" حسب ذوقي.

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة نظرًا لعدم وجود نشاط حديث لها. سيتم إغلاقه إذا لم يحدث أي نشاط آخر. شكرا لمساهماتكم.

تضمين التغريدة

من الناحية الفنية ، يتوفر مكون إضافي يطبق الميزة منذ عام 2015 . لكنني شخصيًا لم أختبرها أبدًا ، لذا من فضلك لا تلومني إذا حدث خطأ ما (إنه لمعلوماتك فقط).

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة نظرًا لعدم وجود نشاط حديث لها. سيتم إغلاقه إذا لم يحدث أي نشاط آخر. شكرا لمساهماتكم.

لذا ... عدت إلى هذا الخيط مرة أخرى ولا يمكنني تحديد ما إذا كانت هذه في الغالب حالات لأشخاص يسيئون فهم نطاق أقل أم لا.

لا أرى حقًا الحاجة إلى التحقق مما إذا كان قد تم تعريف vars. يجب تحديد الفارز إذا كان سيتم استهلاكها.

<strong i="7">@import</strong> "library";  // contains @library-color: blue;

@library-color: red;

.box {
  color: @library-color;
}

لا أفهم الحاجة إلى تعيين خاصية مشروطة بناءً على القيمة _changing_. إذا تم تعيين الخاصية على متغير ، ما عليك سوى تغيير قيمة المتغير.

بمعنى ، إذا كان library.less يحتوي على هذا:

@library-color: blue;
.box {
  color: @library-color;
}

كل ما يحتاجه شخص ما لضبط مخرجاته:

<strong i="16">@import</strong> "library";
@library-color: red;

هذا من شأنه أن ينتج:

.box {
  color: red;
}

هل يفهم البروتوكول الاختياري والآخرون في هذا الموضوع هذا السلوك؟

أعتقد أن حالة استخدام "does var موجود" هي نوع من الطريقة اللطيفة لعمل الإشارات. أي ، لا أعتقد أن هناك "خطأ" صريح من الناحية المفاهيمية. أو بالأحرى ، من غير المعتاد أن true هي القيمة الوحيدة "الحقيقة". بعبارة أخرى ، أعتقد أن الأمر يتعلق بالتعليم وليس السلوك.

أعتقد أننا يجب أن نفكر في إغلاق هذه المشكلة ، حيث يتم إصلاح ذلك عادةً بسطر واحد يعلن عن قيمة المتغير الافتراضية. على الرغم من التحرك نحو صفقة أكثر تساهلاً مع أقل v3.5 ، فربما يتم تقييم المتغيرات داخل الحراس بشكل أكثر تساهلاً؟

تصويتي لا ، رغم ذلك. يبدو أن @the-variable: false; هو كل ما تحتاجه OP لإضافته.

لأي شخص لديه أسئلة حول كيفية حل مشكلة معينة يشعر أنها مرتبطة بهذا ، لا تتردد في النشر على الأقل عمقًا و @ me.

حسنًا ، شكرًا للختامcalvinjuarez.

ما حدث أيضًا منذ أن كان مفتوحًا هو الوظيفة if() . لذا يمكنك عمل color: if((@variable), green, red);

@ Matthew-dean شكرًا جزيلاً لك على مراسلتنا بهذه النصيحة. لقد رأيت إضافة if () في ملاحظات الإصدار 3.0 ، لكنني لم أجعل الاتصال بهذه المشكلة ، والتي كانت لدي حالة فريدة من نوعها (ولكن ليس الوقت المناسب لإنشاء نسخة مصغرة من). مرة أخرى ، أقدر كثيرا جدا. أحسنت يا فريق LESS.

kbav لا مشكلة! نصيحة أخرى أعلى هذه النصيحة: عندما تم تقديم if() لأول مرة ، تطلب الأمر أقواس حول الشروط لأنها كانت في الأساس "تضمين" a when guard (كما هو الحال في ، الجزء بعد when في when (@variable) ). ومع ذلك ، فقد تم إصلاح ذلك اعتبارًا من أقل من 3.6 ، لذلك يمكنك كتابة المثال أعلاه بدون أقواس (إذا كنت تستخدم أحدث إصدار):

color: if(<strong i="10">@variable</strong>, green, red);