Review: Classes DSL

[cmeeren]

Most MUI components have a classes prop that is used to set class names of MUI's internal sub-components (or for specific pseudo-selectors or component states). The allowed rule names vary per component.

Here's the JS native API:

<Button
  classes={{
    root: "foo"
    label: "bar"
  }}
>

Here's an example of the view DSL with the classes prop:

Mui.button [
  button.classes [
    classes.button.root "foo"
    classes.button.label "bar"
  ]
]

The button.classes prop is defined like this:

https://github.com/cmeeren/Feliz.MaterialUI/blob/adb43cba1d6b9aea2153da32a9987d608159ed92/src/Feliz.MaterialUI/Props.fs#L338

The actual classes are defined like this:

https://github.com/cmeeren/Feliz.MaterialUI/blob/adb43cba1d6b9aea2153da32a9987d608159ed92/src/Feliz.MaterialUI/Classes.fs#L116-L123

With a design like this, it's impossible to use incorrect rule names.

Is this design and implementation OK?

---

Ideally, I'd like to flatten it:

Mui.button [
  button.classes.root "foo"
  button.classes.label "bar"
]

But this of course causes problems in the prop generation, since classes is a sub-object.

I had an early hack going where I used prop names like "classes.root", and when creating the prop object from the IReactProperty list I extracted props with . in the name, split them on . and created a sub-object. The API was nice, but I was concerned about performance since this was done for every single prop list in the whole app. (I didn't measure anything, though.) Inputs on this approach are welcome.

[irium]

I'm ok with current solution. It's the same as prop.style usage.

[cmeeren]

Continued in #39.