feat: add support for custom css properties #348
Conversation
| expect(code).toContain(`css={[_default, [["${i.id}", color]]]}`); | ||
| }); | ||
|
|
||
| it.only('should disallow when configured off', async () => { |
There was a problem hiding this comment.
| it.only('should disallow when configured off', async () => { | |
| it('should disallow when configured off', async () => { |
| ).rejects.toThrow(/Could not resolve interpolation to a value/); | ||
| }); | ||
|
|
||
| it('should disallow Styled usage when configured off', async () => { |
There was a problem hiding this comment.
what's disabled in this test case?
There was a problem hiding this comment.
you can't use the ${props => props.color} in styled, only the css prop
| // Match any valid CSS units followed by a separator such as ;, newline etc. | ||
| const rUnit = new RegExp(`^(${cssUnits.join('|')})(;|,|\n| |\\))`); | ||
|
|
||
| // const toValidCSSIdentifier = s => s.replace(/[^_0-9a-z]/gi, '_'); |
|
On the CSS thing, would it be silly to support something like: <div className={css`...`} />instead of having a custom prop? Or something like a That would allow stuff like: <MyComponent className={cssClass`...`} fooClassName={cssClass`...`}> |
|
tbh i went with the wouldn't work, but it's a bit harder to detect usage, to know whether |
|
Yeah, hard to say how sophisticated we need to be. The inability to integrate nicely with tooling is a bummer. I was just looking at cases where passing in more than one class would be useful. No reason not to support a |
|
siigh yeah, so a lot of the api choices that SC and emotion made are regrettable. It's annoying to have to follow. Lets bikeshed more tho in #320 |
supersedes #75
At the moment the
styledsupport is half-baked because we've no shouldForwardProps support, but i don't want to bloat the runtime right now. This is primarily for the css prop case, where we don't need to handle whitelisting