Can't access theme from styled component and question about sx props vs style props

[coreybruyere]

I have a React TS-based design system built with emotion, styled-system, and theme-ui and am encountering a TS error I can't seem to resolve. It seems like a simple fix, I just haven't been able to debug it.

I found a work around by just using bg, so utilizing styled function props, and I plan on utilizing the sx prop for all other styling needs.

The error is:
Property 'colors' does not exist on type 'Theme'.

I'm trying to access theme in a styled component with:

background-color: ${({ theme }) => theme.colors.border};

My question is: Why isn't it possible to style utilizing the theme prop inside of a styled component?

[hasparus]

Could you share your whole component?
Is colors present on theme at runtime and the error is purely in types world, or is colors also missing at runtime? Do you import "styled" from styled-components or @emotion/styled?

[hasparus]

I noticed when consuming a component with sx props and applying additional styles on top of said component via sx prop that all previous styles from the original component are wiped out.

If you're using a JSX pragma, merging sx props should work out of the box — sx is compiled to className so then you have sx, and className from props.

If you're not transpiling your JSX, you'll have to merge sx objects.

sx={{
  color: 'blue',
   ...props.sx,
}}

This is similar to merging classNames when using pragma / classic CSS.

className={join("Button", active && "Button--active", props.className)}

So, here's a question — how opinionated is your components library? Is it a reusable pack of components to be styled in whatever way the user is accustomed to? Then, accepting styles from props through either sx, className or style props seems like a nice permissive API.

However, if you're building a closed design language, you'd probably accept neither of these props, maybe leaving some escape hatch like seek-oss/braid-design-system does with Box.

I'm using Chakra in one commercial project, and I've grown... skeptical of style props, but that's just my personal opinion. I'm familiar with a few quite ambitious designers and I'd rather have an access to a superset of CSS (like sx) than a subset or an equivalent set of JSX props. There's always a (far albeit realistic) possibility of static optimization of some of your sx props and transforming them to classNames at build time.

[coreybruyere]

@hasparus - I tried merging sx objects after adding a jsx pragma and am not getting the result I'd expect. Here's a Pull request with changes.

Does anything look wrong here?

I'd expect any additional styled props or sx props I apply on top of an existing component (styled with styled props or sx prop) to override the styles that were previously defined. In this case I expect a p value of 5 with a fontSize of 40:

<Tag p={5} sx={{fontSize: 40}}>This is a Tag</Tag>

For context: I'm essentially trying to create a small library that supports both styled-system styled props AND theme-ui sx prop.

[hasparus]

In your PR py and px overwrite p, right?

For context: I'm essentially trying to create a small library that supports both styled-system styled props AND theme-ui sx prop.

I'm afraid you'll have to manage the "priority" manually. I'd expect that in your example all styles you wrote are emitted but the class is not in ordered as you'd like. Is it true?

[coreybruyere]

Yes this is true, py and px are overriding p. How would I go about managing that? To ensure amended props override preexisting props?

[hasparus]

I, personally, stray from style props because they give you a second way to do the same thing for a slightly more concise syntax.

If you want to say "whenever p is passed from top-level, I want it to override my px and py" you could write it like this:

const paddingFromProps = props.p || props.padding;
const padding = paddingFromProps ? { p: paddingFromProps } : { px: 1, py: 2 }

<div 
  sx={{
    ...padding,
    ...sx,
  }}
/>