Welcome to part III and I hope you have been reading the full series, to get more context. We are going through the analysis and explaining some architecture decisions, behind a lazy-loading strategy for components.

We are now going to explain what style abstracts are, and why they are so useful, particularly, when you want to ship the smallest amount of code to any page!

What are (styles) abstracts?

When talking about CSS pre-processors architecture, abstracts are contained in a folder that, compiled as stand-alone, does not output any code at all.

This folder contains tools and other utilities, such as

• variable and maps definitions
• mixins
• functions

Teaching sass (or any other CSS pre-processor language) is not in the scope of these series, but you can start here, with the official documentation

When we want to use abstracts for our components, we may want to structure it like this

|abstracts
|variables
- colors.scss
- _fonts.scss
- _breakpoints.scss
- _import_variables.scss
|mixins
- _button.scss
- _grid.scss
- _font.scss
- _import_mixins.scss
|_functions
- _rtl.scss
- _import_functions.scss
all_abstracts.scss -> barrel file that imports all abstracts

The above is just a slim example, but it should give you an idea of what kind of contents your commons scss package should have, and how to structure it.

Variables

If you're a beginner, you may want more examples of what should go there.

Colors

If you have a design style guide, you can easily extract a color scheme into this file.

Pro-tip! Call your color variables after a code convention (like $c-01 or $c-primary), not a human-readable name. Human readable names for colors, get messy too fast.

Breakpoints

Breakpoints are certainly very similar across projects. So you should assign them to variables to quickly reuse them.

Fonts

Font definitions are another scheme you can extract from the design guide. It is very likely you can map all headlines to a definition, all summaries to another, all descriptions to another set of rules, and the text bodies to yet another one. But for all your components, each one of those will be identical. Meaning, all h2's in a certain context will have the same font style, weight, size, etc. All text copies will share the same attributes too.

Mixins

Button Mixin

So we spoke about the button component in part II, and it was clear as well: it is a component that participates of the composite of many other container components.

A button could be the button link of a teaser, the load more button of a teaser list, the submit button of a form. But in an app with some minimal UI/UX care put on, those buttons for sure share characteristics. And you may want to have a mixin control that.

In essence and to wrap up

** When you aim at lazyloading components, it is because you care for performance and want to be able to download only the necessary code and assets, when a page of your site/application is requested.**

The very first step to an effective lazy loading strategy is being able to separate containers or wrapping components, from features that can be used as standalone or composite, to structure your pages and organize content.

Once you have done this, you need to be able to extract common definitions from those components. Colors, fonts, breakpoints, etc, can be extracted into common variables. Behavior can be assigned to mixins and functions.

Variables can be passed as !defaults to the mixins, so can override them later per tenant.

** All these primary and common definitions can be organized as abstracts, to be imported and used in each component, in a consistent way.**

You can move them from your repository to a library or (npm) package, to be maintained as stand-alone and consumed by many different tenants. They can even be installed as a dependency on completely independent platforms or projects.

For that, once we have our abstracts ready, we can publish the package.

Learn about it in Part IV!