-
-
Notifications
You must be signed in to change notification settings - Fork 835
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
feat: add Less custom function extender, is-extension-enabled
function
#3190
Conversation
[ci skip] [skip ci]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would a simpler syntax be better, such as:
I think so. What's the benefit of doing it the other way?
There's no inherent benefit of either way, I don't believe. Just syntactically different. |
dd11c51
to
842efd1
Compare
So I've pushed an alternate syntax which I think may be better. The original syntax required that the mixin be declared in the root scope, meaning that // This would work
.if-extension-enabled(@ext) when (@ext = flarum-tags) {
body { background: black; }
}
// ...but this would NOT
body {
.if-extension-enabled(@ext) when (@ext = flarum-tags) {
background: black;
}
} The new syntax, however, does support this: // This would work
.when-extension-enabled(flarum-tags, {
body { background: black; }
});
// ...and so does this
body {
.when-extension-enabled(flarum-tags, {
background: black;
});
} However, the newer method will be significantly less performant, since it performs a loop over all enabled extensions each time it is called, rather than only doing it once. We could reduce that by setting a less variable per enabled extension (e.g. |
What worries me about this is that, even without this, the Less compiler breaks the forum sometimes by running out of memory, it has been reported multiple times before, I've even experienced it locally, so I'm personally very reluctant to introducing anything that could reduce its performance even less. How about registering a custom function instead ? I haven't actually tested the difference (yet) but I'm assuming it would be a more efficient solution. (tested locally and it works). .App {
& when(is-extension-enabled('flarum-tags') = true) {
opacity: 0.3;
}
} $parser->registerFunction('is-extension-enabled', function (Less_Tree_Quoted $extensionId) {
return new Less_Tree_Quoted('', in_array($extensionId->value, ['flarum-tags', 'flarum-blog']) ? 'true' : 'false');
}); |
That does seem like a much better idea. When I saw the documentation of less-php state that custom functions weren't supported, I assumed it meant completely, but if we can define them in PHP, that's perfect! |
[ci skip] [skip ci]
[ci skip] [skip ci]
is-extension-enabled
function
@SychO9 Should be done now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall makes sense, but is the = true
/ = false
really necessary? Is there no "not" symbol
[ci skip] [skip ci]
[ci skip] [skip ci]
[ci skip] [skip ci]
[ci skip] [skip ci]
…o dw/less-extension-styles
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
just nitpicks, because they're fun :p
Co-authored-by: Sami Mazouz <sychocouldy@gmail.com>
Co-authored-by: Sami Mazouz <sychocouldy@gmail.com>
Changes proposed in this pull request:
This prevents stylesheet bloats from extensions which extend multiple extensions, by only adding styles which are needed.
Extender usage:
Is ext enabled func usage:
Reviewers should focus on:
(no longer applicable)
Would a simpler syntax be better, such as:
Necessity
Confirmed
composer test
).Required changes: