UI Guy, Dad, Ukulele Enthusiast
showing 21 lessons...
Writing SCSS @functions is similar to writing functions in other programming languages; they can accept arguments and have return statements. SCSS provides a ton of great features, but sometimes we need to roll our own function. We can do that too! They’re useful when the desired functionality isn’t available from the built in SCSS functions and a mixin just won’t do. In this lesson, we learn how and when to use SCSS function directives.
Writing similar classes with minor variations, like utility classes, can be a pain to write and update. Sometimes just a single character is the only difference between classes and updating the defining parameter means we need to change it for every class name and value. We can write a class one time and the @for directive can write all the minor variations for us. If the similar classes need to be updated, with the help of the @for directive, they only need to be updated once. In this lesson we learn how to leverage the power of the SCSS @for control directive to relieve the pain.
Tired of dealing with monolithic CSS files? Are requests for multiple CSS files hurting your performance? In this lesson we learn how to separate our styles with SCSS partials, and how SCSS imports compile to one file so there's only one request.
We can write reusable styles with the SCSS @extend or @mixin directives. Which one is better? It depends. A better question is, how do they differ?
change the source order, mixins don’t.
maintain relationships, mixins don’t.
share inherited traits, mixins don’t.
can extend multiple classes, mixins don’t.
can create multiple class declarations in the compiled CSS, mixins don’t.
can use the placeholder selector, mixins don’t.
can accept arguments, extends don’t.
can pass additional content, extends don’t.
repeat code when compiled, extends group class names together.
work well wIth media queries, extends have a limited interaction wIth media queries.
In this lesson we learn about writing reusable styles with the @extend directive and how it compares to the @mixin directive.
Copy/pasting the same code is redundant and updating copy/pasted code slows development velocity. Mixins are reusable chunks of code that are included, similar to calling a function, instead of copy/pasted.
Mixins have some nice features:
- Arguments just like functions.
- Arguments can have default values and optional values.
- Named arguments allow us to use optional and default arguments when the mixin is included.
- Variable arguments allow us to have a dynamic number of arguments when the mixin is included.
- The @content directive allow us to add additional styles when the mixin is included.
In this lesson we learn how to DRY up the code with the SCSS @mixin directive and make copy/paste a thing of the past.
SCSS nesting can produce DRYer code by targeting child elements without having to write the parent class. Nesting up to 3 levels deep can help us understand relationships between styles. The SCSS parent selector represents the parent class, so it can DRY up targeting pseudo-elements/classes and be an asset for naming conventions. In this lesson we learn how to remove the redundancy of targeting pseudo-elements/classes, and child elements by taking advantage of SCSS’s nesting and parent selectors.
Updating the same color or metric multiple times is no fun. SCSS variables improve maintainability by allowing one name to represent a value that can be used anywhere. SCSS variables also give us the power of creating our own naming conventions to express the intent of specific values. In this lesson we learn how to use SCSS variables to assign user friendly names to colors/metrics so one value change will update that value in all the right places.
The SCSS @for directive is great when we know how many iterations are required and we only need 1 variable. What if we need multiple variables to iterate over data sets? Hello SCSS maps and the @each control directive! In this lesson, we’ll check out iterating with lists and looping over data sets with maps and the @each directive.
Typescript generics are great for writing code that accepts any type. How do we write code that doesn’t accept any type, but instead accepts a range of types? In this lesson we learn how to use generic classes, interfaces and constraints to be more specific with our Typescript generics.
It can be painful to write the same function repeatedly with different types. Typescript generics allow us to write 1 function and maintain whatever type(s) our function is given. This lesson covers syntax and a basic use case for Typescript generics.
Handling state with Typescript enums, instead of booleans, is preferred because:
- Enums are more readable
- Enums can have as many states as you need while booleans only have 2
- You only need to keep track of state with 1 variable when using enums