Labs are hands-on coding projects that you build along with Tonya as she explains the code, concepts, and thought processes behind it. You can use the labs to further your code knowledge or to use right in your projects. Each lab ties into the Docx to ensure you have the information you need.
Each lab is designed to further your understanding and mastery of code. You learn more about how to think about its construction, quality, maintainability, programmatic and logical thought, and problem-solving. While you may be building a specific thing, Tonya presents the why of it to make it adaptable far beyond that specific implementation, thereby giving you the means to make it your own, in any context.
In Part 2e, you will finalize the Entry Content Sass module, which includes the entry title, entry header, entry meta, entry content, and entry footer. You’ll think through all the components and then break up the partials to fit those components. You’ll migrate the media queries, refactor, identify and assign variables, and then refactor to remove redundancies and make it more readable. Then at the end, let’s setup the README and gitignore files and then commit the changes using git.
In Part 2d, you will finalize the Footer Sass Module, which includes the footer widgets and site footer components. Just like with the other Part 2 labs, you’ll migrate in the media queries, assign variables to make it easy to customize, and refactor it further to remove redundancies and clean it up. Then at the end, let’s commit the changes to GitHub.
In Part 2c, you will finalize the Header Sass module, which encompasses the site-header area including the site title, site description, and, if configured, the header right area. You’ll migrate in the media queries, assign variables to make it easy to customize, and refactor it further to remove redundancies and clean it up.
WooHoo! You are now done with converting the native CSS stylesheet over into modular Sass. I know that was a long process, but you only needed to do it once. Now you have a codebase that you can use on every single project and site that you build. Quick Summary of What You Learned: It’s Sass and not SASS. You have a modular codebase that you can use on every single project. Color changes are quicker as you change them in one spot and your entire stylesheet changes. Typography changes are quicker. Dimensions are customizable in one spot. It will […]
It’s time to check that we have all modules and sub-modules imported into their index files. And then we’ll make sure that everything is imported into the style.scss main style file. We’ll talk about the DocBlock too.
There are various strategies available to you for handling the media query breakpoints including these options, which all do the same thing: The advantage to setting a new breakpoint in the _breakpoints.scss file is you make all changes to your breakpoints in one place. Now that we’ve integrated media queries into the styles at the component level, this technique means you are not searching through all of the partials to find where to change what you need. Therefore, using the Neat function new-breakpoint() allows you to be more efficient which will save you time in working with your new codebase. […]
For the screen sizes, let’s use this naming convention: $screen-size–smallest. The name is now more clear and it complies with BEM. Whew.
Let’s apply the BEM naming convention to the dimensions variables too.
Did you notice that we are repeating hex colors within the color variables file? Why? That’s not efficient and it’s redundant. Instead, let’s specify the colors at the top of the file and then use those variables within the configuration.
Just as we did with the typography, let’s apply BEM naming convention to the color variables, e.g. $button–hover-background-color.
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.