Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing ruleset with variables to mixin #2004

Closed
kolya-ay opened this issue May 13, 2014 · 6 comments
Closed

Passing ruleset with variables to mixin #2004

kolya-ay opened this issue May 13, 2014 · 6 comments

Comments

@kolya-ay
Copy link

Is there a way to pass named set of variables to mixin? Like so:

@small: {
        @width: 10px;
        @height: 10px;
};

.button(@dim) {
        @dim();
        width: @width;
};

@media (max-width: 700px) {
        button {
                .button(@small);
        };
}

Generally speaking, I need some way of parametric composition, the way to pass one mixin into another by name. I think this is quite useful in many cases. There is may be an approach to simulate this behavior?

@seven-phases-max
Copy link
Member

So is it "pass named set of variables to mixin" or "pass one mixin into another by name"? Those are quite different things actually.

OK, never mind, I guess I can guess what you need. Well, you can use old good "tagged mixins" for this:

.dim(small) {
    @width:  10px;
    @height: 10px;
};

.button(@dim) {
    .dim(@dim);
    width: @width;
}

@media (max-width: 700px) {
    button {
        .button(small);
    }
}

Although, technically I also would expect your initial snippet to work as it is too (i.e. @width to be visible after @small() call) but the "detached rulesets" feature is not fully stabilized yet and not everything there works like it would with regular mixins (e.g. #1859 (comment)).

Alternatively another working solution is:

@small: {
    @width:  10px;
    @height: 10px;
    .style();
};

.button(@dim) {
    @dim();
    .style() {
        width: @width;
    }
}

@media (max-width: 700px) {
    button {
        .button(@small);
    }
}

Though I don't think it has any advantages over the first one.

@kolya-ay
Copy link
Author

For my usecase it doesn't matter what will I pass to the underlying (.button) mixin, ether "ruleset with variables" (which seems not affect to context) or "mixin by name" (something like function-apply which is not possible as far I understad). While the things may be very different internally (mixin names and variable names seems to lie in different namespaces) from user point of view it's matter of syntax (like passing a struct or passing a function that returns that struct). Please correct me if I'm wrong.

Slightly different example with expected output:

@small: {    // or .small {...}
   @width: 10px;
};
@big: {
   @width: 20px;
};
.size(@settings) {        
   @settings();
   button {
     width: @width * 2;
   }
};

.size(@big); // or .size(.big)
@media (max-width: 700px) {
   .size(@small);
}

The output:

button {
  width: 40px;
}
@media (max-width: 700px) {
  button {
    width: 20px;
  }
}

@seven-phases-max
Copy link
Member

Yes, I get it. Hence my first example. The only difference is that instead of .small or @small: you define the mixin as .dim(small) (with whatever suitable name instead of dim) and the usage is as simple as it can be.

@kolya-ay
Copy link
Author

Thank you! I just found your SO ansfer about such and other workarounds. However is there a plan/roadmap to add generic mixin-as-parameter feature? I can easily imagine the cases where it would be very userfull though..

@seven-phases-max
Copy link
Member

is there a plan/roadmap to add generic mixin-as-parameter feature?

There was a discussion of it at least (so maybe, eventually).

@seven-phases-max
Copy link
Member

If you don't mind I'll close this as not an issue or bug report (there's discussable variable visibility behaviour in the initial example but it's probably better to be reported separately in more formal way).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants