Challenge 3: Solution

[00:00:00]
>> Mike North: Let's address the questions before we go over the solution to the variables exercise. Yes?
>> Speaker 2: Yeah, I had one. So does it matter where in your Sass value call in the partial filename?
>> Mike North: Great question.
>> Speaker 2: Should it be at the very top or should it just be outside those declarations?

[00:00:18]
>> Mike North: Great question. So if you do it at the very top, then all Scss you define below that point will behave as if all of the stuff that is defined in that import is in scope. You can actually do an import from inside a declaration block if you wanted to make certain rules available, certain variables and things available only within a particular scope, right?

[00:00:44]
So there are two things you need to consider. One is whether you want stuff to be available in the global scope. And typically, that would be like imported at the very first line of the file. And the second is if you don't want it to be in that scope, is there a place you could put it where things wouldn't collide with other important things?

[00:01:08]
It would be contained. So if you, for example, had this variables file and you put that import inside container, you would only have access to those variables within that scope there. Similar to the local variables example that we looked at earlier. And this, by the way, this is another underutilized aspect of the import selector, where you could define some classes in an import and you could almost bring them into a selector.

[00:01:39]
There are better ways to do this with Sass, but this is one way to do it. Where if we moved our button primary into another file, we could actually just bring those rules into button with an import. It's almost like a copy and paste. Copy file contents, and replace the import with that.

[00:02:00]
Were there any other questions?
>> Speaker 3: Is the namespacing on import, is that just the relative path on the hard disk?
>> Mike North: Yes.
>> Speaker 3: Okay.
>> Mike North: Namespacing on import is a relative path on the hard disk. That is one thing that will resolve. But also keep in mind that you can set up the Sass compiler to have access to other paths.

[00:02:21]
So actually, look, you have ordering of the paths, right, and it will go and try to resolve the first thing that it can encounter. So an example would be if you had a file in your path called Bootstrap, that would overshadow the Bootstrap library you might have brought in.

[00:02:42]
So this is why sometimes, it is nice to bring things in. This is why Bootstrap doesn't have its underscore variables file at the top level of the of its import. You bring that in with bootstrap/ _variables, so that they're trying to make it so that you don't have any collisions there.

[00:02:59]
>> Speaker 3: So I had a question about the bloat in your CSS where you import. So if you were doing the local version of that, of scoping at the import, you get everything in that every eye, right?
>> Mike North: So, [LAUGH] that's a good question there. The way I typically use imports, I don't rely on them to do too much of the crazy stuff that I just said was possible.

[00:03:26]
To be clear, I didn't say, it was advisable that you do that. My Sass, in terms of my imports, looks as follows. I'll have one file that is entirely comprised of imports, and that will usually be the only non-partial Sass file that I have. That'll be the only thing that doesn't start with an underscore.

[00:03:46]
And I'll usually call that app.scss, and that will turn into my CSS. And we'll begin by importing the variables and making sure that you get that right in terms of what needs to get defined before what. And then I'll import other things from other places. Now, I told you that importing was sort of a find and replace thing.

[00:04:09]
What this means is that because wherever I'm consuming my other partials for my components and things, those will be already brought into a scope where variables are defined. They're already defined in my app.scss on a higher line, right? That means that I don't have to import my variables into every single file.

[00:04:30]
Now, what that does mean is that each of my individual files, they are not freestanding. But partials are not really meant to be freestanding. So this is an appropriate way to do it in my mind. But yes, to your point, importing is a copy-and-paste style operation. And importing many times will result in many copies of that being proliferated through your app.

[00:04:55]
So that being said, with the approach that I just advocated for here, typically you don't need to worry about that, because anything you are importing into a file that has classes, is something that will evaluate to no CSS. So that would be mix ins and variables and one other thing called placeholders that we'll talk about later today.

[00:05:21]
And everything else sort of just all being brought together into one big piece. And this pattern scales up really nicely because. Now it's, you know we're used to boiling everything down until like as few files as possible, I mean until the whole world is on HTTP/2 and like breaking things up into multiple files comes to no cost to our users.

[00:05:41]
Like we need to move in the direction of consolidating and concatenating everything together and this gives me a nice way to sort of, Do that right from the start with imports and not have build tools define how things are-
>> Speaker 3: It sounds a little bit like the structure that Max advocates.

[00:06:03]
>> Mike North: Yep, in addition to that, it's a lot like the way Rails would structure styles. It is a lot like the way Ember structures styles.
>> Speaker 2: Smex is awesome.
>> Mike North: What is Smex? It is that CSS architecture it is like suits and smex those different methodologies.
>> Speaker 2: Just how to organize your folders if you could just use bin and then smex it would be perfect Interesting.

[00:06:34]
[CROSSTALK]
>> Speaker 3: A little modular architection, see what it says, and Jonathon Snook-
>> Speaker 2: Snook. You guys had Snook here. Like a couple years ago [CROSSTALK]
>> Speaker 3: Yeah, we actually have a smash course on with-
>> Mike North: Cool.
>> Speaker 2: Yeah, he's the best.
>> Mike North: Awesome. Sounds like there's a lot of convergence around a similar set of patterns.

[00:06:57]
So with that, I'm going to go through the solution to this exercise here. If there are no other questions and none online. So let's look at our code here
>> Mike North: We are currently not running and let me go back to my slides here. Variables is the name of the exercise.

[00:07:20]
So run I don't know if that is. run -e variables. And we're up and running on localhost:3000 we can get rid of our terminal here.
>> Mike North: Do a refresh.
>> Mike North: And collapse all our folders. All right, variables.
>> Mike North: So here's our SCSS file. I didn't make everyone do the similar work that would be required to get here from excercise one.

[00:08:00]
This should like a little bit like your excercise one solution. So I'm gonna go ahead and right at the I'm gonna import the variables file. You don't need to add the extension, you do need a semicolon at the end of the variable statement here, right? And then from within here, if I recall, let me just double check the instructions here.

[00:08:22]
So hot bush for the primary background. A $venus border so lets do that. Border should be $venus and this should be $hopbush. And for the second background $nebula background and a $patina border.
>> Mike North: And it's that easy. Now we could start just to give you a preview of like the lighten, darken the color functions here.

[00:08:57]
We could even do this like saturate
>> Mike North: By 20% and make it a more vivid Pink there, or darken by 20%. And you see I've got code completion in here from a Visual Studio plugin that tells me, I'm using SASS, and this is the result of this function, and these are the arguments it takes.

[00:09:23]
So really easy to use, really easy to import and consume variables.