0

I have a mixin in Less to set the text-transform-property:

.text-transform(@type: none) {
    & when (upper = @type) {
        @type: uppercase;
        color: red;
    }

    text-transform: @type;
}

Which works fine for calls like:

.text-transform(none);
.text-transform(uppercase);

Now I want to shorten the syntax and allow:

.text-transform(upper);
.text-transform(lower);

I tried to update the variable inside the mixin, like:

@type: uppercase;
@type: "uppercase";

But it won't change and the resulting rule is:

text-transform: uppper;

I also tried @type: "@{type}case";, which resulted in an endless recursion.

The branch is executed, however. The test to change the color to red passed successfully.

How ca I update the variable?

lampshade
  • 2,470
  • 3
  • 36
  • 74
  • See https://stackoverflow.com/questions/25287904. – seven-phases-max Jan 18 '18 at 16:20
  • @seven-phases-max Thanks. That means, what I want to do is not possible this easily, right? I can however solve it with another condition (my current solution): `& when (upper = @type) { text-transform(uppercase); }`. Is there any benefit of one way over the other? – lampshade Jan 18 '18 at 16:34
  • If you're writing a more complex conditionals (including switch/case-like things) - see https://stackoverflow.com/questions/23738798, https://stackoverflow.com/questions/23030184 etc.. I.e. use mixins and argument pattern matching instead of `& when` (which is just a limited syntactic sugar goody for very specific cases and no way a blind `if` replacement). – seven-phases-max Jan 18 '18 at 16:38
  • In a strict sense, yes, what you want is simply impossible just because variables in Less are not the same thing as variables in imperative languages (for instance `@variable: value` statement does not assign a new value to a (existing or not) variable but creates a new var instead)). There's actually a [dedicated thread](https://github.com/less/less.js/issues/2072) at the issue-tracker with some [comments](https://github.com/less/less.js/issues/2072#issuecomment-90918318) illustrating why exactly such `& when`s simply can't work in Less by definition (per language design). – seven-phases-max Jan 18 '18 at 17:18
  • For your use-case I guess the Less-way implementation could look [like this](https://gist.github.com/seven-phases-max/2b8e85bc5183cb0cf68821e8c6780bd5) (all three versions doing the same via different technics to choose depending on your actual needs/prefs). – seven-phases-max Jan 18 '18 at 17:45
  • @seven-phases-max Thank you very much for your help. I took a deeper look at [Pattern Matching](http://lesscss.org/features/#mixins-parametric-feature-pattern-matching) and understand your techniques. From your example I find the first and secod approach the best - especially regarding readability. If you want you to, please add these examples with your good explanation as an answer. Otherwise if you don't want to, I'll close it as a duplicate, as you suggested. Thank you. – lampshade Jan 18 '18 at 18:13
  • @seven-phases-max One last question - thank you very much for your time. You say "*`& when` (which is just a limited syntactic sugar goody for very specific cases and no way a blind if replacement*". Does this mean, that [this way](https://jsfiddle.net/b5jcbz1t/) of writing is a bad practice? Can you say way, and whether there's a benefit of Pattern Matching over this? Because it looks very clear, easy to read and it works quite good. – lampshade Jan 18 '18 at 18:17
  • For your `& when` example, it's not that it's bad practice - it's just quickly becomes too verbose and hard to read when it comes to `(if) else`/`switch-case` cases (e.g. in your example the `default` branch have to repeat all previous conditions, now imagine you'll have more then two or three). Thus it's absolutely fine to use `& when` if you find it more easy, it's just becomes not very convenient and error prone when it comes to something more complex than "set property(s) on a single condition". – seven-phases-max Jan 18 '18 at 18:52
  • @seven-phases-max Thank you very much for your response. All good points in favor of your examples. I'm going to refactor these parts. – lampshade Jan 18 '18 at 19:32

0 Answers0