css overload type purpose?

[datner]

Steps to reproduce

use css

Current behavior

N/A

Expected behavior

N/A

Context

The css function has the following overload:

/* -- snip -- */
type CssArg$1 = ((themeArgs: ThemeArgs) => CSSObjectNoCallback) | CSSObjectNoCallback;
type CssFn$1 = (themeArgs: ThemeArgs) => string | number;

interface Css {
  /**
   * @returns {string} The generated css class name to be referenced.
   */
  (arg: TemplateStringsArray, ...templateArgs: (Primitve$1 | CssFn$1)[]): string;
  /**
   * @returns {string} The generated css class name to be referenced.
   */
  (...arg: CssArg$1[]): string; // <-- focus on this one
}
/* -- snip -- */

I cannot imagine a use-case utilizing the n-ary case for css

css(
  { color: 'red' },
  { border: '1px solid black' },
  { background: 'blue' },
  ({ theme }) => ({ padding: theme.spacing(4) })
)

There is no value gain over the unary case 🤔
If anything, I would argue that this support is harmful, promoting creation of silly patterns like this:

import { redText, border, blueBg, padding } from './my-first-design-system'

css(redText,border,blueBg,padding) // -> 'aaaa0001'

promoting a classname explosion instead of composition.
I would expect that the n-ary case would function like this:

const redText = css({ color: 'red' }) // -> 'aaaa0001'
/// and the rest...

const foo = css(redText,border,blueBg,padding, { .. }) // -> 'aaaa0001 aaaa0002 aaaa0003 aaaa0004 aaaa0005'

similar to clsx basically but that would accept everything.

What is the rational behind the n-ary css function?

Your environment

N/A

Search keywords: css method types overload arguments

[datner]

bump?