Private vs. Public (Part 3)
Tags: css, webdev, tutorial, todayilearned
Published: 2019-10-09 03:52:28

The new module system for Sass allows for certain members to be private, while others may remain publicly exposed for consumption.

This pertains mostly to library authors but this can also be wildly useful to allow developers to consume libraries, but also have the ability to adjust configurations.

Library authors can now make their helpers and members private which may cause catastrophic issues when edited, and expose public configurations for those members that should be configurable. This comes in extremely handy when working with CSS UI and utility libraries.

## Public
I created a CSS utility library ([fulcrum-css](https://www.npmjs.com/package/fulcrum-css)) that allows developers to add simple adjustments to elements, add spacing, and provides a grid built with flexbox to control layouts. The aim being to keep code dry and give the markup meaningful and identifiable class names. The grid is currently based on a 12 column system to make it easy to transition from something like Bootstrap to this smaller utility library for your project. Wouldn't it be nice if the developer could decide the number of columns that they would like to use, and pass that to the configuration of the grid though? Previously you could declare your config variables with `!default` and as long as you declared that variable prior to the import with the default variable your declared value would be used. You should still use `!default` when declaring your variables, but let's take a look at how this would work with the new `@use` rule.

#### Public members for configuration:

Here are a few config variables that are used with this grid implementation:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/2ytjz3rntq7psnfe3yb0.png)

What happens if we want a grid that only has **6** columns:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/7uyqibrqrdhwy4sxgtuh.png)

How to solve this with `@use`:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/nkscjdvyblujfxn1cfy6.png)

You can also do this with a namespace that you provide:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/oc31j8yvfhuuqj5id5am.png)


## Private
By using the `@forward` rule, library authors can decide what is able to be exposed from one module to another. If you want to allow a stylesheet to consume and imported sheets members but not allow access to them from the importing stylesheet, you simply do not forward them.

First let's take a look at how to forward members of an imported module:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/kwb5qb336irtacftij2v.png)

Doing this would allow the members from the *colors* and *typography* modules to be accessible to any stylesheet consuming this module. It is important to note that `@forward` _does not create a namespace_, however when importing this sheet you can access the forwarded members with the consuming modules namespace:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/w1244yszg3r377nz7xd5.png)

Here the *base-config* module allows access to the *colors* modules members because they were forwarded from the *base-config* module. If you do not want to allow this, and would like to simply not forward the colors module:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/q67rxddc8mgytiavhl9t.png)

Since we are no longer exporting the *colors* module, if we try to access the `$yellow` member through the *base-config* module:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/gr6zbujqnxuv7z7ytxmh.png)


We end up with this error:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/cgobsks3tfv5p94tusgr.png)

Another way to create private members is to `hide` them in the `@forward` rule:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/9nc3no3qmylpdvtpwnzc.png)

This will keep the `$yellow` variable private, but still expose all the other members:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/5rxx7xj6p8x53mwccs0p.png)

This functionality helps library authors keep their utilities private, while also allowing them to expose public members so that the consuming application can adjust configurations provided by the author. This creates a much more robust platform for configurations when it comes to working with libraries, and I already have tons of ideas on how to improve mine with this!


**If you would like to see more in this series, drop a comment and tell me what you would like to know. I will do my best to get back to you, and add to this if the demand is high enough. If you would like to learn more about fulcrum-css, the utility library I created, install it with [NPM](https://www.npmjs.com/package/fulcrum-css) and kick the tires of it. If you like it, give it a star on [github](https://github.com/gtyrkicksin216/fulcrum-css). If you hate it, or see something that could be added to it, feel free to open an issue regarding your feature request/comment. This library does not currently utilize the new Sass Module System but I will undoubtedly be moving it over to this shortly. I'm also working on getting a robust set of documentation for this library set up, so bear with me and if you have questions on how to use it drop me a message.**