- Creating Powerful Mixins 4:30
- Smarter Mixins with null and Keyword Arguments 8:17
- Advanced Mixins Challenge 4 objectives
- Add Conditional Logic to Your Stylesheets 8:11
- Storing Values in Maps 7:37
- Write Loops with @for 6:24
- Loop Through Lists with @each 4:25
- Loop Through Data in a Map with @each 6:18
- Maps and Loops Review 5 questions
- Handling Errors with @error and @warn 3:51
- Debugging Sass with Sourcemaps 3:08
- Debugging Review 5 questions
Preview
Video Player
00:00
00:00
Handling Errors with @error and @warn
3:51Providing feedback to developers when something goes wrong in their code is important. Sass offers directives that provide feedback to the compiler and help you avoid mistakes. In this video, we'll use the @error and @warn directives to make sure our media query mixin arguments are valid.
Code doesn't always run smoothly on your
first, even second or third attempt.
0:00
Getting used to working with SAS and
writing it well takes time and practice.
0:04
So it's common to make lots
of mistakes along the way.
0:08
Even when you become a SAS pro there
will be times when parts of your code
0:10
just won't work.
0:14
So in these final videos we'll look at
the way SAS helps you handle errors and
0:15
debug code in the browser and console.
0:18
Providing feedback to developers when
something goes wrong in their code is
0:20
crucial in any programming language.
0:24
So SAS offers three directives that
provide feedback to the compiler and
0:26
help you avoid mistakes error,
warn, and debug.
0:29
I'm only going to cover error and
warn in this video, but
0:33
you can learn more about the debug
directive in the teacher's notes.
0:37
So the error and warn directives are
incredibly useful for making sure function
0:40
and mixin arguments are valid and
that you're following best practices.
0:44
For example, one problem with our media
query mixin is that it's error-prone and
0:48
fails without a warning.
0:52
For instance, if you misspell or
0:53
provide an incorrect breakpoint name,
Everything comes to a halt.
0:55
The compiler stops running and outputs
the error Invalid null operation null
1:01
lt 576 in the browser,
console, and output CSS.
1:07
So this message is not very helpful
because it provides no warning or
1:14
explanation of what caused the error.
1:19
So the error and warn directives
give you the ability to output
1:22
custom messages that help you track down
errors and fix mistakes in your code.
1:27
So over in the mixins
partial let's add a condition
1:31
to the media query mixin that checks for
invalid values.
1:35
And we'll make it the first condition
using the if directive to check
1:39
if the value is equal to null or
if it's invalid.
1:44
Inside the curly braces we'll
use the error directive
1:50
to print a custom error message
within a set of quotes.
1:53
So inside the quotes I'll use
interpolation syntax to insert the value
1:58
of break in to the error message which
will read is not a valid breakpoint name.
2:02
So now let's not forget to update our
original if condition here to an else if.
2:13
Give this a save.
2:23
And if you the pass the media query
mixin an invalid value for break.
2:24
So for example, fooo.
2:28
Once you save your changes the compile
stops running and the error directive
2:31
outputs the message Error fooo is not
a valid breakpoint name in the browser,
2:36
console output,
as well as the stack trace in style.css.
2:42
So it traces back to the source of
the error to help make debugging easier.
2:47
While the error directive
immediately stops the compiler and
2:52
forces you to correct the mistake,
the warn directive is less strict.
2:57
Warn outputs a warning message but
allows the compiler to keep running.
3:03
So if I change this to warn, save,
the compiler keeps running, but
3:07
over in the console you'll see
that it outputs the message,
3:12
warning foooo is not
a valid breakpoint name.
3:16
So the error directive is useful for
validating arguments to mixins and
3:21
functions.
3:26
It notifies developers when
they've entered invalid data.
3:27
And use warn to inform developers
of deprecations in the code like,
3:31
unnecessary vendor prefixes or to suggest
that they follow certain best practices on
3:35
a project,
like using m-values instead of pixels.
3:40
I've posted links to more
examples of how to use error and
3:46
warn in the teacher's notes.
3:49