feat(core): add support for multiple extends on a simple selector by using composition

[barak007]

• Add -st-compose to StylableDirectives
• Process multiple extends into -st-compose after the first one
• Reorder resolver object
• Fix bug wrong meta for local classes from parent resolution
• Export multiple composed classes

This feature will allow to write multiple -st-extends on parts. the first extends defines the type like before and the rest will be added to the JavaScript module exports.
Example:

.root {
  -st-extends: a b c;
}
.a {}
.b {}
.c {}

exported classes

{
  root: "root a b c",
  a: "a",
  b: "b",
  c: "c"
}

[tomrav]

A couple of questions about this:

• -st-compose or -st-composes?
• comma or space separated?
• is there any difference in composing an inner part vs. a root? (e.g. named/default imports)
• should we not expose -st-compose as its own directive as well? or is there no use-case for it without extending the type?

[idoros]

PR talks about -st-compose and also the code adds -st-compose, but the feature seems to be based on -st-extends.

[tomrav]

PR talks about -st-compose and also the code adds -st-compose, but the feature seems to be based on -st-extends.

Yes, his suggestion is it to implement -st-compose as a hidden directive and to use it through the multiple extends syntax.

[idoros]

Didn't understand that from the description. So -st-compose is a real thing that can be used to compose classes without inheriting any type (when you say hidden, you mean undocumented)? and the new feature just appends the -st-extends 2nd...Nth classes to compose?

If true, then I'm not sure why you would add to the complexity of -st-extends. I would simply expose -st-compose as a way to allow class appends and not mix the features. We might want to expand extend in the future.

Also, what if a class that contains multiple composed classes is composed into another class, are all classes merged in?

[barak007]

-st-compose is an internal directive you cannot write it in css you should use -st-extends.
for now we are not implementing multiple type resolution (union/intersections) only the first extends is considered as type.
multiple composed classes are exported together.

.a{
  -st-extends: b;
}
.b{
  -st-extends: c;
}
.c{
  -st-extends: d e f; 
}

.d{}
.e{}
.f{}
.

export for a is: a b c d e f

[idoros]

I understand that now. Still think it's a mistake to complicate -st-extends. Compose can be exposed without changing extend

[tomrav]

Let's say it's a separate directive, then the following example is valid?

.a {
  -st-extends: b;
  -st-composes: c;
}
.b {}
.c {
  -st-composes: d;
}
.d {}

export for a would be a b c d?

[idoros]

export for a would be a b c d

Yes, I think this makes sense.

I will try to sum up my reasoning for exposing -st-compose and keeping -st-extends as is.

I think the current behavior of -st-extends is correct, but complicated as is. Using -st-extends on a class name causes 2 things:

1. merge the type of the reference to the class
2. append the reference output class name to export - only if its not a root of a stylesheet

The reason root classes are not appended is because we assume that the root of a stylesheet is a component, and since the component code doesn't assume anything about the code that uses it, it will append it's own style root. So if a root class is extended, no extra class name is passed, and there is no duplicate class name in the DOM. Another benefit is that Stylable warns in development when an extending class is not applied to the component it extends.

The current limitation with -st-extends is that it only accepts a single reference, that is because we didn't want to allow for union types. At Least for the moment.

I think ^{bringing back} -st-compose is good because it opens up more styling patterns that don't necessarily need the complexity we currently have with -st-extends (types, components pattern).

Keeping -st-extends as is will keep things simpler without making future changes much harder.

[barak007]

close in favor of progress in #2299