RFC | Design Variants for individual components

[JayaKrishnaNamburu]

Variants

Proposal's aim's to bring component-scoped variants for individual component. Let's take a generic and common use case of a button. We will have a primary, secondary, highlighted, active, inactive etc states for a button. And these states are called as Variants. So, when we call a button from a parent component/page. We can call using

<Button variant="active">Active Button</Button>

<Button variant="inactive">In-Active Button</Button>

<Button variant="primary">Primary Button</Button>

<Button variant={this.state.buttonState}>Button</Button>

These variants are component specific and can't be re-used while defining any other component. Or anywhere else other than the component itself.

Examples for Inspiration

Let's look at Styled System's Variants and Stitches Variants.

Here are some of the points that needs a discussion and brain-storming w.r.t to variants.

Ideology

• Component can have only one variant prop when used in a parent comp/page.
• Component can have any number of variants, and every variant can define component's state like hover,
  focus, disabled, media-states. Can use prop's, tokens for defining.
• Component can have a default variant like a default-prop and it is over-written when the parent passes a variant prop.

UIDL

So, in UIDL, we need to introduce a styleSetDefinitions for all ComponentUIDL. Right now, it is available only for RootComponentUIDL, which is basically a router. We use the styleSetDefinitions on the root as project-style-sheet.

Referring the variant of the root of Component

I strongly suggest that we should not mix-up the variant as a generic attr. Currently, we can simply have className dynamic attr on any node. And it just refers to the variant prop. But, here is the draw-back of the approach
https://repl.teleporthq.io/?uidlLink=u4pti7db6be446yb8rqnz1

If the component has some default styles. Then it adds the className two times. Since, generators don't know the difference between a className attr and className added by the style-plugin. So, we need to have a separate variant reference on the nodes that refer to the variant. So, generators can mix up the default styles and variant class-name at the same time.

[JayaKrishnaNamburu]

After some discussion around this topic, we are leaned more towards this approach. Every component can have a propDefinition that targets to root. So, the propDefinitions which is currently

export interface UIDLPropDefinition {
  type: string
  defaultValue?: string | number | boolean | unknown[] | object | (() => void)
  isRequired?: boolean
}

Will have a new attribute like

export interface UIDLPropDefinition {
  type: string
  defaultValue?: string | number | boolean | unknown[] | object | (() => void)
  isRequired?: boolean
  target?: {
      type: 'style' | 'attribute',
      content: 'root'
  }
}

if props.target is style and content is set to root by default the props is referring to the root of the component. This is going to be uni-direction reference. Like propDefinitions points to style and key and it's the key's that should handle this.
Like in a typical example it can look like

• Calling the component

const rootElement = document.getElementById("root");
render(<App variant="inherit1" />, rootElement);

And inside the component

export default function App({ variant = "default" }) {
  return (
    <div className={variant}>
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

And each instance of a component will have a single instance of variant. Which is defined under a new variable styleSetDefinitions under ComponentUIDL. This are similar to styleSetDefinitions in global but scoped to the component and doesn't support dynamic values.

How the default style is set ?

Should the default is created by extracting from the root's inline-style.In UIDL terms, the styles that are defined on the input.node.content.styles (input references to ComponentUIDL). And if the global styles are defined, the root node should basically have both style from global style sheet and the default style.
Here is an example

export default function App({ variant = "default" }) {
  return (
    <div className={`primary  ${variant}`}>
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

And the variant always overrides the primary from global here. Since specificity which is the ideal behaviour too.

Reasons for the approach

We support Angular, Vue and React with multiple style targets as output. And supporting every flavour is always the first priority without external lib support like runtime css libraries. So, this way the styles are static and adds support css based environments and the runtime libraries at the same time.

[JayaKrishnaNamburu]

CSB used for the example https://codesandbox.io/s/beautiful-hooks-cc0zc?file=/src/App.tsx