[RFC] Descendent and Sibling selectors about stylex HOT 8 OPEN

Too much freedom will lead to additional learning costs. And i noticed @zaydek mentioned whether when is composable. I think this is something that needs to be made clear. Repeating definitions creates extra work. Using API to define css selector is more friendly to javaScript string template. In my option, string template is hard to maintain and it is not friendly to the compiler.

from stylex.

What happens when multiple parent nodes use the same id ?

If two anscestor have the same id, then if either one matches the given pseudo-class, then the style would be applied. In practice, this is usually not a problem:

1. With :hover if a child is hovered, then the parent is hovered anyway
2. Same with :focus-within
3. Same with :active
4. With :focus, it's rare to have nested focusable elements and even rarer to need IDs on two parent focusable elements.

Most other pseudo-classes don't even make sense as something to observed IMO.

The use-case for multiple IDs is mostly specific to peers or descendents (using :has()).

@zaydek I considered an API with strings instead of function calls. There are a few reasons I don't prefer this.

1. Even though TS has template string types, Flow doesn't and that's what we use internally
2. Template Literal types are considerably slower at type-checking
3. A generic string implies the ability to use arbitrary selectors and we want to explicitly limit the selectors that can be used.

One other thing is I'd prefer if I don't need to create n+1 files everytime I want to do this kind of thing

We might loosen the requirement for a .stylex.ts file in the future when values are not being exported and are only being used locally within a file. For this proposal, however, I think the extra indirection adds value as we want to discourage the use of custom IDs as much as possible. Custom IDs will generally result in unique CSS that will not be shared and we want to push the usage of the default ID if at all possible.

However, whether we loosen the requirement for .stylex.ts files is a separate discussion that we can have.

The one benefit this has over the ID approach is that I don't need to create a .stylex.ts file to adopt this pattern.

Officially, you need a .stylex.ts file to use the variable hack as well. The fact that string variables work is an escape hatch to support legacy usage internally. It's not officially supported part of the API. Variables in StyleX should be defined using stylex.defineVars.

from stylex.

Would it be possible to support an API like:

const id = stylex.id()

...

[`${id}:hover &`]: {
  // ...
}

I would think there could be a couple of valid string interpolations the user could do, and I think these are possible to have typed in TypeScript because you can make expressions like ${string}:hover & and so on. I understand that perhaps you want to limit users from being able to put whatever they want there, but you can always have StyleX error on illegal expressions.

That being said, I can respect that you are trying to limit the API surface area as much as possible by relying on explicit, imported function calls rather than magical strings.

One other thing is I'd prefer if I don't need to create n+1 files everytime I want to do this kind of thing (+1 file for .stylex.ts). Perhaps this is a limitation of the Babel pipeline or something but I think one of the strongest principles of StyleX is colocation, so the decision to force users to having an extra .stylex.ts file around for these one offs isn't personally appealing to me.

Right now when I need to implement this kind of pattern, I use the CSS variable hack as alluded to in other threads. The one benefit this has over the ID approach is that I don't need to create a .stylex.ts file to adopt this pattern.

There is a real need for this kind of pattern overall and relying on JavaScript and event listeners is unwieldy and CSS variables feels like a work around.

from stylex.

What happens when multiple parent nodes use the same id ?

from stylex.

@nmn Got it, thanks. Other quick questions -- is when composable? I assume not but is it explicitly disallowed that you can do when.peerAfter(when.peerBefore(id, ":hover"), ":focus") or something zany like that? Not saying anyone would but if you haven't already, you might want to hard code some errors for these use cases. I say that because I've implemented anti patterns in the past without knowing, so having stricter errors up front would have prevented that. 🙂

Besides that I'm on board with this. I find when.ancestor slightly confusing because it's not the ancestor of the ID, it's the ID that is the ancestor in this case. Maybe when.is and when.has (instead of ancestor and descendent) would make this distinction more clear?

from stylex.