Less.js: Izinkan penjaga bekerja dengan variabel yang tidak ditentukan

Dibuat pada 4 Jul 2013  ·  46Komentar  ·  Sumber: less/less.js

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

Variabel tidak didefinisikan, oleh karena itu tidak ada output.

<strong i="8">@variable</strong>: true;

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

Variabel didefinisikan, oleh karena itu output:

a {
  color: red;
}
feature request low priority support as plugin

Komentar yang paling membantu

Apakah ada pergerakan atas permintaan ini? Saya sudah cemas untuk pemeriksaan variabel yang tidak ditentukan untuk beberapa waktu sekarang. Saat ini, saya memiliki pekerjaan yang jauh dari ideal...

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

tetapi, agar ini berfungsi, variabel harus ada dan didefinisikan sebagai null secara default. Ini akan jauh lebih efektif/fleksibel jika saya bisa memeriksa apakah variabel itu ada di tempat pertama.

Semua 46 komentar

+1
Ini juga dapat digunakan untuk mengatur warna dasar pada perpustakaan.
Bayangkan kasus berikut:
Anda memiliki lebih sedikit file untuk aplikasi tertentu, misalnya menu utama situs web.
Anda mengimpor lebih sedikit file ini di file utama yang lebih sedikit, di mana warna dasar Anda didefinisikan sebagai variabel.
Sekarang jika Anda menggunakan warna dasar tersebut di file less menu utama, mereka bergantung pada file utama.
Jika Anda dapat memeriksa keberadaan variabel, Anda dapat kembali ke warna yang ditentukan modul.
Berikut adalah contoh bagaimana saya membayangkan menu less file:

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

+1, kita sudah memiliki istext , isnumber memiliki isdefined dan isundefined akan sangat membantu dalam tema dengan lebih sedikit.

Yaitu menggunakan value atau userValue jika isdefined

Saya sering mengalami masalah ini ketika mencoba mengatur konvensi tema untuk UI Semantik dengan KURANG.

+1 ini - akan sangat bagus.

+1 ini untuk saya juga

Bukan masalah besar untuk menambahkan fungsi is-defined (saya berharap itu muncul di salah satu plugin pertama segera setelah v2 dirilis). Meskipun jujur ​​hal yang menyedihkan adalah bahwa mereka yang menginginkan fitur ini sangat merindukan fakta bahwa kedua kasus penggunaan di atas dapat dipecahkan (dalam banyak kasus bahkan dengan kode yang lebih ringkas) tanpa fitur seperti itu.

Kasus penggunaan @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;

Kasus penggunaan @ 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...

Yaitu secara ringkas: alih-alih menguji apakah suatu variabel didefinisikan, berikan saja nilai default untuk variabel itu karena nilai variabel dapat ditimpa secara bebas.

Adakah yang bisa menjawab mengapa contoh max tidak bisa dilakukan untuk mereka? saya hanya dapat
anggap itu karena Anda tidak tahu apakah variabel didefinisikan di atas atau
di bawah impor? Atau itu sesuatu yang lain?
Kami tidak akan mempertimbangkan sesuatu yang tidak memiliki use-cases .
Kelemahan dari melakukan ini adalah orang yang salah mengetik variabel tidak akan melihat
kesalahan. Kami bisa mengatasi ini dengan peringatan tetapi kemudian jika Anda melakukannya pada
tujuan Anda tidak ingin peringatan .. itu satu-satunya masalah saya dengan ini
saran.

Ini berguna terutama ketika mendefinisikan tema untuk mengurangi ukuran CSS yang dihasilkan. Saat membuat tema secara umum, seseorang ingin mengaktifkan pengaturan banyak properti. Namun, pengguna mungkin ingin menyetel hanya beberapa dari mereka membiarkan properti lainnya tidak disetel. Tentu saja menyetelnya ke nilai default akan berfungsi secara umum, namun, ini membuat CSS akhir membengkak.

Pertimbangkan tema dasar (templat) berikut:

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

Pengguna tema mungkin ingin menyetel warna teks saja, membiarkan properti lainnya tidak disetel. Tentu saja dimungkinkan untuk menyetel nilai ke "awal", "transparan", "mewarisi", dll., namun, ini meningkatkan ukuran CSS akhir. Tema cenderung memiliki ratusan properti seperti itu sehingga ukurannya dapat meningkat secara signifikan.

@JechoJekov

Saya pikir Anda kehilangan poin dari permintaan fitur ini, perhatikan bahwa untuk kasus penggunaan Anda, Anda masih perlu menjaga setiap properti ini (karenanya alasan yang saya sarankan dua posting di atas masih berlaku). Jadi saya tidak berpikir kasus penggunaan Anda menambahkan sesuatu yang baru ke #1400 (pada dasarnya sepertinya Anda menyarankan fitur yang berbeda seperti "lewati properti jika semua nilainya disetel dengan variabel yang tidak ditentukan" atau sesuatu seperti itu tetapi itu adalah yang lain cerita besar).

@seven-fase-max

Mungkin akan lebih baik jika dimungkinkan untuk mengatur variabel ke nilai "tidak terdefinisi" atau "tidak disetel". Menyetel properti ke nilai seperti itu berarti properti tersebut tidak dirender dalam CSS final. Ini menyederhanakan sintaks dan memungkinkan untuk memvalidasi bahwa variabel dideklarasikan.

@JechoJekov

Mungkin akan lebih baik jika dimungkinkan untuk mengatur variabel ke nilai "tidak terdefinisi" atau "tidak disetel".

Seperti yang saya sebutkan ini adalah fitur lain yang membutuhkan tiketnya sendiri (dengan diskusinya sendiri).

Hanya beberapa klarifikasi untuk peta jalan: Ini ditandai "ReadyForImplementation", tetapi sepertinya tidak ada konsensus di utas ini, dan sepertinya @seven-phases-max menyarankan alternatif yang layak. @lukeapage @seven-phases-max, haruskah implementasi siap dihapus?

@matthew-dean Tidak tahu. Saya kira di sini "ReadyForImplementation" masih valid, artinya sesuatu seperti "fitur ini tampaknya tidak terlalu diperlukan tetapi jika seseorang datang dengan PR yang mengimplementasikan hal seperti itu tidak akan ada penolakan" atau semacam :)

Bagaimana dengan itu? (Dalam pertimbangan)

Bagi saya, "Siap Untuk Implementasi" berarti ada konsensus umum (tetapi tidak harus bulat) bahwa itu _harus_ ditangani atau diimplementasikan. Saya pikir "Dalam Pertimbangan" memenuhi definisi Anda.

Masih mengalami masalah ini saat menggunakan pelingkupan

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

Akan menyukai kemampuan untuk menggunakan isDefined

Meskipun sesuatu seperti is-defined masuk akal (sebagai gula sintaksis), itu tidak benar-benar diperlukan. Cukup _always_ definisikan @foo (dengan nilai default apa pun yang Anda butuhkan), lagi pula jika Anda menggunakan variabel dalam gaya Anda - Anda _can_ memprediksi Anda perlu mendefinisikannya, misalnya:

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

Meskipun saya kira saya sudah menulis ini dalam contoh di atas (saya hanya mencoba untuk memastikan untuk menyuarakan fakta bahwa kurangnya fitur ini tidak dapat menjadi show-stopper untuk apa pun. Jika Anda tahu kasus penggunaan di mana itu satu, tolong bagikan).

Saya mencoba mengatur pratinjau tema di browser.

Ini berarti saya harus menggunakan less.js dan menimpa variabel default @theme dengan pengaturan run-time.

ala

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

Dalam KURANG saya, saya mengimpor file theme.less global yang menyertakan

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

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

Saya juga baru mencoba

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

Dalam kasus pertama, nilai yang dikeluarkan adalah undefined dalam kasus kedua selalu default terlepas dari apa yang diatur dalam modifyVars

Klik dropdown tema di sini untuk contoh.

Pekerjaan saat ini (yang ada di situs langsung) adalah secara manual mengambil jalur impor variabel, dan menguraikannya menggunakan regexp lalu mengimpor semua variabel tersebut dengan modifyVars , karena Anda dapat menebak ini cukup berantakan

@seven-phases-max Saya telah mempersempitnya menjadi kasus uji yang sangat spesifik dengan @import menyebabkan masalah.

Dalam kedua kasus, asumsikan:

Javascript

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

Dalam kasus pertama di theme.less, outer diatur dengan benar ke changedValue

komponen.less

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

tanpa tema

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

Dalam kasus gagal ini, di theme.less @theme disetel ke default dan bukan changedValue

komponen.less

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

tanpa tema

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

Dalam kasus "var in mixin", cuplikan berubah menjadi:

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

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

Meskipun untuk modifyVars itu harus selalu menghasilkan 'someOtherValue' untuk potongan yang Anda coba (karena modifyVars bekerja hanya dengan menambahkan baris <strong i="14">@theme</strong>: 'someOtherValue'; biasa tepat di akhir kompilasi Kode sumber). Jadi jika modifyVars tidak berfungsi, kemungkinan besar masalahnya ada di tempat lain.
Saya memang melihat kode halaman button tetapi terlalu rumit untuk dengan cepat mengatakan apa yang mungkin salah. Sekilas saya tidak dapat melihat (atau mungkin tidak mengerti) bagaimana kode Less dikompilasi ulang dan CSS yang dihasilkan diterapkan kembali setelah modifyVars (dalam cuplikan sederhana ini dilakukan melalui less.refreshStyles mengikuti modifyVars ).


Btw., untuk jaga-jaga, apakah Anda yakin tidak berencana menggunakan is-default sebagai sesuatu seperti:

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

? Jika demikian, masalahnya adalah kode tersebut akan secara langsung melanggar prinsip evaluasi malas ( is-defined harus mengembalikan false jika variabel tidak ditentukan, tetapi karena _akan_ didefinisikan dalam cakupan itu segera , is-defined juga memiliki untuk mengembalikan true -> rekursi yang tidak dapat dipecahkan. (Untuk detail lebih lanjut tentang mengapa redefinisi seperti imperatif bersyarat tidak dapat diizinkan dengan aman di Kurang lihat # 2072).
Yaitu itu benar-benar dapat berfungsi seperti yang diharapkan (kecuali is-defined dikodekan untuk secara eksplisit mendeteksi dan menyelamatkan dari rekursi tersebut) tetapi hanya sebagai jenis perilaku yang tidak ditentukan/tidak ditentukan, tanpa konsistensi dengan aturan visibilitas variabel normal sehingga menciptakan genap lebih banyak kekacauan.

@jlukic

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

Ya, ini adalah salah satu kecurigaan saya juga (Sayangnya saya tidak dapat menguji ini sekarang, saya juga tidak dapat menebak bagaimana ini bisa terjadi, tapi ya, itu mungkin karena penggunaan variabel dalam impor adalah ilmu hitam nyata. Saya akan membuat khusus mengeluarkan laporan jika ini masalahnya).

Aku cukup yakin itu ada hubungannya dengan sihir hitam yang luar biasa itu.

Saya telah bekerja dengan file yang sangat sederhana untuk di-debug, namun saya belum memiliki kesempatan untuk membuat repo kasus uji.

Dalam pengujian saya, kegagalannya khusus untuk menggunakan nilai {@variable} dalam impor, tetapi tidak dalam properti css.

Benar-benar menikmati tema dengan lebih sedikit, akan senang untuk mengatasi masalah ini. Berikut adalah contoh tema yang menyenangkan dengan KURANG yang baru saja saya pamerkan di Meteor DevShop minggu lalu (klik ikon paintbucket di kanan atas)

@jlukic saya mengujinya dan modifyVars berfungsi untuk vars dalam impor seperti yang diharapkan baik dengan lessc dan dengan less.js (lihat demo codepen , ini kode yang agak rumit karena harus impor dari url menakutkan Inti , tapi saya kira itu sama dengan apa yang seharusnya dilakukan halaman Anda ... Jadi sepertinya masalahnya ada di tempat lain).

Terima kasih telah meluangkan waktu untuk menghasilkan test case untuk saya. Ini dipotong cukup jelas. Saya tidak yakin apa yang terjadi pada saya .. Saya harus menyelidiki

Apakah ada pergerakan atas permintaan ini? Saya sudah cemas untuk pemeriksaan variabel yang tidak ditentukan untuk beberapa waktu sekarang. Saat ini, saya memiliki pekerjaan yang jauh dari ideal...

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

tetapi, agar ini berfungsi, variabel harus ada dan didefinisikan sebagai null secara default. Ini akan jauh lebih efektif/fleksibel jika saya bisa memeriksa apakah variabel itu ada di tempat pertama.

+1

Jadi secara ringkas: implementasi fungsi is-defined(name) (dan/atau get-value-of(var-name, fallback-value-if-not-defined) ) dalam sebuah plugin membutuhkan kurang dari 15 baris kode. Jadi lakukan saja jika Anda cukup berani.

+1 untuk ini. Apakah ada kemajuan dalam hal ini sebagai plugin? Maksud saya, @seven-phases-max Anda lebih tahu kodenya daripada kebanyakan kontributor, saya kira. Jika membutuhkan sekitar 15 baris kode, mengapa belum dilakukan?

Jika membutuhkan sekitar 15 baris kode, mengapa belum dilakukan?

Karena tidak ada yang benar- benar tertarik? Setiap fitur itu keren dan "sangat berguna" ketika orang lain melakukan ini untuk Anda... Tapi secara ajaib itu menjadi tidak begitu penting ketika itu tentang waktu Anda sendiri ;)

Anda lebih tahu kodenya daripada kebanyakan kontributor

Ini tidak berarti saya harus mengutamakan kepentingan saya sendiri setelah kepentingan orang lain, maaf (Terutama jika itu adalah sesuatu yang mendorong apa yang secara pribadi saya perlakukan sebagai penyalahgunaan/gaya kode-buruk).

Agar tidak terdengar kosong, untuk kasus penggunaan @ashenden : inilah cara yang tepat untuk membuat set aturan Anda dapat disesuaikan dengan "tidak diketahui" (jelas dengan asumsi kasus di mana penggantian CSS normal tidak berlaku untuk beberapa alasan) tanpa cacat ide "buta-pindah-setiap-CSS-nilai-ke-variabel-plus-gunakan-sesuatu-yang-Anda-tidak-gunakan" (Saya tidak akan menjelaskan secara rinci mengapa itu benar-benar rusak karena ini adalah cerita untuk posting blog yang panjang).

Ada konsep yang biasanya bernama "hooks", jadi berikut "festival can't make my mind up":

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

harus diganti dengan:

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

Hitung garisnya, hitung kemungkinannya, hitung batasannya.
Yaitu benar-benar, jika Anda tidak menggunakan beberapa properti CSS, biarkan saja bagi mereka yang akan .

Teman-teman, di sinilah saya mengalami ini, silakan lihat contoh ini dan beri tahu saya apakah ini kasus yang valid dan tidak dapat diperbaiki tanpa is-undefined.

Saya ingin memuat tema di perpustakaan seperti modul seperti itu:

Di aplikasi inti saya, saya mendefinisikan variabel @theme : 'kuning' dan kemudian mengimpor perpustakaan lebih sedikit.

Dan inilah tampilan library less dalam kasus ini:

@import 'tema/@{tema}';

tubuh {
latar belakang: @primaryColor;
}

Dengan cara ini saya dapat memiliki yellow.less dan default.less dengan @primaryColor : yellow dan @primaryColor : red.

Pada akhirnya, saya dapat menulis perpustakaan saya menggunakan nama variabel semantik seperti primaryColor dan menyediakan satu set tema dengan variabel-variabel yang ditentukan. Dan pengguna perpustakaan hanya akan menentukan nama tema di aplikasinya dan mengimpor gaya perpustakaan.

Oke, tidak apa-apa, sepertinya saya mengerti, saya hanya perlu mengimpor mixin seperti ini:

<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 Anda dapat menyederhanakan kode Anda menjadi:

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

juga perhatikan kutipan berlebihan yang dihapus.

Meskipun sejujurnya saya tidak dapat melihat bagaimana <strong i="13">@theme</strong>: yellow; (+ semua kode mixin) lebih baik daripada hanya baris <strong i="15">@import</strong> "themes/yellow"; eksplisit. Yaitu pertama-tama apakah Anda menyadari mengesampingkan ? Yaitu Anda tidak perlu menyembunyikan default <strong i="18">@import</strong> "themes/default"; , jika pengguna perpustakaan Anda perlu menerapkan barang yellow - dia hanya mengimpor tema kuning Anda ( di mana saja setelah file perpustakaan utama Anda, dan sekali lagi itu adalah sama satu baris) dan voila - perpustakaan Anda menggunakan nilai variabel yang ditentukan dalam file kuning.

Saya berakhir dengan impor opsional file yang menimpa tema atau beralih ke tema yang telah ditetapkan. Dalam proyek yang menggunakan perpustakaan, kami kemudian mengonfigurasi webpack untuk menggunakan alias ke file itu sebagai modul simpul jika proyek membutuhkan tema yang berbeda. Apa yang saya tulis sebelumnya atau apa yang Anda tulis tidak akan berfungsi dalam kasus kami karena kami sedang membangun kit UI untuk Angular dan ini sangat modular. Kita dapat mengimpor hanya satu tombol atau pilih kontrol dan itu harus menyadari tema yang kita gunakan dengan semua enkapsulasi gayanya. Solusinya mudah diatur, jadi saya senang dengan itu.

apa yang Anda tulis tidak akan berfungsi dalam kasus kami karena kami sedang membangun kit UI untuk Angular dan ini sangat modular.

Saya telah melihat waktu yang tak terbatas ini sebelumnya - ini adalah salah satu masalah Kurang (salah) pemahaman yang paling menyedihkan - orang hanya melewatkan prinsip dasar evaluasi Kurang malas dan, alih-alih menggunakan Less overriding alami, buat perpustakaan dengan injeksi file yang berat- pola kustomisasi berbasis yang terinspirasi oleh kebiasaan dari bahasa dengan semantik variabel yang berlawanan secara langsung (seperti PHP, Sass, dll.). Itu pasti sesuatu yang lebih dari sekadar pria yang terus menerus berteriak, "Teman-teman, kamu salah!"

Saya ingin melakukannya dengan benar, saya tidak mengklaim bahwa saya mengerti segalanya :) Ingin menjelaskan saran Anda tentang contoh saya? Inilah yang kami dapatkan:

Berikut adalah contoh struktural minimum:

Perpustakaan:

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

Proyek 1 (harus menggunakan tema default):

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

Proyek 2 (harus menggunakan tema sekunder):

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

Pustaka kami ditambahkan sebagai modul simpul dan di dalam proyek kami hanya mengimpor komponen tombol dari pustaka. Karena ini adalah modul Angular untuk tombol itu dengan file yang lebih sedikit, itu dikompilasi secara terpisah dari sisa Proyek 1 atau Proyek 2.

Saya telah memikirkan hal ini untuk sementara waktu dan saya tidak dapat menemukan cara untuk mengatur lebih sedikit file untuk memungkinkan Proyek 1 atau Proyek 2 untuk mengatur file tema apa yang akan digunakan saat mengkompilasi kedua komponen dan kode Proyek sendiri. Saya tidak melihat cara untuk mengganti gaya untuk komponen tombol dari dalam kode Proyek.

Jadi sebagai gantinya, pada dasarnya, inilah cara saya menulis import.less:
<strong i="58">@import</strong> 'theme-default';
<strong i="61">@import</strong> 'mixins';
<strong i="64">@import</strong> (optional) '~custom-theme';

Dan di dalam Proyek, jika saya ingin mengganti variabel tema untuk kode Proyek dan komponen perpustakaan, saya alias file ini sebagai modul menggunakan webpack. File ini dapat memiliki penggantian eksplisit katakanlah @primary atau hanya beralih ke tema sekunder:
<strong i="69">@import</strong> '~myLibrary/styles/theme-secondary';

Jadi saya tahu tentang mengganti, masalahnya adalah — pengguna perpustakaan tidak memiliki cara untuk masuk di antara "di mana saja setelah file perpustakaan utama Anda" dan kode komponen perpustakaan. Saya mengerti bahwa apa yang Anda katakan akan berfungsi untuk kerangka kerja tanpa enkapsulasi gaya, tetapi untuk Angular itu tidak akan berfungsi atau saya salah memahami sesuatu dalam solusi Anda.

Saya melihat. Kemudian kita sebenarnya berbicara tentang hal yang sama (hanya dengan kata-kata yang berbeda). Segera setelah buttonComponent (atau komponen lainnya) dikompilasi secara terpisah, "master kustomisasi proyek" tetap menjadi file import.less dan Anda melakukan persis seperti yang saya sarankan. (sementara Project 1 dan Project 2 berubah menjadi hanya komponen "lainnya" (atau "all-in-one"?) dengan level yang sama dengan buttonComponent dan bukan cukup "proyek").

Yaitu dengan cara ini saya akan mengatakan Anda "melakukannya dengan benar" sesuai selera saya.

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.

@basi Ping.

Secara teknis plugin yang mengimplementasikan fitur ini tersedia sejak 2015 . Tapi secara pribadi saya tidak pernah mengujinya jadi tolong jangan salahkan saya jika ada yang tidak beres (ini hanya untuk diketahui).

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.

Jadi... Saya menelusuri kembali utas ini dan saya tidak dapat benar-benar menentukan apakah ini sebagian besar kasus kesalahpahaman orang. Lingkup lebih sedikit atau tidak.

Saya tidak benar-benar melihat kebutuhan untuk memeriksa apakah vars didefinisikan. Vars harus ditentukan jika akan dikonsumsi.

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

@library-color: red;

.box {
  color: @library-color;
}

Saya tidak mengerti perlunya menetapkan properti secara kondisional berdasarkan nilai _changing_. Jika properti diatur ke variabel, cukup ubah nilai variabel.

Yaitu, jika library.less memiliki ini:

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

Yang perlu dilakukan seseorang untuk mengatur outputnya:

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

Ini akan menghasilkan:

.box {
  color: red;
}

Apakah OP dan orang lain di utas itu memahami perilaku itu?

Saya pikir kasus penggunaan "apakah var ada" adalah cara yang bagus untuk melakukan flag. Artinya, saya tidak berpikir ada "kepalsuan" yang secara konseptual lurus ke depan. Atau lebih tepatnya, itu tidak biasa bahwa true adalah satu-satunya nilai "benar". Dengan kata lain, saya pikir ini masalah pendidikan, bukan masalah perilaku.

Saya pikir kita harus mempertimbangkan untuk menutup masalah ini, karena ini biasanya diperbaiki dengan satu baris yang menyatakan nilai variabel default. Meskipun dengan Less v3.5 bergerak menuju kesepakatan yang lebih permisif, mungkin variabel di dalam penjaga dievaluasi lebih permisif?

Suara saya tidak, meskipun. @the-variable: false; tampaknya semua OP perlu menambahkan.


Kepada siapa pun yang memiliki pertanyaan tentang bagaimana memecahkan masalah tertentu yang mereka rasa terkait dengan ini, jangan ragu untuk memposting di less gitter dan @ me.

Oke penutup, terima kasih @calvinjuarez.

Apa yang juga terjadi sejak ini dibuka adalah fungsi if() . Jadi Anda bisa melakukan color: if((@variable), green, red);

@matthew-dean Terima kasih banyak telah menulis dengan tip ini. Saya melihat penambahan if() dalam catatan rilis 3.0, tetapi tidak membuat koneksi ke masalah ini, yang saya punya kasus unik untuk (tetapi bukan waktu untuk membuat versi yang dikurangi). Sekali lagi, sangat dihargai. Bagus, tim KURANG.

@kbav Tidak masalah! Tip lain di atas tip itu: ketika if() pertama kali diperkenalkan, itu memerlukan parens di sekitar kondisi karena pada dasarnya "menyematkan" a when guard (seperti pada, bagian setelah when di when (@variable) ). Namun, itu telah diperbaiki pada Less 3.6, jadi contoh di atas dapat Anda tulis tanpa tanda kurung (jika dikompilasi dengan versi terbaru):

color: if(<strong i="10">@variable</strong>, green, red);
Apakah halaman ini membantu?
0 / 5 - 0 peringkat