Theming

[chrisvxd]

Puck is being deployed in a wide variety of situations that require different themes. We should support theming to support this.

Some ideas:

• classNames for everything that can be customised
• style tags for everything that can be customised
• a discrete API exposing a limited subset of style overrides
• custom render functions to enable users to take ownership of specific parts of the application
• remove CSS modules and expose all existing CSS classes

Let's have a discussion and form this into a more fully fledged series of proposals.

Related #122

[leweyse]

Hi @chrisvxd !

I definitely support using custom properties. A great example of a similar implementation is shadcn (reference: CSS variables).

I use Tailwind CSS and would love it if the theme customization could be easily extended to Custom Fields or Plugins in my projects.

[JakeSidSmith]

I think if you want to appease everyone you're probably going to need both inline style and className support.

And just to throw an extra complication into the works, there'll be people using styled-components that would like to be able to wrap your existing components instead of applying global styles. This might be able to be achieved in a similar way to how react-markdown allows customizing elements....

If you had an interface that allowed overriding/extending the styles in one place (in addition to style and className on each component) it'd be incredibly powerful. E.g.

noIdeaWhatToCallThis: {
  Button: (ExistingComponent) => ({className, props}) => (
    <ExistingComponent {...props} className={classNames(className, 'extra')} />
  ),
  // Styled component example
  Button: (ExistingComponent) => styled(ExistingComponent)`color: red;`
}

[chrisvxd]

@leweyse also a big fan of custom properties, so there could be something here. This might be a good way of doing a relatively light and controlled custom theming layer.

@JakeSidSmith I think what you're suggesting is the "custom render functions" option combined with "classNames", which is full UI override.

This is definitely the most powerful option and would allow people to do whatever they want, but I have concerns around the trade-off in making the internals part of a public API. If you remove a component internally, you now have to issue a breaking change. I imagine the risk of this happening decreases as Puck becomes more stable.

[BleedingDev]

I agree with the simple solution with custom properties. They are well-known and supported and they can cover a lot of use-cases. Custom render functions would be for complete white-labelling, which is way to advanced (and heavily paid in solutions like Builder.io).

[chrisvxd]

Initial pass being worked on by @leweyse (see #175)

[chrisvxd]

I think #224 may unlock this work, and should probably be a blocker here.