typicode / mistcss

Create visual components for React without JavaScript or TypeScript. Leverage native HTML and CSS. It's an alternative to CSS-in-JS and CSS modules.
MIT License
1.07k stars 27 forks source link

Why are custom properties not optional? #69

Open juice49 opened 1 day ago

juice49 commented 1 day ago

I was really impressed to learn Mist generates types for CSS custom properties. However, I'm wondering why the resulting style object types are not optional. Especially because—as far as I can tell—Mist can only discover custom properties that have been declared with a default value in a style. Style consumers may not wish to override this default.

CSS input

div[data-component="test"] {
  --color: rebeccapurple;
  outline: 10rem solid var(--color);
}

TypeScript output (--color is not optional)

interface Mist_div_data_component_test extends React.DetailedHTMLProps<React.HTMLAttributes<HTMLDivElement>, HTMLDivElement> {
  'data-component': 'test'
  style?: { '--color': string } & React.CSSProperties
}

Questions

  1. Would the maintainers be receptive to a PR making custom properties optional?
  2. Has there been any consideration around supporting the @property at-rule for discovering custom properties, and perhaps inferring information about them?

Love the work that's been done here ❤️.

typicode commented 13 hours ago

Hey,

Thanks! :)

  1. It's a mistake, feel free to create a PR
  2. Yes in previous versions, I don't remember why exactly why it wasn't supported in the end. Do you have some use cases/examples that would benefit from it?
juice49 commented 11 hours ago

Thank you. PR opened! (:

On @property support:

  1. It embraces the spirit of being a standards focused approach.
  2. It eliminates the need to redeclare a custom property that has already been declared using @property.
  3. The syntax descriptor could perhaps be used to enhance the created type (imagine a value that can be 'a' | 'b' being typed that way).

Having said that, it doesn't appear to be permissible to nest @property at-rules. I think this puts a bit of a spanner in the works for discovery, because Mist would not be able to associate the at-rule with an element.

Not permissible

div[data-component="test"] {
  @property --color {
    syntax: "<color>";
    inherits: false;
    initial-value: rebeccapurple;
  }

  outline: 10rem solid var(--color);
}

Permissible, but can no longer be associated with an element

@property --color {
  syntax: "<color>";
  inherits: false;
  initial-value: rebeccapurple;
}

div[data-component="test"] {
  outline: 10rem solid var(--color);
}

Some half baked thoughts:

  1. What if Mist discovered custom properties by observing where they are used (var(--some-property) versus --some-property: 1)?
  2. What if after discovering the usage of a custom property, Mist looked for a matching @property at-rule in order to create a more precise type based on its syntax declaration?
  3. Observation: typing custom properties like this is generally quite a challenging task, because the value could be set on some element outside of where it's declared or used in CSS.

Maybe I'm overthinking it 😅.