Using StyleX is great, but the guidelines are super restrictive

[hyperknot]

I'm having a great time using StyleX, but many of the things I'm using is not following the guidelines.

For example look at this:

  base: {
    ':not(:last-child)': {
      marginRight: 5,
    },
  },
  
  trigger: {
    '--trigger-icon-color': 'hsl(0,0%,40%)',  
    ':hover': {   
      borderTopWidth: 1,
      borderBottomWidth: 1,
      '--trigger-icon-color': 'hsl(0,0%,0%)',
    },
    ':is([data-disabled])': {
      cursor: 'default',
      ':hover': {
        borderTopWidth: 0,
        borderBottomWidth: 0,
        '--trigger-icon-color': 'hsl(0,0%,40%)',
      },
    },
  },
  
  triggerIcon: {
    color: 'var(--trigger-icon-color)',
    marginBottom: -1,
  },

Here, I'm not supposed to use :hover, :is([data-disabled]) and setting and getting CSS vars like --trigger-icon-color.

Some of these are necessities, as I need to mirror the exact CSS from a component library.

Others, like the :hover are just much cleaner this way.
If I put 10 rules in a single :hover, why would I split them into 10 individual rules? The point of putting everything under :hover is to see exactly what's happening there. Like an if block in the source code. You don't write 10 if blocks with 1 line inside each, you write 1 if block with 10 lines inside.

:not(:last-child) - I have no idea how would I do this without making the code way more complicated and trying to count this JS side, and then passing it on as props.
What about n-th child? Do you implement a modulo function in a for loop and pass the result as props?

At this point, I'm not sure I understand the philosophy behind StyleX. Why not allow these use cases?
They work great, but all these are not supposed to happen (as eslint is very enthusiastic to tell me).

How would you rewrite this to be more in line with the StyleX philosophy?

[nmn]

First, let me say that using --trigger-icon-color is not against the guidelines. We generally recommend that you use variables defined using StyleX with stylex.defineVars, but we intentionally allow using keys that start with -- to allow you to have compatibility.

Now, let's consider the other issues you mentioned, which are essentially all about selectors.

:hover at the top level

I know that many devs are used to writing styles this way and this was the legacy pattern that StyleX started with. However, we discourage such use and recommend putting pseudo classes within the value of style properties instead.

const styles = stylex.create({
  foo: {
    color: {
      default: 'black',
      ':hover': 'var(--accent)', // You can use raw CSS variable strings if you want.
    }
  }
})

So why?

This is done mostly to make composing styles, i.e. merging styles across components and files absolutely predictable and consistent. This makes styles work just like inline styles and the last applied style always wins.

And if you can re-train your brain to stop thinking in terms of "default styles" and "hover styles" and instead just think about styles and values under different conditions for different properties it can lead to much more maintainable and consistent styles when it finally clicks for you.

It does make it hard to use the pattern when "default styles" are defined in one place and "hover styles" in another place, but this, too, is by design as it can lead to inconsistent unmaintainable styles. Being forced to consider the value under all conditions in one place leads to more reliable styles with no accidental "gaps".

:is([data-disabled])

This is usually fine to use. The reason we discourage is mostly to help make your generated CSS as efficient as possible. Instead of using a attribute selector, you could, in theory, apply styles conditionally and avoid generating extra CSS rules.

This is mostly relevant for larger apps as without such guidelines in place developers end up using all sorts of custom selectors and defeating the purpose of having re-usable atomic CSS rules.

If your app isn't going to keep growing, or if you have the discipline to limit yourself to a few specific types of selectors, you can go ahead and use them.

:not(:last-child)

This, again, is mostly about efficiency.

You can always use default and :last-child instead of using a unique :not(:last-child) selector. Again, if you don't care about the size efficiency of CSS, you can use this selector, just like :hover etc.

React Native

Another reason for many of these restrictions is compatibility with React native in react-strict-dom, but you don't seem to care about that.

Verbosity

One undocumented feature of the StyleX compiler is that it is able to understand simple single expression functions at compile time, so you can write a function like this reduce the amount of :hover you have to write:

type V = null | number | string;
const defaultHoverActive = (base: V, hover: V, active: V) => ({
  default: base,
  ':hover': hover,
  ':active': active,
});

const styles = stylex.create({
  foo: {
    color: defaultHoverActive('black', 'var(--accent)', null),
  }
});

The rules for such functions are bit stringent and I'm still working to make it work more often which is why it is undocumented, it should get better over time.

---

Hopefully that answers all your questions?