Evaluate stiches.js to replace emotion and theme-ui

[sebald]

Library to evaluate: https://stitches.dev/

Reasons:

• way better DX
• solves a lot of issues we have with theme-ui (we don't use much of its features, no "in place" vars that would be nice for something like border)
• reduces our bundle size since we don't use css strings that emotion supports

Cons:

• requires some setup regarding SSR
• we would need to replace pseudo selectors when creating the theme, which actually may be good for performance?
• stiches assumes that there is a default theme, which we don't really have (except some in __baseCSS), we might still make use of useComponentStylse

API:

We might use it like this:

import { styled } from '@stitches/react';
import { useComponentStyles } from '@marigold/system';

const StyledButton = styled('button', {...});

export const Component = ({ variant, size, children, ...props }) => {
  const styles = useComponentStyles(
    'Button',
    { variant, size },
  );

  return <StyledButton {...props} css={styles}>{children}</StyledButton>
}

Reuse our API?

import { Box, useComponentStyles } from '@marigold/system';

export const Component = ({ variant, size, children, ...props }) => {
  const styles = useComponentStyles(
    'Button',
    { variant, size },
  );

  return <Box as="button" {...props} __baseCSS={{ appearance: 'none' }} css={styles}>{children}</Box>
}

// system/Box.tsx
import { styled } from '@stitches/react';

export const Box = ({ __baseCSS, css, children, ...props }) => {
  const Component = styled(as, merge(__baseCSS, css));
  return <Component {...props} />;
}

Is this good? We maybe need to make a "factory"?

import { mg, useComponentStyles } from '@marigold/system';

export const Component = ({ variant, size, children, ...props }) => {
  const styles = useComponentStyles(
    'Button',
    { variant, size },
  );

  return <mg.button {...props} css={styles}>{children}</mg.button>
}

// system/factory.tsx
import { styled } from '@stitches/react';

export const md = {
  button: styled('button', {
		// basically what previously was __baseCSS
	    display: 'inline-flex',
	    alignItems: 'center',
	    justifyContent: 'center',
	    gap: '0.5ch',
	    cursor: disabled ? 'not-allowed' : 'pointer',
	    width: fullWidth ? '100%' : undefined,
	    '&:focus': {
	      outline: 0,
	    },
	  }),
  div: styled('div')
}

[sarahgm]

Some Questions from me for understanding the issue Description

• Why do we need to replace the pseudo selectors? Do you mean the way they are implemented? Because pseudo elements and pseudo selectors are supported? here in docs
• The Default Theme would be the Global css settings?
• Also does that mean we need a <StyledButton/> and a 'normal' <Button/> ?

Generel
We use emotions ThemeProvider, does that mean we don't need one if we use Stitches JS? Because it's with the createStitches covered? Also the basic/default theme is there written?

From what I understand the obvious advantages are:

1. just one tool instead of two(emotion&theme-ui) where we even don't use the full possibilities
2. better performance

In my opinion (as far as I get it), I think we could implement this after we made next.js work 🙂 I haven't seen much conflicts.
PS: I also think in this case we should make the tokens (e.g. color00 and color.00) consistent.

[sebald]

@sarahgm

Why do we need to replace the pseudo selectors? Do you mean the way they are implemented? Because pseudo elements and pseudo selectors are supported? here in docs

I meant how our pseudos work (e.g. :hover -> :hover, [data-hover] We would need to keep/adjust that. Not that big of deal.

The Default Theme would be the Global css settings?

Not sure what you mean.

Also does that mean we need a <StyledButton/> and a 'normal' <Button/> ?

IDK depends how we implement it, I guess.

---

And to the other comment. Yeah, if we switch, we should take the opportunity and make stuff more consistent.

[sebald]

Related: stitchesjs/stitches#1109

[sebald]

Switch to a non-CSS-in-JS Solution?

Since there might not be good support in the CSS-in-JS libs we might to consider other alternatives

Other components libs are currently moving away from CSS-in-JS library. One of the prominent ones is NextUI. Even the maintainer of Emotion says that

Server Components were designed in a way that is at fundamental odds with CSS-in-JS. So don't expect Emotion (or other popular CSS-in-JS libs) to introduce support for them. They just don't allow us to integrate with them anyhow.
see this comment here: mui/material-ui#34905

While you can make them compatible, it might no optimal or worthwhile in the future. On the other hand we currently don't really have any Next apps in productions, except the Marigold docs. This might change in the future though.

Issue from NextUI regarding their reasons to switch: heroui-inc/heroui#1035

---

Suggestion

Investigate Tailwind? The spiritual successor of Bootstrap has a enormous community already and might be an option that also solves a lot of our challenges.

In order to have the same feature and high compatibility with our current styling approach (variants and size), there are two options:

• https://github.com/joe-bell/cva + https://github.com/dcastil/tailwind-merge
• https://www.tailwind-variants.org/ (in beta, but this will be used by NextUI)

[sarahgm]

Reference how other Design Systems use Stitches: https://github.com/radix-ui/design-system/tree/master/components

[sarahgm]

Questions tailwind:

• how to handle simple tokens like breakpoints in tests, because the type supports just name and components. the tokens are defined in tailwind.config.cjs how to use and test them -> have to add in config but how? (example: colors: purple10 -> I can't just import the colors.ts in tailwind config build failes -> cannot find module)
• how to fix test in useTheme with className type definition
• how to get the theme in the marigold provider // how to get it in storybook -> why works in tests but not in app
• what about extending a theme? How should this be handled?
• test in Marigold.Provider
• Storybook -> own theme???

Note:

• right now in useComponentStyles there are two versions of it because if remove it breaks all -
• in preview.ts same (set default to unicorn)

Next Steps:

• more styles in tailwind ?
• evaluate together ?
• ???

[sebald]

what about extending a theme? How should this be handled?

can we use tailwind presets for this?

[sarahgm]

@sebald I mean the function extendTheme as I understand Presets are something else

• maybe it works as before. the tests are correctly

[sebald]

@sarahgm ah, I think we can not use that any longer. Extending a theme has to be done via tailwind/postcss I guess

[sarahgm]

@sebald really? but the tests worked correctly I see no problem 🤔

[sebald]

Okay, then I am clearly wrong and I have to see the implementation 😄