Unstyled UI components

[danielbayerlein]

I think it makes sense to ship the UI components without a CSS-in-JS library. This way, the developer is not forced to provide a second library to the user. What do you think about it?

[zbeyens]

So the idea is the make the ui packages headless (without styles), and move the current styles, twin.macro and styled-components deps to @udecode/plate-styled-components.

https://www.radix-ui.com/ is a good example, which we'll try to use for the remaining plate components.

The thing I don't know how to decouple yet is, in all components we're using:

• a css prop to style with twin.macro
• a styles props in all components so the user can override the styles

Anyway the current priority is to have a nearly complete design system before optimizing

[danielbayerlein]

I think the approach is great!

[zbeyens]

It’s a common concern that styled-components is coupled to the ui packages. Radix is really nice and will be the main reference together with headlessui.

Styled

• we currently use styled-components and twin.macro
• Styled components would have the same props than the unstyled ones without merging props, so overriding a styled component className would replace instead of the current merging strategy. So we can either start designing from an unstyled or styled component.
• Styled components accept css-in-js props (using styles prop), so people can override the styled components.
• Any thoughts on https://stitches.dev/ ? I read it has really nice DX using variants. See also https://github.com/ben-rogerson/twin.examples/tree/master/next-stitches-typescript

Unstyled

No need to override styles, no specificity wars.

Phase 1

• create unstyled components
• The challenge here is that our twin.macro helper is outputting css and className prop for each tag. css is coupled to styled-components, so we can’t use twin.macro in unstyled components. So props redesign is needed for unstyled components. Unstyled components could have, for each (nested) tag, overridable props (className, css) and overridable tag (as). I need to confirm passing css prop is working, but it seems like in that example. Any idea on a clean props interface?
• We generally want to use the same “essential styles” (like positioning) from the styled components, so we’ll need to show the code on the docs to reuse these styles. We’ll however keep tailwind as the fastest DX is crucial for maintenance, so people not using tailwind will need to map tw class names to their styling solution.

Composable

Granular access to each component part.

Phase 2. Still reluctant about it.

• we'd keep the "full components" as a whole so it's not a need to compose
• extract composable components from these full components
• alternative is to provide props to customize composability, but we lose tree-shaking

Customizable ✅

Consistent

One of our main goals is to provide the best possible developer experience. All components share a similar API, creating a consistent and predictable experience.

Components with similar functionality share similar API.

Packaging

1. The unstyled components will live in the same package than the styled ones, so styled-components will be kept as a peer dep but you could not install it and filter/ignore the warning message if not using the styled components.
2. The alternative is to move all the styled-components to @udecode/plate-styled-components as a design system, but we lose SoC.
3. The last option would be to duplicate all ui packages @udecode/plate-ui-codeblock (unstyled) @udecode/plate-styled-codeblock (styled) but having 2x more packages slows down maintenance, so I’d go for 1).

[horacioh]

looking forward to this discussion, since many apps will find this useful! this could be interestiing for apps that supports theming components too!

My current setup

we at Mintter (shameless plug XD) do not use Plate, but I was very influenced by it when building our plugin system. for styling we use both Radix UI and Stitches. Radix UI help us to make accessible components, and Stitches help us with styling and theming (light, dark, custom...)

as you mentioned, the main problem is when you want to customize styles on complex components. one way is to create consistent naming in order to target elements from outside with styles. this is something Radix does for styling component states for example. The use of data-attributes in CSS is something that feels weird in the beginning, but makes so much sense in the long run. it also helps for testing purposes too.

Using Radix as a reference might help, since Radix is a Unstyled solution for very complex UI components. also another example could be Ariakit.

Packaging

Creating a separate package for UI feels wrong to me too, more overhead for maintainers. but it's a tradeoff: do we want Library users to just install and use the library? or we want defer the styling work to them and make them do a little bit more work. Radix does the latter and IMHO it makes sense.

Hope my PoV helps!

[zbeyens]

Thanks for your feedback @horacioh ! After reading it and part of the docs, I'm convinced to

• reuse Radix UI components as base components to our future unstyled components (thinking to Context Menu, Dropdown Menu, Popover, Select, Toolbar, etc.), they have a package for each component which is perfect
• use data-attributes for states
• use their utilities like Slot to support asChild
• replace SC by Stitches, our current variants introduce a lot of overhead so that will improve DX by a lot

[zbeyens]

Done in v22 #2472