Improving variants

[hbriese]

Unistyles has been a great addition to the ecosystem, and I thought I'd provide my observations on the variants api after using them for a bit. It'd be great for this to be a richer discussion beyond my proposal

variants are too verbose

Variants were a great addition to v2, but are quite verbose & cumbersome.
To me, their primary benefit seems to be injecting variables into the whole stylesheet, instead of per-style with dynamic style functions.

createStyleSheet(({ colors }) => ({
  button: {
    variants: {
      verifcation: {
        safe: {
          backgroundColor: colors.primary,
        },
        unverified: {
          backgroundColor: colors.warning,
        },
        ['domain-mismatch']: {
          backgroundColor: colors.error,
        },
        malicious: {
          backgroundColor: colors.error,
        },
      },
    },
  },
  buttonLabel: {
    variants: {
      verification: {
        safe: {
          color: colors.onPrimary,
        },
        unverified: {
          color: colors.onWarning,
        },
        ['domain-mismatch']: {
          color: colors.onError,
        },
        malicious: {
          color: colors.onError,
        },
      },
    },
  },
}));

Proposed api

Variables are provided to createStyleSheet directly, resembling dynamic styles functions but at stylesheet level

+ Less code (13 LOC vs 35)
+ More composable. ts-pattern is shown here
+ No need to repeat all variants in all styles
- Explicit typing required when declaring stylesheet

Note that this doesn't necessarily have to be a breaking change

interface Variants {
  verification: 'safe' | 'unverified' | 'domain-mismatch' | 'malicious';
}

createStyleSheet(({ colors }, { verification }: Variants) => ({
  connect: {
    backgroundColor: match(verification)
      .with('safe', () => colors.primary)
      .with('unverified', () => colors.warning)
      .with(P.union('domain-mismatch', 'malicious'), () => colors.error)
      .exhaustive(),
  },
  connectLabel: {
    color: match(verification)
      .with('safe', () => colors.onPrimary)
      .with('unverified', () => colors.onWarning)
      .with(P.union('domain-mismatch', 'malicious'), () => colors.onError)
      .exhaustive(),
  },
}));

An object could be used instead of `ts-pattern`, or whatever may be appropriate

backgroundColor: {
  safe: colors.primary,
  unverified: colors.warning,
  ['domain-mismatch']: colors.error,
  malicious: colors.error,
}[verification],

[jpudysz]

Hello, and thank you for opening this discussion.

I'm open to extending the API, but only if we can achieve additional benefits, such as supporting compound variants.

The issue with the API you proposed is that it allows you to select only a single property. You have 13 lines of code per style, but with a more verbose API, you can actually save some lines. It may not work for a single property, but for a larger group, it's a different story.

I don't want to enforce tools like ts-pattern, as they are opinionated. It's challenging to create a small API that fits all.