@emotion/css works with styled-tools

The problem

There are some common css functions that are often needed to define and shared with more than one style components, hence @emotion/css is often used to tackle this problem. However, it’s impossible to use it with styled-tools. Although it’s alright to use styled-tools with normal styled components.

Proposed solution

Implement the feature to enable user to use styled-tools with their @emotion/css functions.

import { palette } from "styled-tools";
const common = (p: HeaderProps) => css`
  color: ${(p) => palette(p.color || "dark")};
  ${center}
  u {
    text-decoration: inherit;
  }
`;

[Andarist]

Please always try to share a repro case in a runnable form - either by providing a git repository to clone or a codesandbox. OSS maintainers usually can’t afford the time to set up the repro, even if exact steps are given.

Tbh , quite frustrated to have to repeat myself over again. If this is not clear enough, then I dno what will.

Please refrain from using such language and expressing such an attitude in your comments. Sam is trying to help you out for free - he could be doing something entirely else and such behavior doesn’t help your question to be answered. In fact, it can only create the opposite effect.

[Andarist]

@mimiqkz I’ve found your language to be really passive-aggressive and not polite. We can express our feelings without such language.

---

Yes, currently css doesn’t support “props” at all on purpose. It’s meant to represent a “partial” style that is already fully computed, cacheable etc. I had a short conversation about this with Mitchell over 2 years ago. To support this we’d have to conditionally return non-serialized data, that would be responsible for storing arguments passed to css. This probably would have to support source maps. Using this data we could later “resolve” it when the “props” would be supplied. Mitchell has also mentioned “I was thinking more that we hoist things and then use weak memorization” in response to some of my Babel-related ponderings about the implications of such a change/feature. But quite frankly - I’m not completely sure what we’d hoist and memoize there. Maybe the assumption was that the “props” would be just theme as that could indeed make it more worthwhile (theme is usually static so the memorization makes sense, whereas component props change all the time so it makes much less sense).

If we’d support “any” props - this could become quite quirky to type and I’m not sure what the real gain is. Wrapping css (when needed) in a function isn’t IMHO bad and makes the control flow predictable.

I could take a look at PoC of supporting this… but overall I’m not sold on the idea just yet so there is no guarantee that such PoC would actually get merged. We’d need to balance the gains from such a feature with the added runtime complexity etc.