Less.js: Wachen erlauben, mit undefinierten Variablen zu arbeiten

+1
Dies könnte auch verwendet werden, um Basisfarben für Bibliotheken festzulegen.
Stellen Sie sich folgenden Fall vor:
Sie haben eine Less-Datei für eine bestimmte App, z. B. das Hauptmenü einer Website.
Sie importieren diese Less-Datei in die Haupt-Less-Datei, in der Ihre Grundfarben als Variablen definiert sind.
Wenn Sie nun diese Grundfarben in der Less-Datei des Hauptmenüs verwenden, hängen sie von der Hauptdatei ab.
Wenn Sie die Variablen auf Existenz überprüfen könnten, könnten Sie auf moduldefinierte Farben zurückgreifen.
Hier ist ein Beispiel dafür, wie ich mir die menülose Datei vorstelle:

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

+1, wir haben bereits istext , isnumber mit isdefined und isundefined werden sehr bei der Thematisierung mit weniger helfen.

Dh verwenden Sie value oder userValue wenn isdefined

Ich stoße häufig auf dieses Problem, wenn ich versuche, Themenkonventionen für die semantische Benutzeroberfläche mit LESS einzurichten.

+1 dazu - wäre wirklich toll.

+1 dazu auch für mich

Es ist keine große Sache, die Funktion is-defined hinzuzufügen (ich erwarte, dass sie in einem der ersten Plugins erscheint, sobald v2 veröffentlicht wird). Um ehrlich zu sein, ist das Traurige jedoch, dass diejenigen, die dieses Feature wollen, wirklich die Tatsache übersehen, dass beide oben genannten Anwendungsfälle (in vielen Fällen sogar mit kompakterem Code) ohne ein solches Feature lösbar sind.

Anwendungsfall von @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;

Anwendungsfall von @ 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...

Dh zusammenfassend: Anstatt zu testen, ob eine Variable definiert ist, geben Sie einfach einen Standardwert für diese Variable an, da Variablenwerte frei überschrieben werden können.

Kann jemand beantworten, warum das Beispiel von Max für sie nicht machbar ist? Ich kann nur
nehmen Sie an, weil Sie nicht wissen, ob die Variable oben definiert ist oder
unter dem Import ? Oder ist es etwas anderes?
Wir werden nichts betrachten, was keine Anwendungsfälle hat.
Der Nachteil dabei ist, dass Leute, die eine Variable falsch eingeben, keine sehen
Error. Wir könnten dies mit einer Warnung umgehen, aber dann, wenn Sie es getan haben
Zweck Sie möchten keine Warnung ... das ist mein einziges Problem damit
Anregung.

Dies ist besonders beim Definieren von Themen nützlich, um die Größe des resultierenden CSS zu reduzieren. Beim Erstellen von Themen im Allgemeinen möchte man viele Eigenschaften festlegen können. Benutzer möchten jedoch möglicherweise nur einige von ihnen festlegen und den Rest der Eigenschaften nicht festlegen. Natürlich würde es im Allgemeinen funktionieren, sie auf Standardwerte zu setzen, aber dies bläht das endgültige CSS auf.

Betrachten Sie das folgende Basisthema (Vorlage):

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

Der Benutzer des Themas möchte möglicherweise nur die Textfarbe festlegen und die restlichen Eigenschaften nicht festlegen. Natürlich ist es möglich, die Werte auf "initial", "transparent", "inherit" usw. zu setzen, jedoch erhöht dies die Größe des endgültigen CSS. Themen haben in der Regel Hunderte solcher Eigenschaften, sodass die Größe erheblich zunehmen kann.

@JechoJekov

Ich denke, Sie verfehlen den Sinn dieser Funktionsanfrage. Beachten Sie, dass Sie für Ihren Anwendungsfall immer noch jede dieser Eigenschaften schützen müssen (daher gilt die Begründung, die ich in zwei Posts oben vorgeschlagen habe, immer noch). Ich glaube also nicht, dass Ihr Anwendungsfall # 1400 etwas Neues hinzufügt (im Grunde sieht es so aus, als würden Sie eine andere Funktion wie "Eigenschaft überspringen, wenn alle Werte mit undefinierten Variablen festgelegt sind" oder ähnliches vorschlagen, aber es ist eine andere große Geschichte).

@Sieben-Phasen-max

Vielleicht wäre es am besten, wenn es möglich wäre, eine Variable auf einen "undefinierten" oder "ungesetzten" Wert zu setzen. Das Festlegen einer Eigenschaft auf einen solchen Wert würde bedeuten, dass die Eigenschaft im endgültigen CSS nicht gerendert wird. Dies vereinfacht die Syntax und ermöglicht die Überprüfung, ob die Variable deklariert ist.

@JechoJekov

Vielleicht wäre es am besten, wenn es möglich wäre, eine Variable auf einen "undefinierten" oder "ungesetzten" Wert zu setzen.

Wie ich bereits erwähnt habe, ist dies ein weiteres Feature, das ein eigenes Ticket benötigt (mit einer eigenen Diskussion).

Nur eine Klarstellung für die Roadmap: Diese ist als "ReadyForImplementation" gekennzeichnet, aber es scheint keinen Konsens in diesem Thread zu geben, und es sieht so aus, als hätte @seven-phases-max eine anständige Alternative vorgeschlagen. @lukeapage @seven-phases-max, sollte Ready for Implementation entfernt werden?

@matthew-dean Keine Ahnung. Ich nehme an, hier ist "ReadyForImplementation" immer noch irgendwie gültig, was so etwas wie "dieses Feature scheint nicht wirklich notwendig zu sein, aber wenn jemand mit einer PR kommt, die so etwas implementiert, wird es keinen Widerstand geben" oder so etwas :)

Wie ist das? (Unter Berücksichtigung)

„Bereit zur Umsetzung“ bedeutet für mich, dass ein allgemeiner (aber nicht notwendigerweise einstimmiger) Konsens darüber besteht, dass es angegangen oder umgesetzt werden _sollte_. Ich denke, "Under Consideration" trifft Ihre Definition.

Dieses Problem tritt immer noch bei der Verwendung von Scoping auf

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

Würde gerne isDefined verwenden können

Während so etwas wie is-defined sinnvoll ist (als syntaktischer Zucker), ist es nicht wirklich erforderlich. Definieren Sie einfach _immer_ @foo (mit dem Standardwert, den Sie benötigen), wenn Sie schließlich eine Variable in Ihren Stilen verwenden - Sie _können_ vorhersagen, dass Sie sie definieren müssen, z.

// 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;

Obwohl ich dies wahrscheinlich bereits in den obigen Beispielen geschrieben habe (ich versuche nur sicherzustellen, dass das Fehlen dieser Funktion kein Show-Stopper für irgendetwas sein kann. Wenn Sie einen Anwendungsfall kennen, wo es ist das eine, bitte teilen).

Ich versuche, Designvorschauen im Browser einzurichten.

Das bedeutet, dass ich less.js verwenden und die Standardvariable @theme mit Laufzeiteinstellungen überschreiben muss.

Ala

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

In meinem LESS importiere ich eine globale theme.less -Datei, die Folgendes enthält

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

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

Ich habe es auch gerade probiert

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

Im ersten Fall ist der ausgegebene Wert undefined im zweiten Fall ist es immer default , egal was in modifyVars eingestellt ist

Klicken Sie hier für ein Beispiel auf die Themen-Dropdown -Liste.

Die aktuelle Problemumgehung (die sich auf der Live-Site befindet) besteht darin, den Variablenimportpfad manuell zu erfassen und ihn mit Regexp zu analysieren und dann alle diese Variablen mit modifyVars zu importieren, da Sie sich vorstellen können, dass dies ziemlich chaotisch ist

@seven-phases-max Ich habe es auf einen sehr spezifischen Testfall eingegrenzt, bei dem @import Probleme verursacht.

Nehmen Sie in beiden Fällen an:

Javascript

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

Im ersten Fall in theme.less ist outer korrekt auf changedValue gesetzt

komponentenlos

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

theme.less

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

In diesem fehlgeschlagenen Fall wird in theme.less @theme auf default und nicht changedValue gesetzt

komponentenlos

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

theme.less

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

Im Fall von „var in mixin“ verwandelt sich das Snippet in:

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

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

Obwohl es für modifyVars immer 'someOtherValue' für jedes Snippet ergeben sollte, das Sie ausprobiert haben (weil modifyVars einfach funktioniert, indem die einfache Zeile <strong i="14">@theme</strong>: 'someOtherValue'; direkt am Ende der kompilierten Quellcode). Wenn also modifyVars nicht funktioniert, liegt das Problem höchstwahrscheinlich woanders.
Ich habe mir den button angesehen, aber er ist zu komplex, um schnell zu sagen, was möglicherweise falsch sein könnte. Auf den ersten Blick kann ich nicht sehen (oder kann es vielleicht einfach nicht verstehen), wie der Less-Code neu kompiliert und das resultierende CSS nach modifyVars erneut angewendet wird (in einfachen Ausschnitten erfolgt dies über less.refreshStyles nach modifyVars ).

Übrigens, nur für den Fall, sind Sie sicher, dass Sie nicht vorhaben, is-default als etwas zu verwenden wie:

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

? Wenn dies der Fall ist, besteht das Problem darin, dass solcher Code direkt gegen das Lazy-Evaluation-Prinzip verstößt ( is-defined sollte falsch zurückgeben, wenn die Variable nicht definiert ist, aber da sie in diesem Bereich sofort definiert _wird_, hat , is-defined auch um wahr zurückzugeben -> unlösbare Rekursion (Weitere Einzelheiten darüber, warum bedingte Imperativ-ähnliche Neudefinitionen in Less nicht sicher zugelassen werden können, finden Sie in #2072).
Das heißt, es könnte tatsächlich wie erwartet funktionieren (es sei denn, is-defined ist so codiert, dass es eine solche Rekursion explizit erkennt und verhindert), aber nur als eine Art unspezifiziertes/undefiniertes Verhalten, ohne Konsistenz mit normalen Variablensichtbarkeitsregeln, wodurch eine Gleichheit entsteht mehr Chaos.

@jlukic

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

Ja, das war auch einer meiner Vermutungen (Leider kann ich das gerade nicht testen, ich kann auch nicht erraten, wie das passieren könnte, aber ja, es ist möglich, weil die Verwendung von Variablen in Importen echte schwarze Magie ist. Ich werde eine dedizierte erstellen Bericht ausgeben, wenn dies das Problem ist).

Ich bin mir ziemlich sicher, dass es etwas mit dieser wunderbaren schwarzen Magie zu tun hat.

Ich habe mit sehr einfachen weniger Dateien zum Debuggen gearbeitet, hatte jedoch noch keine Gelegenheit, ein Testfall-Repo zu erstellen.

In meinen Tests ist der Fehler spezifisch für die Verwendung {@variable} -Werten beim Import, aber nicht in CSS-Eigenschaften.

Wenn Sie Themen mit weniger wirklich genießen, würden Sie diese Probleme gerne überwinden. Hier ist ein lustiges Themenbeispiel mit LESS, das ich letzte Woche im Meteor DevShop gezeigt habe (klicken Sie auf das Farbeimersymbol oben rechts).

@jlukic Ich habe es getestet und modifyVars funktioniert für vars in imports wie erwartet sowohl mit lessc als auch mit less.js (siehe Codepen-Demo , es ist ein bisschen kniffliger Code, da es musste Importieren Sie die beängstigende URL aus dem Kern , aber ich nehme an, es entspricht dem, was Ihre Seiten leisten sollen ... Es scheint also tatsächlich so, als ob das Problem woanders liegt).

Vielen Dank, dass Sie sich die Zeit genommen haben, den Testfall für mich zu erstellen. Das ist ziemlich eindeutig. Ich bin mir nicht sicher, was mit mir los ist. Ich muss nachforschen

Hat sich bei dieser Anfrage etwas getan? Ich habe seit einiger Zeit Angst vor einer undefinierten Variablenprüfung. Im Moment habe ich eine Arbeit, die alles andere als ideal ist ...

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

aber damit dies funktioniert, muss die Variable existieren und standardmäßig als null definiert sein. Dies wäre weitaus effektiver/flexibler, wenn ich stattdessen einfach prüfen könnte, ob die Variable überhaupt existiert.

+1

Zusammengefasst: Die Implementierung einer is-defined(name) (und/oder get-value-of(var-name, fallback-value-if-not-defined) ) Funktion innerhalb eines Plugins benötigt weniger als 15 Codezeilen. Also mach das einfach, wenn du mutig genug bist.

+1 dazu. Gibt es diesbezüglich Fortschritte als Plugin? Ich meine, @seven-phases-max, du kennst den Code besser als die meisten Mitwirkenden, denke ich. Wenn es ungefähr 15 Codezeilen erfordert, warum wurde es noch nicht gemacht?

Wenn es ungefähr 15 Codezeilen erfordert, warum wurde es noch nicht gemacht?

Weil es niemanden wirklich interessiert? Jedes Feature ist cool und "extrem nützlich", wenn jemand anderes dies für Sie erledigt ... Aber es wird auf magische Weise nicht so wichtig, wenn es um Ihre eigene Zeit geht ;)

Sie kennen den Code besser als die meisten Mitwirkenden

Das bedeutet nicht, dass ich etwas von meinem eigenen Interesse hinter etwas von jemand anderem Interesse stellen muss, sorry (insbesondere wenn das etwas Ermutigendes ist, was ich persönlich als Missbrauch/Bad-Code-Stil behandle).

Um nicht leer zu klingen, für den Anwendungsfall von @ashenden : Hier ist der richtige Weg, um einen beliebigen Regelsatz so zu gestalten, dass er von "Unbekannten" angepasst werden kann (offensichtlich unter der Annahme eines Falls, in dem normales CSS-Überschreiben aus irgendeinem Grund nicht anwendbar ist), ohne dass dies fehlerhaft ist Idee von "jeden CSS-Wert blind in eine Variable verschieben und etwas verwenden, das Sie nicht verwenden" (ich werde nicht ins Detail gehen, warum es eigentlich kaputt ist, da es eine Geschichte dafür ist ein langer Blogbeitrag).

Es gibt ein Konzept, das normalerweise "Hooks" heißt, also das folgende "can't make my mind up festival":

// .............................................
// 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?

sollte ersetzt werden durch:

// .............................................
// 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}

Zähle die Linien, zähle die Möglichkeiten, zähle die Grenzen.
Das heißt wirklich, wenn Sie einige CSS-Eigenschaften nicht verwenden, lassen Sie sie bitte einfach in Ruhe für diejenigen, die es tun werden .

Leute, hier bin ich darauf gestoßen. Bitte werfen Sie einen Blick auf dieses Beispiel und sagen Sie mir, ob es sich um einen gültigen Fall handelt und nicht ohne is-undefined behoben werden kann.

Ich möchte Themen in eine Bibliothek wie dieses Modul laden:

In meiner Core-App definiere ich die Variable @theme : 'yellow' und importiere dann die Bibliothek weniger.

Und so könnte Bibliothek weniger in diesem Fall aussehen:

@import 'Themen/@{Thema}';

Karosserie {
Hintergrund: @primaryColor;
}

Auf diese Weise könnte ich yellow.less und default.less mit @primaryColor : yellow und @primaryColor : red haben.

Am Ende kann ich meine Bibliothek mit semantischen Variablennamen wie primaryColor schreiben und eine Reihe von Designs mit diesen definierten Variablen bereitstellen. Und der Bibliotheksbenutzer würde einfach den Themennamen in seiner App definieren und Bibliotheksstile importieren.

Ok, egal, sieht so aus, als hätte ich es verstanden, ich brauche nur ein Import-Mixin wie dieses:

<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 Sie können Ihren Code folgendermaßen vereinfachen:

<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);

Beachten Sie auch die entfernten redundanten Anführungszeichen.

Obwohl ich ehrlich gesagt nicht sehen kann, wie <strong i="13">@theme</strong>: yellow; (+ der gesamte Mixins-Code) besser ist als nur die explizite Zeile <strong i="15">@import</strong> "themes/yellow"; . Dh zunächst einmal sind Sie sich der Vorrangigkeit bewusst? Das heißt, Sie müssen die Standardeinstellung <strong i="18">@import</strong> "themes/default"; nicht ausblenden, wenn Ihr Bibliotheksbenutzer yellow -Zeug anwenden muss - sie importiert einfach Ihr gelbes Design ( irgendwo nach Ihrer Hauptbibliotheksdatei, und wieder ist es die dieselbe Zeile) und voilà - Ihre Bibliothek verwendet Variablenwerte, die in der gelben Datei angegeben sind.

Ich endete mit einem optionalen Import einer Datei, die das Design überschreibt oder zu einem voreingestellten Design wechselt. In einem Projekt, das die Bibliothek verwendet, konfigurieren wir dann das Webpack so, dass es den Alias ​​dieser Datei als Knotenmodul verwendet, wenn das Projekt ein anderes Thema benötigt. Was ich zuvor geschrieben habe oder was Sie geschrieben haben, würde in unserem Fall nicht funktionieren, da wir ein UI-Kit für Angular erstellen und es sehr modular ist. Wir können nur eine Schaltfläche importieren oder ein Steuerelement auswählen, und es muss sich des von uns verwendeten Themas mit all seinen Stilkapselungen bewusst sein. Die Lösung ist einfach einzurichten, also bin ich damit zufrieden.

Was Sie geschrieben haben, würde in unserem Fall nicht funktionieren, da wir ein UI-Kit für Angular erstellen und es sehr modular ist.

_{Ich habe das schon unendlich oft gesehen - es ist eines der traurigsten Less (Miss-)Verständnisprobleme - die Leute vermissen einfach das grundlegende Less Lazy-Evaluation-Prinzip und konstruieren, anstatt das natürliche Less-Überschreiben zu verwenden, Bibliotheken mit schwerem File-Injection. basierte Anpassungsmuster, inspiriert von Gewohnheiten aus Sprachen mit direkt entgegengesetzter variabler Semantik (wie PHP, Sass usw.). Es muss etwas mehr sein als nur ein Typ, der ständig schreit: "Leute, ihr macht es falsch!"}

Ich würde es gerne richtig machen, ich behaupte nicht, dass ich alles verstehe :) Möchtest du deinen Vorschlag an meinem Beispiel erklären? Hier ist, was wir bekommen haben:

Hier ist ein minimales strukturelles Beispiel:

Bücherei:

• import.weniger
  <strong i="10">@import</strong> 'theme-default';
<strong i="13">@import</strong> 'mixins';
• mixins.weniger
  some mixins here like resetting default browser button styles
• theme-default.less
  <strong i="20">@primary</strong>: red;
<strong i="23">@secondary</strong>: blue;
• theme-secondary.less
  <strong i="27">@primary</strong>: green;
<strong i="30">@secondary</strong>: yellow;
• SchaltflächeKomponente
  <strong i="34">@import</strong> 'import';
.button { color: @primary; }

Projekt 1 (muss Standarddesign verwenden):

• Komponente
  <strong i="42">@import</strong> 'import';
body { background: @secondary; }

Projekt 2 (muss sekundäres Thema verwenden):

• Komponente
  <strong i="50">@import</strong> 'import';
body { background: @secondary; }

Unsere Bibliothek wird als Knotenmodul hinzugefügt und innerhalb von Projekten importieren wir nur die Schaltflächenkomponente aus der Bibliothek. Da es sich um ein Angular-Modul für diese Schaltfläche mit einer eigenen Less-Datei handelt, wird es getrennt vom Rest von Projekt 1 oder Projekt 2 kompiliert.

Ich habe eine Weile darüber nachgedacht und konnte keine Möglichkeit finden, weniger Dateien zu organisieren, damit Projekt 1 oder Projekt 2 festlegen können, welche Designdatei verwendet werden soll, wenn sowohl Komponenten als auch eigener Code des Projekts kompiliert werden. Ich sehe keine Möglichkeit, Stile für die Schaltflächenkomponente im Code von Project zu überschreiben.

Stattdessen habe ich im Grunde genommen import.less so geschrieben:
<strong i="58">@import</strong> 'theme-default';
<strong i="61">@import</strong> 'mixins';
<strong i="64">@import</strong> (optional) '~custom-theme';

Und innerhalb von Projects, wenn ich Designvariablen sowohl für Projects-Code als auch für Bibliothekskomponenten überschreiben möchte, aliasiere ich diese Datei als Modul mit Webpack. Diese Datei könnte eine explizite Überschreibung von beispielsweise @primary oder nur einen Wechsel zum sekundären Thema haben:
<strong i="69">@import</strong> '~myLibrary/styles/theme-secondary';

Ich weiß also über das Überschreiben Bescheid, das Problem ist - der Benutzer der Bibliothek hat keine Möglichkeit, zwischen "irgendwo nach Ihrer Hauptbibliotheksdatei" und dem Code der Bibliothekskomponente zu gelangen. Ich verstehe, dass das, was Sie sagen, für Frameworks ohne Stilkapselung funktionieren würde, aber für Angular würde es entweder nicht funktionieren oder ich habe etwas in Ihrer Lösung falsch verstanden.

Ich verstehe. Dann sprechen wir eigentlich von der gleichen Sache (nur mit anderen Worten). Sobald buttonComponent (oder eine andere Komponente) separat kompiliert wird, bleibt "der Projektanpassungsmaster" die Datei import.less und Sie haben genau das getan, was ich vorgeschlagen habe. (während Project 1 und Project 2 sich als weitere „alles andere“ (oder „all-in-one“?) Komponenten auf der gleichen Ebene wie buttonComponent und nicht ein ziemliches "Projekt").

Dh auf diese Weise würde ich sagen, Sie haben es nach meinem Geschmack "richtig gemacht".

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität gab. Es wird geschlossen, wenn keine weiteren Aktivitäten stattfinden. Vielen Dank für Ihre Beiträge.

@stalePing .

Technisch gesehen ist seit 2015 ein Plugin verfügbar, das das Feature implementiert. Aber persönlich habe ich es nie getestet, also beschuldigen Sie mich bitte nicht, wenn etwas schief geht (es ist nur zu Ihrer Information).

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität gab. Es wird geschlossen, wenn keine weiteren Aktivitäten stattfinden. Vielen Dank für Ihre Beiträge.

Also ... Ich habe diesen Thread noch einmal überflogen und kann nicht wirklich feststellen, ob dies hauptsächlich Fälle sind, in denen Leute Less scope missverstehen oder nicht.

Ich sehe nicht wirklich die Notwendigkeit zu überprüfen, ob vars definiert sind. Vars sollten definiert werden, wenn sie verbraucht werden sollen.

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

@library-color: red;

.box {
  color: @library-color;
}

Ich verstehe nicht die Notwendigkeit, eine Eigenschaft basierend auf dem Wert _changing_ bedingt festzulegen. Wenn die Eigenschaft auf eine Variable gesetzt ist, ändern Sie einfach den Wert der Variablen.

Das heißt, wenn library.less dies hat:

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

Alles, was jemand tun müsste, um seine Ausgabe einzustellen:

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

Dies würde ausgeben:

.box {
  color: red;
}

Versteht das OP und andere in diesem Thread dieses Verhalten?

Ich denke, der Anwendungsfall "existiert var" ist eine nette Art, Flags zu machen. Das heißt, ich glaube nicht, dass es ein konzeptionell geradliniges "falsey" gibt. Oder besser gesagt, es ist ungewöhnlich, dass true der einzige "wahre" Wert ist. Mit anderen Worten, ich denke, es ist eher eine Frage der Erziehung als eine Frage des Verhaltens.

Ich denke, wir sollten in Betracht ziehen, dieses Problem zu schließen, da dies normalerweise mit einer Zeile behoben wird, die den Standardvariablenwert deklariert. Obwohl sich Less v3.5 in Richtung eines freizügigeren Deals bewegt, werden vielleicht Variablen innerhalb von Wächtern freizügiger bewertet?

Meine Stimme ist jedoch nein. @the-variable: false; scheint alles zu sein, was OP hinzufügen muss.

Alle, die Fragen zur Lösung eines bestimmten Problems haben, von dem sie glauben, dass es damit zusammenhängt, können es gerne auf the less gitter und @me posten.

Okay, Schluss, danke @calvinjuarez.

Was auch passiert ist, seit dies geöffnet wurde, ist die Funktion if() . Sie können also color: if((@variable), green, red); tun

@matthew-dean Vielen Dank, dass Sie sich mit diesem Tipp gemeldet haben. Ich habe die Hinzufügung von if() in den 3.0-Versionshinweisen gesehen, aber keine Verbindung zu diesem Problem hergestellt, für das ich einen einzigartigen Fall hatte (aber nicht die Zeit, eine reduzierte Version davon zu erstellen). Wieder sehr geschätzt. Gut gemacht, LESS-Team.

@kbav Kein Problem! Ein weiterer Tipp zusätzlich zu diesem Tipp: Als if() zum ersten Mal eingeführt wurde, waren Klammern um Bedingungen erforderlich, da es im Grunde genommen darum ging, einen when-Wächter "einzubetten" (wie in dem Teil nach when in when (@variable) ). Dies wurde jedoch ab Less 3.6 behoben, sodass Sie das obige Beispiel ohne Klammern schreiben können (wenn Sie mit der neuesten Version kompilieren):

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