I have created a React Component library for the first time that uses Rollup & sass and each component has its own style defined in the library. I want to consume the library in a project and overrides some of the styles set in the library. I have tried inject which requires me to use !important for every css overriding which I am not really fond of as the styles in the library takes precedence. Is there a way to configure it to make the styles to be at a level which can be overridden by project scss files easily?
Current setup:
styles()
// postcss() the same issue also happens for this plugin
Example of overriding css:
// In library
.button {
background-color: white;
border-radius: 2em;
}
// In project
.button {
background-color: black; // I want this to be precedence instead of the one above (white)
}
Related
I'm migrating a Stylus library to SCSS since Angular 12 has deprecated Stylus and I'm in that impacted 0.3%. I've run into something we were doing that I'm not sure how to convert to SCSS—maybe it's impossible.
Let me lay this out simply: I work on several projects that all use loads of the same styles, so we put those styles together into one style sheet in its own NPM package. We can then just grab #import '#company/design/styles'; and suddenly we've got all of our regular styles and variables and mixins available in the project, or we can import #import '#company/package/styles/common'; for just the variables and mixins.
The thing is, our projects might need to configure the library before we import it. Suppose the library contains this bit:
// #company/package/styles/_forms.scss
input:invalid {
background: url('/assets/input-error.svg') no-repeat center right;
}
Not every project will have /assets/input-error.svg at that exact location. Maybe one of my projects has to use /subfolder/static/input-error.svg.
I could include this then overwrite input:invalid { background-image: url(...) } to supply it with the correct location, but there may be many references to this particular file and many other assets on top of that to correct. So we instead, in our Stylus library, we introduced an $asset-input-error variable that points to /assets/input-error.svg by default and did something like this:
// #company/package/styles/_forms.scss
input:invalid {
background: url($asset-input-error) no-repeat center right;
}
// the local project
$asset-input-error: '/subfolder/static/input-error.svg';
#import '#company/package/styles';
The above is heavily simplified and isn't actually legitimate SCSS, but I hope it conveys what we're trying to do: we want to set up what are effectively environment variables in our SCSS, include the common style sheet, and have it use those variables.
The thing is, I'm not sure what the legitimate or idiomatic approach is to do this in SCSS. Unlike Stylus, which has a global scope for its variables, SCSS would have me #use '../config'; and reference config.$asset-input-error, and from outside the library there's no way I see to change the configuration to point that asset to a different location. I'm sure SCSS has a way for me to do this, but I'm not sure what it is. Do I convert the entire library into a giant mixin to which I pass optional configuration? Do I do something with global variables? Something else?
How can I provide variables to my SCSS style sheet to configure it as part of including it in a project?
Ultimately the end goal here is just to be able to say to the library things like: “the assets to reference are here” (very important) or “the error color is this in this particuilar project” (less important).
Using #import
You can use global variables declared before the #import as you stated.
SCSS Documentation for this method
#company/package/styles/_forms.scss
$asset-input-error: '/subfolder/static/input-error.svg' !default;
input:invalid {
background: url($asset-input-error) no-repeat center right;
}
#company/package/styles/styles.scss
#import 'forms';
local.scss
$asset-input-error: '/different/path/input-error.svg';
#import '#company/package/styles';
CodeSandbox Demo
Using #use [...] with
You can also hop aboard the #use train if you prefer to future-proof your library.
SCSS Documentation for this method
SCSS Documentation for using mixins
SCSS Documentation for configuring forwards
#company/package/styles/_forms.scss
$asset-input-error: '/subfolder/static/input-error.svg' !default;
input:invalid {
background: url($asset-input-error) no-repeat center right;
}
#company/package/styles/styles.scss
#forward 'forms';
local.scss
#use 'styles' with (
$asset-input-error: '/different/path/input-error.svg'
);
Sadly CodeSandbox and StackBlitz don't support dart-sass, so I don't have a live demo for this but I tested it on the latest version of sass from npm.
In Sass, I could find I can use '#extend' with '#mixin'.
But from the code, I got curious what's the advantage of using extend.
If we know which 'classes' exactly what do we have to use, we can just use two classes, not extend and make another class.
In my opinion, if we just use two classes, not making multiple extends, code would be shorter and we can save memory. What can I think of the advantage is it's just more easy to see on 'CSS output', but usually people just check SCSS file, not CSS code output.
Isn't it just better to use two separate classes instead of using multiple extends? What is the main advantage of using '#mixin'?
It helps you write DRY code quickly. #extend can be very useful when used properly.
It allows a selector to extend the styles of another selector, essentially providing a form of sub-classing. #extend works by combining selectors into a single comma-separated selector.
I.e. -
.A {
font-size: 1rem;
color:red;
}
.a{
#extend .A;
line-height: normal;
}
Which outputs:
.A,.a {
font-size: 1rem;
color:red;
}
.a{
line-height: normal;
}
There are a couple of important issues with extends to keep in mind:
they change the order of your CSS rules and re-group them often awkwardly which can have unintentional issues down the road
they are less performant than Mixins when your Sass is minified and gzipped.
Great article detailing these issues by Harry Roberts: "Mixins for Better Performance"
I'm just getting into both Laravel and SASS and I took the opportunity to rewrite my old html template into something re-usable and SASS the CSS rules.
In my HTML template, I had the borders such as follows:
input[type="text"]{
border-style:solid;
border-color:red;
border-width:1px 1px 4px 1px;
}
<input type="text" />
So I would have a border-bottom of 4px and rest would be 1px, in the same style and same color. I wanted to override Bootstrap 4's $border-width property so I went ahead and changed it to 1px 1px 4px 1px, and boom. It didn't work.
After inspecting the SASS files, I've noticed that they're not used the way I thought they'd be, but instead they look something like:
border: $border-width solid $border-color
So that got me thinking, there are probably several ways to resolve this, one way I went ahead and done so far is:
$border-widths:1px 1px 4px 1px;
input[type="text"].form-control{
border-width:$border-widths!important;
}
So I'm leaving the default $border-width variable as is, and instead creating my own variable and then selecting the input and overriding the border-width property only. Which looks, not right because:
This is my _variables.scss override file and I kind of want it to stay that way.
I could do this with just CSS override the same way, but then it'd defeat the whole purpose.
I have to explicitly use !important otherwise I can't override Bootstrap 4's rules.
So, there must be another way, I guess. But what exactly?
I ended up simply keeping the !important for overriding and just made myself another scss file, and written the rules there:
_variables.scss
$border-widths: 1px 1px 4px 1px;
_custom.scss
.border-thick-bottom{ border-width:$border-widths!important; border-style:solid; }
I'm using css modules. Each css module is a scss file and looks something like the following:
.componentWrapper {
border: solid cadetblue;
border-radius: 40px;
padding: 10px;
width: 95%;
&.componentTitle {
font-size: 18px;
width: 15%;
background-color: white;
margin-top: -25px;
}
}
Is it considered an anti-pattern to use & inside css modules?
Well no. Just keep in mind that this forces you to have the html in an appropriate structure to make that work. So in case the styles are only used in this module and not needed anywhere else, that is absolutely fine. But if you need those Styles somewhere else, in another context which does not have the appropriate html structure, another approach, f.i. by using classes, would be better. Then the #extend directive can come in handy.
No, sass-loader will run first and spit out plain CSS
CSS modules takes the CSS and scopes it.
Using SASS/SUSY,
I am trying to create RTL rules that only apply when [dir="rtl"] is set (dynamically) but my layout is taking on the RTL flow rules by default. How do I do this with SUSY?
I have a Demo here
$default-dir: (
math: fluid,
columns: 12,
gutter-position: split,
gutters: 0,
flow: ltr
);
.boxes{
width: 100%;
display: block;
margin: 0 auto;
max-width: 1280px;
#include clearfix;
#include layout($default-dir);
[dir="rtl"] &{
#include layout(rtl);//I EXPECT THIS LINE TO ONLY APPLY TO RTL [dir="rtl]
background-color: orange;
}
...
}
This is a common confusion between how CSS works, and how Sass works. CSS is DOM-aware, because it is compiled by browsers along with HTML. Sass is working at a different layer, unaware of the DOM structures implied by your CSS.
The layout mixin is a Sass abstraction, changing a few global Sass variables that Susy can refer back to — it has no actual CSS output of its own. The layout mixin changes the output of other functions and mixins that come after it in the Sass. You can also use with-layout() { <content> } to wrap entire blocks of mixins and functions — but in both cases, the variables only exist in Sass.
In order to change the layout based on a selector, you have to provide both layouts in full — not just one layout, and a scoped variable change. That means something more like this:
.box-item {
#include span(1 of 2);
[dir='rtl'] & {
#include span(1 of 2 rtl)
}
}
There are some workarounds to make that less repetitive, but none are as simple and clean as what you hoped for. They basically involve finding ways to compile the same code block twice, with different variables and an extra selector.