Skip to content

Default mixin arguments aren't recognized by selector guards #1613

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

Closed
radium-v opened this issue Oct 24, 2013 · 4 comments
Closed

Default mixin arguments aren't recognized by selector guards #1613

radium-v opened this issue Oct 24, 2013 · 4 comments
Labels

Comments

@radium-v
Copy link
Contributor

Howdy,

I'm trying to use a guarded selector inside a mixin with default vars, like so:

.a(@v: 0) {
    & when (@v >= 0) {
        prop: @v;
    }
}

.b {
    .a;
}

Changing .b will allow it to pass though:

.b {
    @v: 0;
    a;
}

Also, changing the mixin works:

.a(@v: 0) {
    .c(@v) when (@v >= 0) {
        prop: @v;
    }
    .c(@v);
}

.b {
    .a;
}

My expectation would be that example 1 would output the prop for .b by default, since the mixin sets its local var @v: 0, but it throws an undefined error.

There's not much documentation around the new features in v1.5.0, so I might be doing it wrong, but it feels like a bug. Thoughts?

@radium-v
Copy link
Contributor Author

One extra note: the variable is indeed visible within the mixin's scope:

.a(@v: 0) {
    & {
        prop: @arguments;
    }
}

.b {
    .a;
}

Will output:

.b {
    .prop: 0;
}

@lukeapage
Copy link
Member

It works the same way two mixins would work.. the first call unlocks the
2nd. Then it is only called once in its final scope. I agree its not very
obvious though and we may need to look at the scoping rules to improve this
new feature.

@lukeapage
Copy link
Member

re-reading I think we should fix sorry.

@lukeapage
Copy link
Member

Sorry should have fixed this ages ago

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

No branches or pull requests

2 participants