Namespaces (Part 2)
Tags: css, webdev, tutorial, todayilearned
Published: 2019-10-09 02:56:08

# Namespaces
## Avoiding name collision
  - **`@import`:** With this rule, using simple would almost guarantee that there was a possibility of these names being used elsewhere in the application, which would cause value re-declaration by those used further down in the cascade. This forced developers to create names that were overly complex and not always correlative to what they were tied to.
  - **How `@use` solves this:** This rule, as previously mentioned, creates a namespace for the members that it brings in. This means that the same name can be used since it is part of a different namespace. Say you have a light theme and a dark theme. These themes each have different blue colors that they use. With `@import` you would likely have to name these something like `$lightThemeBlue` and `$darkThemeBlue`. This doesn't seem so bad right? But what if you have a white-label product that has _many_ themes that need to each have different blue colors. This could cause these names to get wildly out of control. With the new `@use` rule, you can just name these `$blue` in each theme module, and when imported it will be prefixed with a namespace that will ensure that you are getting the correct blue for that theme.

**Let's take a look at how this works**
First we have 3 theme files
![Theme Files](https://thepracticaldev.s3.amazonaws.com/i/792l2bqbzwbyrjftaneu.png)

Here is what will happen with the `@import` rule
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/7xinn6vhzxi8f530o17n.png)

Using the `@import` rule, members with the same name will always evaluate the the member that has been imported last.

Here is how the `@use` rule solves this problem
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/3777lq7cs5pw0vg6v0fz.png)

Using the `@use` rule, members with the same name are scoped to a specific namespace. This allows the same name to be reused in different sheets without overriding when multiple sheets are imported with the same member name. This means that you don't have to get creative with member names and reduce their correlative meaning to the property that they represent.

We can even go a step further and change the namespace to something more concise!
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/q405wixslqotccwfzc9l.png)

Using the `@use 'sheet' as name;` syntax, you can provide a custom namespace to the members of that sheet. This allows you to keep your file names meaningful, but reduce the size of the namespace by providing an alias for that sheet.

You can also provide the `*` top-level namespace to make members available without having to prefix with a namespace.
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/c1065i1kx8sdmio0k6b5.png)

This can be useful for sheets that you maintain and do not want prefixed with a namespace.

_**NOTE:** Only one top-level namespace can be provided, otherwise the compiler will throw an error:_
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/0gj517s0ac6ziva8gw2u.png)

Will produce this error:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/9qmug8p4l1gc4wupmlrc.png)

Similarly, if you try to use the same provided namespace an error will occur:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/97diiv59p8dm7dksgvqj.png)

Will produce this error:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/qeboqdre7t5osdhzlqmk.png)



With just this simple overview it is very easy to see that you could come up with wildly elaborate themes without having to come up with crazy names just to avoid collision.

**In the next part (Part 3) we will take a look at how to manage private and public members and imports.**