fix(TS): allow CSSObject on @emotion/styled

[kentcdodds]

What: This allows: styled.div(/* this can be an object /*)

Why: Because that API is supported so the typings should allow for it.

How: Tried it locally and it typed fine (even helped me fix an issue I had), so I just made this change in the github editor.

Checklist:

• Documentation N/A
• Tests
• Code complete

[kentcdodds]

Hmmm... Just noticed this test:

emotion/packages/styled-base/types/tests.tsx

Lines 39 to 41 in 6f3ee3f

	const Button1 = styled('button')({
	color: 'blue'
	})

I'm not sure how that's working because using the object syntax isn't working for me. I'm using styled.button rather than styled('button'), so maybe that's why...

[kentcdodds]

The failure is:

Property 'button' does not exist on type 'CreateStyled'.

I'm not sure how to fix that 😬

[emmatown]

styled.button and stuff should be in the @emotion/styled package

[kentcdodds]

Ok, so I fixed the test, but then I added a few more tests for things that I think should be errors but they're not and I'm not sure why...

[Ailrun]

@kentcdodds We cannot emit an error on "wrong properties", since we should handle something like & > &, & > li, ..., and TS does not support RegExp property type (which they said they will support).

[Ailrun]

This case is covered by the previous overloading, so you don't need to add one.
Interpolation<WithTheme<StyleProps, Theme>> is a (structural) supertype of CSSObject.

[kentcdodds]

Hmmm... I wonder why I was seeing issues then. I'll dig a little more. Thank you!

[kentcdodds]

Ah, I think this is the issue I was having that lead me to open this PR. Would you like me to make a new issue?

---

This is a weird issue and I don't know what's going on. Help appreciated!

Here's the code:

import styled from '@emotion/styled'

const WorkingDivider = styled.hr({borderTopStyle: 'solid'})

const baseStyles = {borderTopStyle: 'solid'}
const NotWorkingDivider = styled.hr(baseStyles)

const otherBaseStyles = {margin: 20}
const AnotherWorkingDivider = styled.hr(otherBaseStyles)

export {WorkingDivider, NotWorkingDivider, AnotherWorkingDivider}

Here's the error I'm getting:

$ yarn typecheck
yarn run v1.12.3
$ tsc
index.ts:6:37 - error TS2345: Argument of type '{ borderTopStyle: string; }' is not assignable to parameter of type 'TemplateStringsArray'.
  Type '{ borderTopStyle: string; }' is missing the following properties from type 'TemplateStringsArray': raw, length, concat, join, and 10 more.

6 const NotWorkingDivider = styled.hr(baseStyles)
                                      ~~~~~~~~~~


Found 1 error.

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

So from my observations, when I specify borderTopStyle in an object and pass it to styled, it'll fail typechecking with the above error. But if I inline the object it works. I have not observed this behavior with any other css property.

[Ailrun]

I think the issue you met is #1025. Please check my comments on the issue.
It's about how TS works...

[lychyi]

@kentcdodds @Ailrun is correct, this is due to the inner-workings of TS (and exacerbated by an error messaging issue). Although, to be fair, I think #1025 makes is hard for some TypeScript users to decipher.

Let me try to explain this phenomenon because when I tripped up on this last time it was kind of hard to find a solution online. Hopefully this helps anyone else out:

Explanation

The difference in the working/non-working examples above is that WorkingDivider is an object literal passed as a function argument, thus its type is inferred correctly:

// parameter type is effectively { borderTopStyle: 'solid' }
// important here: value is a string literal type
const WorkingDivider = styled.hr({borderTopStyle: 'solid'})

vs.

// Notice the difference!
// type is { borderTopStyle: string }
// important here: value is a regular string type
const baseStyles = {borderTopStyle: 'solid'}
const NotWorkingDivider = styled.hr(baseStyles)

while in this case, we have an object literal assigned to a variable and then passed as a function argument. const baseStyles infers its type before it is passed into the styled function and the type is different because by default TS does type-widening on object literals. And because borderTopStyle only takes a specific values of strings (a string union type), it won't just accept string as the type. This makes sense, 'frizzy' or 'asdf' is not a valid borderTypeStyle so you want that type to be strict.

Finally, the last part of your example works because margin is designed to take any number or string (say, '20px'), so type-widening doesn't really affect it.

// type here is { margin: number } which is totally fine
const otherBaseStyles = {margin: 20}
const AnotherWorkingDivider = styled.hr(otherBaseStyles)

Solutions

This is my favorite way to fix it. Do the type inference via annotation:

import styled, { CSSObject } from '@emotion/styled';

// You could annotate the type to prevent widening
const baseStyles: CSSObject = { borderTopStyle: 'solid' }

I've seen this next solution get thrown around but it's difficult to maintain. i.e. What if you need to change from 'solid' to 'dotted'?

// Prevent type-widening with an assertion
// ...but if you had multiple properties that needed this, it could get tedious
const baseStyles = { borderTopStyle: 'solid' as 'solid' }

Other reading

• Feature request to disable type-widening on TS Suggestion: a way to disable type widening in object literals microsoft/TypeScript#20195

[Andarist]

@lychyi thanks for the explanation! I've learned something today because of your comment ❤️

[Ailrun]

@lychyi Thank you for such detailed explanation!
As one additional side note, it's not just about type widening, but also about how TS use context (other statements, other expressions, ...) to infer types (of variables, values, ...). Namely, it (almost) ignores context, and this is a critical difference with Flowtype.

[Ailrun]

@lychyi Oh, and in your solution, Interpolation can make a problem when you use props in your styles.
CSSObject is originally meant to be used in that exact case.

[kentcdodds]

This has been super helpful. Thank you friends!

[lychyi]

@Ailrun Good to know! Thanks for the heads up.