Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Time to write another story on `@apply`...
When we write code like this:
```css
.a {
@apply b;
}
.b {
@apply uppercase;
color: red;
}
```
The we create 2 Nodes in our context to keep track of. One has
identifier `a`, the other has identifier `b`.
However, when we have an `@apply` and it contains multiple
declarations/atrules, then we have to split up the (aka partition) the
node into multiple nodes so that we can guarantee the correct expected
sort order.
This means that the above example technically looks like this:
```css
.a {
@apply b;
}
.b {
@apply uppercase;
}
.b {
color: red;
}
```
If this was your input, then we would still have 1 node for identifier
'a', but we woudl have 2 nodes for identifier 'b'.
As mentioned earlier, this is important to guarantee the correct order,
here is an example:
```css
.b {
@apply md:font-bold xl:font-normal; /* Here we can sort by our
internal rules. This means that the `md` comes before `xl`. */
}
```
... however
```css
.b {
@apply xl:font-normal; /* This now exists _before_ the example below */
}
.b {
@apply md:font-bold; /* Because we respect the order of the user's css */
}
```
So to guarantee the order when doing this:
```css
.b {
@apply xl:font-normal;
@apply lg:font-normal;
}
```
We also split this up into 2 nodes like this:
```css
.b {
@apply xl:font-normal;
}
.b {
@apply lg:font-normal;
}
```
The tricky part is that now only 1 empty `.b` node exists in our context
because we split the orginal up into multiple nodes and they are new
nodes which means that they have a different identity.
This partitioning used to happen in the expandApplyAtRules code, but
this is a bit too late because the context has already been filled at
this time.
Instead, we move the code to the front, as if you wrote those separated
blocks yourself. Now the code to inject those nodes into the context
happens in a single, consistent spot.
Another good part about this is that we have better consistency between
each layer because it turns out that these two examples generate
different results...
```css
.a {
@apply b;
}
.b {
@apply uppercase;
color: red;
}
```
... is different compared to:
```css
@tailwind components;
@layer components {
.a {
@apply b;
}
.b {
@apply uppercase;
color: red;
}
}
```
Even if both `a` and `b` are being used in one of your content paths...
Yeah.. *sigh*- Loading branch information
1 parent
9c72add
commit 6462f37