• 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 13/03/2023

Choose when to use mixins vs extensions

Mixins vs extensions

On the surface, mixins and extensions are very similar; you have to burrow into the compiled code to discern the difference in function. And that makes it tricky to decide which to use in which situation.

One situation where there's no doubt which to choose is whether or not you want your block of code to use arguments or not. If you need to introduce any sort of argument, use mixins; there’s no other choice.

Aside from arguments, the difference between the two is that you end up with duplicate rules with mixins, and with extensions, you end up with duplicate selectors.

So which should we use? 😧

The answer lies with the extend’s duplicate selectors. You can scroll to the h1 block in the compiled CSS sheet and know everything there is to know about it: except for its typography. To find its typographic properties, randomly scroll around until you find it in a list with other random selectors. But you might not remember that you had extended it, and since there’s no actual indicator that you defined any typographic properties to h1 at all, extension or otherwise, you might get confused and frustrated. 

The verdict: mixins or extensions?

Well, when it's put that way, the answer is actually pretty simple: don’t use extensions.

I know, I know. Mixins produce a bunch of duplicate code! Yes, they do. But they don’t affect the organization of your CSS. Extensions destroy the order and predictability of your codebase to save you from repetitive code. It’s not worth it.

Stick with mixins. The resulting code will be cleaner and easier to maintain, even if it is a bit lengthier.

But… but… why? Why did we spend all of that time on extensions?! 😫

Remember way back at the very start of this course? I said that CSS is tricky because there are no concrete rules for architecting CSS? That means other people will have built their CSS ecosystems differently, and sometimes that will include extensions.

You will run into Sass extensions. Even though you won’t be writing your own, knowing what they are and how they work are vital to being an Sass developer. So, please don’t build a time machine to travel back in time to my writing this and seek revenge, because - you know - the obliteration of all of humanity and all. Thanks!

Now that we've gotten all that sorted, and since we’re sticking with mixins, let’s take it up a notch. In the next chapter, we’ll use some built-in functionality from Sass to take them to the next level.

Let's recap

  • Mixins allow for arguments but cause duplicate rules. 

  • Extensions don't allow for arguments and cause duplicate selectors. 

  • You'll come across extensions in code, but for cleaner code, choose mixins when writing your own.  

Exemple de certificat de réussite
Exemple de certificat de réussite