CODEWITHSUNDEEP
csssass
ritchie
ritchie

Reputation: 455

How do I wrap a file in a mixin to @use in a scss file?

Not sure what the best way to import is but '@import' is deprecated and @use should be used instead. I have a grid file that I want to include in style.scss .

_grid.scss

.main-content {
    display:grid;
    /* Set up grid stuff */
}
header{
grid-area: header;
}

I need to import into here. style.scss

body{
/* More code here */
}

The final complied code should look like this:

.main-content {
    display:grid;
    /* Set up grid stuff */
}
header{
grid-area: header;
}
body{
/* More code here */
}

I know this is wrong, but this is what I have tried:

@use 'grid' as *;
$main-content

What about using a mixin?

_grid.scss

@mixin grid {
/* Wrap all the code here from _grid.scss */

    .main-content {
        display:grid;
        /* Set up grid stuff */
    }
    header{
       grid-area: header;
    }

}

style.css

@use 'grid' as *;
@include $grid

body{
}

Upvotes: 1

Views: 1093

Answers (2)

ritchie
ritchie

Reputation: 455

I ended up just using @import , I seriously doubt they would remove it in the next 3 years and break everyone's code everywhere

Upvotes: 0

Brebber
Brebber

Reputation: 3054

@use is really tricky at the moment ... a real big impact to the language.

(A) First of all you should check if you indeed use the most actual SASS version: DART SASS. HEAD UP: MOST actual compilers even in good maintained frameworks DO NOT YET!!! Here are information about how to find/install compiler with most actual version:

(B) @use changes the structure how to write SASS code substantial.

What NOT works with @use is to import code right in the middle of the code like you can do with @import. So, if you need to do so you are right with your last code example using a mixin including code to the body tag. But you need to move the mixin to the body tag where you want to include the code:

//### > SASS _grid.scss

@mixin grid {
    .main-content {
        display:grid;
        /* Set up grid stuff */
    }
    header{
        grid-area: header;
    }   
}


//### > SASS main.scss

@use 'grid' as *;

body {
    @include grid;
}


//### --> compiles to CSS

body .main-content {
  display: grid;
  /* Set up grid stuff */
}
body header {
  grid-area: header;
}

But honestly there are very few scenarios when you need to nest your grid css into the body tag!

If you divide your SASS into partial files and do the output in a main file which only wraps all code together you are able to do use @use very similar to the common use of @import. Example:

//### > SASS PARTIAL _typography.scss

/* TYPOGRAPHY */ 
html {
    font-family: sans-serif;
}
h1 {
    font-size: 24px;
}

//### > SASS PARTIAL _structure.scss

/* STRUCTURE */
header{
    padding: 10px 20px;
    background: darkgray;
}   
main {
    padding: 20px 20px;
    background: white;
}
footer {
    padding: 20px 20px 80px 20px;
    background: black;
}

//### > SASS PARTIAL _grid.scss

/* GRID HELPER CLASSES */ 

.grid-col_4 {
    display: grid;
    grid-template-columns: 25% 25% 25% 25%;
}

//### > SASS MAIN main.scss

// WRAP PARTIALS TOGETHER
// only '@use' files, no css code here
@use 'typography' as *;
@use 'structure' as *; 
@use 'grid' as *;

//### --> compiles to CSS

/* TYPOGRAPHY */
html {
  font-family: sans-serif;
}

h1 {
  font-size: 24px;
}

/* STRUCTURE */
header {
  padding: 10px 20px;
  background: darkgray;
}

main {
  padding: 20px 20px;
  background: white;
}

footer {
  padding: 20px 20px 80px 20px;
  background: black;
}

/* GRID HELPER CLASSES */
.grid-col_4 {
  display: grid;
  grid-template-columns: 25% 25% 25% 25%;
}

HEAD UP:

Even that seems very similar to the use of @import there is a VERY BIG DIFFERENCE to @import.

If you use variables/mixins/functions you are not able to @import them to the main.scss as before first and they are ready to use by the next included files! With @use now YOU HAVE TO @use the files separatly in every partial file where you need the variables/mixins/function.

If you like you may have an additional look about how that works:
https://stackoverflow.com/a/66300336/9268485

But note: what sounds easy indeed is more complicated in practical use ... even when the projects and modules are bigger and more structured ...

Project configurations splinters to different configurations files and in some cases it additional seems to lead to code/variables repetitions if you need to include different modules with same variables settings ... in every case more code is needed. But up to now that seems to be the future ...

Upvotes: 3

Related Questions