Less.js: Unterstützung für „default“-Variablen hinzugefügt (ähnlich wie !default in SASS)

Siehe Die Dokumentation .

Update: Meinen vorherigen Kommentar dieses Beitrags entfernt, um zukünftige Besucher nicht zu verwirren (hier habe ich versucht, die Frage „Wie definiere ich eine Variable, wenn sie noch nicht definiert ist“ zu beantworten, und den Punkt verpasst, dass es sich um ein „XY-Problem“ und die richtige Antwort für a handelt Sass-like !default ist: in Less braucht man so etwas nicht, weil die notwendige Funktionalität ("(Neu-)Definition nach Gebrauch") bereits durch die Funktionsweise von Less-Variablen bereitgestellt wird).

Wenn Sie dieselbe Variable zweimal definieren, gewinnt die letzte Deklaration und ist im gesamten Gültigkeitsbereich gültig. Eine andere Möglichkeit wäre also, Variablen normal zu deklarieren und den Benutzer zu bitten, seine Variablen nach Ihrer Bibliothek einzufügen.

Bibliothek.weniger

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

user.less:

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

kompiliert in:

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

Vielen Dank für das Feedback zu unserer PR. Diese Lösungen wären praktikabel, wenn wir eine einzige Sache oder ein paar kleine Dinge zu konsumieren hätten. Lassen Sie mich also erläutern, warum diese Lösungen in unserem Fall nicht praktikabel sind.

Wir erstellen ein großes Framework von Komponenten, die als Klassenhierarchie implementiert sind. Wir deklarieren die Variablen für jede Komponente in einer eigenen Datei ... in unserem Basisdesign. Daraus „leiten“ wir dann Themes ab, die diese Variablen modifizieren wollen. Benutzer können dies auch tun, um ein Thema an ihre Bedürfnisse anzupassen.

Außerdem "leiten" sich Variablen oft von anderen Variablen ab. Das offensichtlichste ist die Grundfarbe. Wir haben viel Zeit damit verbracht, Alternativen zu den Problemen großer Klassenhierarchien von Komponenten zu diskutieren, die eine aggressive Weitergabe von Variablenwerten in Kombination mit Themen und ihrem eigenen Vererbungsverhalten verwenden.

Die bei weitem beste Lösung für diese Probleme ist es, Variablen _immer_ als "!default" (in Sass-Begriffen) zu definieren. Dadurch können Benutzer einfach zuerst einsteigen und ihre Werte festlegen, bevor diese Werte zur Berechnung weiterer Werte verwendet werden. Das Timing ist dann für unsere Nutzer ganz einfach zu verwalten. Da dies immer für jede Variable in allen unseren Themen der Fall ist, wären Syntaxkämpfe wie die oben vorgeschlagenen ziemlich mühsam und auch fehleranfällig.

Wir würden gerne andere Funktionen zu Less beitragen, während wir fortfahren. Ich denke, unser (ungewöhnlich?) großer Anwendungsfall könnte eine hilfreiche Validierung dessen sein, was zur Skalierung der Sprache / des Funktionsumfangs erforderlich ist.

Ich hoffe, Sie erwägen, dies zusammenzuführen oder einige Alternativen bereitzustellen, die deklarativer Natur sind. Das Ausnutzen von Scope-Tricks wird für uns wirklich nicht funktionieren.

Nochmals vielen Dank für Ihre Zeit und Überlegung!

Es scheint, dass Sie besser dran sind, Mixins zu definieren, als reine Klassen. Dann können Variablen spät in Ihrem Haupt-Stylesheet oder einem anderen abgeleiteten Thema überschrieben werden. Auf diese Weise kann ich Dinge wie meine Dachrinnenbreiten in meinen Rastern überschreiben, nachdem ich sie importiert habe.

Nur zur Verdeutlichung sprechen wir hier nur über Variablen. Und wir haben kein Haupt-Stylesheet – wir haben eines pro Klasse und Thema. :)

Vielleicht folge ich Ihrem Vorschlag nicht, aber als Beispiel sieht eine unserer Design-Variablendateien so aus:

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

Diese Datei richtet die verschiedenen Panel-Werte für ein Thema ein, das eine Kette von Basisthemen mit einer Tiefe von 4 hat. Diese Basisthemen haben ihre eigenen Variablenwerte für das Panel, aber diese werden zuerst geladen, also überschreiben Sie sie. Es sei denn, ein Benutzerthema leitet sich von diesem Thema ab und bietet eigene Werte.

Dieses Muster wiederholt sich _oft_ :)

Okay, warum überschreiben Sie nicht einfach @panel-base-color in Ihrem Haupt-Leser-Blatt? LESS-Variablen sind global, also gewinnt derjenige, der zuletzt eintritt.

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

@panel-base-color: red;

Jetzt werden alle im Design verwendeten Elemente überschrieben. Wenn dies in Ihrer Importkette von niemandem außer Kraft gesetzt wird, wird die ursprüngliche Einstellung die Standardeinstellung sein.

Wir haben kein "Mainless Sheet" :) Ich schätze Ihre Hilfe und Vorschläge, aber wir haben intern viele Diskussionen darüber geführt und sie neigen dazu, eine Weile zu dauern. Es genügt zu sagen, dass wir glauben, dass wir eine Standardvariableneinstellung benötigen, wie wir sie hier vorgeschlagen haben. Diese Funktion existiert in Sass und wir fanden sie sehr hilfreich, um die Komplexität zu reduzieren und den Benutzern Flexibilität bei der Konfiguration unserer Themen zu bieten.

Ich bin neugierig, ob dies alles bedeutet, dass dieser Pull-Request oder ein ähnliches Derivat jemals akzeptiert würde? Wir passen die Syntax gerne an, wenn dies nicht in Ordnung ist.

Wir haben kein "main less sheet" :)

Ersetzen Sie in den obigen Antworten einfach "Ihr Hauptblatt weniger" durch "eines der weniger Blätter des Benutzers". Bisher scheint es, dass SASS !default (welche Syntax auch immer es hat) erfunden wurde, um ein Problem zu lösen, das in LESS nicht existiert.
@dongryphon , ich kann mich natürlich irren, aber Sie haben noch nicht begründet, warum Sie die von @SomMeri und @Soviut vorgeschlagene Lösung nicht verwenden können.

Um es anders auszudrücken, stellen Sie sich vor, Sie würden nicht importieren und stattdessen alle Ihre Variablen in demselben Blatt haben. Genau das bewirkt der Import. Wenn Sie also in dieser Situation zwei Variablendeklarationen mit demselben Namen hätten, würde die letzte im Blatt gewinnen.

@base-color: green;

div {
    background: @base-color;
}

@base-color: red;

Da die Basisfarbe am Ende erneut deklariert wird, ist die im div verwendete Basisfarbe rot. Es wird kompiliert zu:

div {
    background: red;
}

Dies kam schon früher vor, ich glaube sogar, dass es sogar implementiert wurde, und wir hatten eine Pull-Anfrage von Leuten, die es in Bootstrap wollten, und sie stimmten nach einiger Diskussion zu, dass es ein sinnloses Feature in weniger war.

Das Einzige, was Sie tun können, ist, dass Benutzer vor dem Importieren Variablen definieren. Wenn Benutzer danach Überschreibungen definieren, funktioniert es so, als hätte es einen Standardwert. Das liegt daran, dass selbst in der importierten Datei die letzte Definition auf die gleiche Weise wie CSS übernommen wird, auch wenn sie nach der Verwendung definiert wird.

Es ist für Benutzer einer Bibliothek keine große Belastung zu sagen, dass sie Variablen nach Importen überschreiben (oder eine Variablendatei nach Importen importieren) oder weniger Syntax hinzufügen. Wir denken, dass dies einer der Vorteile von weniger ist, die Sie können machen die gleiche Menge wie sass, aber meistens mit einfacherer Syntax.

Dies widerspricht dem, was ein JavaScript-Programmierer vielleicht denken mag, aber die Idee dahinter ist, dass es CSS näher kommt.

Können Sie bitte erläutern, warum es nicht möglich oder wünschenswert ist, Verbraucher zu bitten, eine Bestellung in Betracht zu ziehen? Wir werden Funktionen mit starken Anwendungsfällen akzeptieren, aber wir müssen rigoros vorgehen, um ein Aufblähen von Sprache und Komplexität zu vermeiden.

Siehe #1109 #1104 #313

Und nur um das klarzustellen, wir sagen keineswegs „nein“. Wir versuchen zu zeigen, dass diese Funktion möglicherweise bereits vorhanden ist.

Ich habe einige Informationen zu less-docs hinzugefügt

Schließen als bereits verfügbares (in "Less way") Feature (http://lesscss.org/features/#variables-feature-default-variables).

Ich denke, diese Verwirrung kommt oft auf, weil SASS zwar eine überlappende _Syntax_ hat, aber von oben nach unten "ausführt", LESS jedoch nicht und stattdessen eher wie CSS funktioniert. LESS ist wie CSS+ (CSS mit zusätzlichen Funktionen) und SASS ist wie "PHP mit CSS-Syntax". Ich frage mich, ob es (falls erforderlich) eine Möglichkeit gibt, diese Unterscheidung zu treffen.

Können Sie bitte erläutern, warum es nicht möglich oder wünschenswert ist, Verbraucher zu bitten, eine Bestellung in Betracht zu ziehen? Wir werden Funktionen mit starken Anwendungsfällen akzeptieren, aber wir müssen rigoros vorgehen, um ein Aufblähen von Sprache und Komplexität zu vermeiden.

Weil wir Bibliotheksbenutzern (und Verbrauchern) beibringen, Bibliothekscodes niemals selbst zu bearbeiten. Das fehlende !default -Feature bedeutet, dass wir eines dieser beiden Dinge tun müssen - beide gleich schlecht imo:

• Die Benutzer müssen das Stylesheet der Bibliothek selbst bearbeiten, um die Variablen dort zu bearbeiten, wo sie deklariert sind (was irgendwie verboten ist, was Bibliotheksaktualisierungen erschwert) oder,
• Die Bibliothek muss zwei Stylesheets bereitstellen: eines für Standardvariablen und eines für tatsächliche Regeln. Dann muss der Benutzer die erste @importieren , dann seine eigenen Variablen deklarieren und dann die zweite @importieren . Es ist komplexer als es sein sollte, insbesondere diese beiden Dateien in derselben Version zu halten.

Der Sass-Ansatz bedeutet, dass eine Bibliothek nur eine einzige Datei bereitstellen muss, die der Benutzer dann anpassen kann.

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

Anstatt:

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

Ich denke, dass Sie dieses Thema noch einmal überdenken sollten.

@arcanis Eigentlich verstehe ich nicht, warum du das denkst:

Die Bibliothek muss zwei Stylesheets bereitstellen: eines für Standardvariablen und eines für tatsächliche Regeln.
Der Sass-Ansatz bedeutet, dass eine Bibliothek nur eine einzige Datei bereitstellen muss

In Less ist es absolut das gleiche Bibliotheksdesign:

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

Ich denke, Sie vermissen einfach das "Lazy-Loading"-Ding (und genau das gleiche Beispiel wird in der Dokumentation verwendet, um no, thanks! bis !default zu sagen).

Ich denke, Sie vermissen einfach das "Lazy-Loading"-Ding

@seven-phases-max WTF, du hast recht. Verdammt, ich sollte wahrscheinlich meine gesamte Antwort löschen (und habe es gerade getan). Sie sagen mir, Sie können Bootstrap importieren und bestimmte Variablen einfach überschreiben, und es wird einfach funktionieren?

Ich habe Ihnen nicht geglaubt und meine eigenen Tests durchgeführt, um es zu überprüfen. Wie habe ich das übersehen?? Ich denke, das liegt daran, dass jeder Artikel, den ich auf Bootstrap gesehen habe, der Anpassungen beinhaltete, empfohlen hat, dass Sie die Datei variables.less kopieren und Ihre eigenen Werte festlegen, was natürlich Probleme verursacht, wenn der Bibliothek weitere Variablen hinzugefügt werden. Und ich glaube, ich hatte den Eindruck, dass Selektoren am unmittelbaren Importpunkt ausgegeben wurden. Haben Variablen immer auf diese Weise „geladen“?

Dies muss die wichtigste, am häufigsten vermisste Funktion in Less sein. Ich habe noch nie einen Blogbeitrag über Less oder eine Less-Bibliothek gesehen, in dem diese Funktion erwähnt wird. Selbst mit allem in diesem Thread und der Dokumentation war nicht sofort klar, was das mit realen Bibliotheken bedeutet. Ich dachte, alle sagten einfach, Sie könnten früher deklarierte Variablen überschreiben, indem Sie sie später setzen, und ich habe nie verstanden, dass dies die Auswertung von Variablen aus früher importierten Dokumenten beeinflussen würde.

Ich kann nicht glauben, dass ich das bis jetzt nie bekommen habe. Dies ändert im Grunde alles daran, wie ich meine wenigeren Dokumente strukturiere, und es gibt eine winzige Erwähnung in den Dokumenten, die keine Ausgabe demonstriert.

Vielleicht erhalten wir so viele Anfragen nach einer !default -Funktion in Less, weil nur wenige Leute diese Funktion intuitiv verstehen oder sie anhand des kurzen Beispiels aus der Dokumentation verstehen (einschließlich mir natürlich).

Zumindest danke für die nochmalige Erklärung @seven-phases-max!

Hoppla. Nun, du hast recht. Ich habe die Dokumente auch falsch verstanden, mein Fehler!

@Soviut du bist ein verdammtes Genie! Ich hatte keine Ahnung, dass Variablendeklarationen in SASS/LESS so funktionieren. Danke!

Ich klopfe mir immer noch auf die Stirn, dass dies kein offensichtliches Verhalten war, bei allem anderen, was ich in Less geschrieben habe. Ich denke, mein Problem war, dass ich schlechte Beispielartikel gesehen hatte, die von Leuten geschrieben wurden, die nicht verstanden, wie man es macht.

Beachten Sie auch: @spikesagal zu Ihrer Aussage: "Ich hatte keine Ahnung, dass Variablendeklarationen in SASS/LESS so funktionieren" - Nach meinem besten Wissen ist das Verhalten von Variablen zwischen den beiden Sprachen nicht gleich SASS und LESS bewerten die Dinge sehr unterschiedlich.

Und sie beenden dieses Feature in BS4, weil sie zu Sass wechseln... :-1: Immer noch ziemlich traurig über diesen Schritt.

So beginnt der Kampf um mehr !default-Variablen: [twbs/bootstrap#17418]

Nun, sie können die Less-Funktion nicht beenden, indem sie die SCSS-Quellen auf welche Weise auch immer ändern. (Technisch gesehen ist es nicht einmal ein "Merkmal" (wie eine Art "synthetisiertes Verhalten"), sondern eine grundlegende Eigenschaft/Folge der faulen Bewertung). Solange es eine Less-Version von BS gibt (das ist nur eine Frage der Anzahl der Personen, die bereit sind, dazu beizutragen) und es mindestens eine globale Variable gibt, können Sie diese Variable immer überschreiben.

Brunnen. Die offizielle v4-alpha von Bootstrap ist nach Sass umgezogen. Das tötet, zumindest nach meinem Verständnis, weniger in ihrer offiziellen Dokumentation - und das bedeutet auch, die Unterstützung für dieses Feature zu beenden, da Sass keine Lazy-Loading-Variablen hat. Sie unterstützen nur !default, was in gewisser Weise bedeutet: „Oh ja, wir erlauben Ihnen, unsere Variablen nur einmal von außen zu überschreiben, und nur, wenn wir dies zulassen. Wenn wir also vergessen, Ihnen Zugriff auf B. eine Variable, indem Sie einfach !default weglassen, sind Sie ziemlich am Arsch und müssen den ganzen verdammten Selektor in Ihren Dateien überschreiben.

und das bedeutet auch, die Unterstützung für dieses Feature zu beenden, da Sass keine Lazy-Loading-Variablen hat.

Nun, das bedeutet nur "sie töten es in Bootstrap" (was offensichtlich außerhalb dieses Threadbereichs liegt - solange es keine Less-Version von BS gibt, sollten wir uns nicht um die Bootstrap-Funktionen in _diesem_ Repository kümmern, oder?).

Da es in dieser Diskussion ziemlich viel um das Überschreiben von Variablen in Bootstrap ging ...

Wir bleiben bei weniger :smile:

Ich habe einen Anwendungsfall für das ursprünglich genannte Dilemma. Betrachten Sie das folgende vereinfachte Beispiel:

1. Ich habe eine Less-Datei, die die Schriftgröße von h1 definiert, etwa so
   <strong i="8">@font_size__h1</strong> = 30px;
2. Ich habe (in Ermangelung eines besseren Ausdrucks) ein Plugin, das eine separate LESS-Datei enthält, die die Deklaration @font_size__h1 verwendet. Also <strong i="12">@import</strong> (reference) "path/to/file.less"; es. Kein Problem, es ist jetzt verfügbar.
3. Jetzt nehme ich dieses "Plugin" in eine neue Site, für die nirgendwo @font_size__h1 definiert ist. An dieser Stelle wäre es großartig zu sagen: "Wenn @font_size__h1 definiert ist, verwenden Sie diesen Wert. Wenn er nicht definiert ist, verwenden Sie den Wert, den ich hier definiere."

Punkt 3 ist derzeit nicht möglich, soweit ich das sehe.

@theMikeD

Punkt 3 ist derzeit nicht möglich, soweit ich das sehe.

Anscheinend hast du den Thread nicht gelesen:

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

was natürlich reduziert werden kann auf:

<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

Dies ist im Grunde das gleiche Beispiel wie http://lesscss.org/features/#variables -feature-default-variables

Ja, ich habe den Thread gelesen. Sieht so aus, als ob Sie nicht verstehen, was ich frage, weil Ihr Beispiel meine Frage rückwärts stellt.

was natürlich reduziert werden kann auf:
@import "Pfad/zu/Datei.less"; // <- dort Defaultwert definieren
@font-size-h1: foo; // Wenn es hier nicht definiert ist, verwenden Sie den oben definierten Wert

Das ist das Gegenteil von dem, was ich brauche. Dadurch wird der Wert von @font-size-h1 in path/to/file.less in jedem Fall mit dem lokalen Wert überschrieben. Was ich brauche, ist der Wert in der lokalen Datei, der nur verwendet wird, wenn:
a) path/to/file.less wird nicht geladen, oder
b) den Wert von '@ font_size__h1 is not set in path/to/file.less'

IOW wird der lokale Wert von @font-size-h1: foo; immer in der lokalen Datei vorhanden sein, sollte aber überschrieben werden, wenn er in path/to/file.less gesetzt ist

Auf jeden Fall habe ich gestern Abend die Lösung gefunden, nämlich zuerst den lokalen Wert zuzuweisen und dann die @import -Anweisung an das Ende der Datei zu stellen, nicht an den Anfang. Falls gefunden, wird der lokale Wert überschrieben.

Danke trotzdem.

Sieht so aus, als verstehst du nicht, was ich frage

Ich würde Ihnen eher vorschlagen, mit einigen weniger variablen Grundlagen zu beginnen, um Ihre Ansicht aufzufrischen:

• Lazy-Evaluation
• Variable Semantik
• Die am meisten missverstandenen ...

(weil es scheint, dass Sie nur versuchen, an alles auf eine imperative C/PHP-ähnliche Weise zu denken, während es in Less/CSS völlig "deklarativ auf dem Kopf steht").
Es wurde all die Jahre bis zum Äußersten geredet, !default kann _nichts_ Neues hinzufügen, wenn man es mit dem nativen Less-Variablenüberschreiben vergleicht. Zeitraum. (Wir waren schon oft dort: Wenn jemand glaubt, er habe in Less einen Anwendungsfall für !default gefunden, bedeutet das nichts anderes als sein Missverständnis der Variablensemantik von Less).

Was ich brauche, ist der Wert in der lokalen Datei, der nur verwendet wird, wenn:
a) path/to/file.less wird nicht geladen, oder
b) der Wert von @ font_size__h1 ist nicht in path/to/file.less gesetzt

Dann ist es einfach umgekehrt:

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

tada!

...wo ich gelandet bin, wie gesagt.

Ich wollte den Artikel vorschlagen, den ich geschrieben habe, und sah dann, dass @seven-phases-max darauf verlinkt hatte. 😄 Vertrauen Sie uns, das, wonach Sie fragen, existiert bereits! Aber Sie müssen die Variablenauswertung von Less verstehen, um zu verstehen, wie/warum sie existiert.

Ich habe eine Komponente - das ist ein Datenraster. Diese Komponente sollte ein Standard-Styling haben – definiert durch das Komponentenpaket. Aber wenn eine bestimmte Variable von außen bereits definiert ist, sollte diese Priorität haben.

app.less
/grid/grid.less

Da das Grid eine Komponente ist, vergessen Sie, hier etwas hinzuzufügen - oder Code nach der Datei grid.less hinzuzufügen.
Ich sehe nicht, wie weniger dieses Problem abdeckt. Scss bietet diese Funktion aus gutem Grund an.

@geri777

Aber wenn eine bestimmte Variable von außen bereits definiert ist, sollte diese Priorität haben.

Weniger wertet wie CSS aus.

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

In Sass/SCSS müssen Sie also zwei Dinge tun, um den Wert einer Root-Variablen zu überschreiben:

1. Sie müssen alle Ihre Variablendeklarationen mit !default
2. Sie müssen Ihre globalen Variablen vor diesen Standarddeklarationen einfügen.

Wie in:

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

In Less ist die Thematisierung viel einfacher. Sie müssen (normalerweise) nichts an Ihrer Bibliothek ändern, Sie müssen nur Ihre Überschreibungen nachstellen. Sie müssen nur eine Sache tun.

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

Daher brauchen Sie !default nicht, da Less immer Ihren endgültigen Wert akzeptiert.

Stellen Sie sich die Less-Evaluierung wie die CSS-Kaskade vor. Es funktioniert einfach. Die Schlusserklärung gewinnt.