Welcome to the thrilling world of Sass mixins where you teach your CSS to obey you and stop repeating itself like a broken record. This little guide shows how to write reusable SCSS mixins accept parameters and avoid copy paste that makes your stylesheet sad and slow to edit.

Why use mixins in your frontend toolbelt

Mixins let you bundle a block of styles and reuse it across selectors. That means less repetition fewer bugs and fewer angry code review comments on Monday morning. Mixins are especially handy for consistent layout helpers visual patterns and configurable components.

Write a simple mixin

Create a mixin by naming a reusable block of styles. Give it a clear name so future you or your coworker does not stare into the void wondering what happened.

@mixin center
  display flex
  justify-content center
  align-items center

Note that the snippet above is pseudo SCSS to keep this readable. In actual SCSS you must put a colon between a property and its value and end each declaration with a semicolon.

Include the mixin where it makes sense

Drop the mixin into a selector so you do not copy paste identical blocks and multiply future maintenance pain.

.button
  @include center
  background blue
  color white

Make mixins configurable with parameters

Parameters transform one mixin into many variations without rewriting the whole thing. Pass values to tweak colors spacing shadows and more.

@mixin box-shadow $x $y $blur $color
  box-shadow $x $y $blur $color
.card
  @include box-shadow 0 4px 10px rgba(0,0,0,0.15)

Again that is illustrative pseudo code. Use the real SCSS punctuation when you type it into your editor.

Defaults and basic logic

Defaults let callers omit arguments without breaking things. Simple conditional checks let a mixin optionally add features like a heavy shadow only when requested.

@mixin btn $bg default blue $pad default 8px
  background $bg
  padding $pad

  // optional behavior via an if style rule
  // in real SCSS you would use @if and true false checks

Use the keyword default or specify sensible fallbacks so your mixin is friendly to lazy humans and busy sprint schedules.

Best practices that do not suck

• Favor small single purpose mixins over giant catchall monsters
• Name mixins descriptively so the intent is obvious
• Accept parameters and supply defaults for ergonomics
• Keep output predictable to avoid surprising side effects

Quick recap

Write clear mixins include them where styles repeat accept parameters for flexibility and use defaults and conditionals for nice fallbacks. The result will be cleaner DRY friendly styles that are less painful to maintain. You will not cure all CSS woes but you will win a few battles and that is progress.