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
Here is what will happen with the @import
rule
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
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!
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.
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:
Similarly, if you try to use the same provided namespace an error will occur:
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.
Top comments (0)