Is it better don't put dynamic styles in emotion ?

[happy-little-one]

Like the left and top propertity generated by drag. if put them in emotion, emotion will keep generate new classes, will this cause performance problems?

[srmagura]

It will cause performance issues. This is discussed in our docs here. :)

[happy-little-one]

What about the switch case and if else secnario ? should it only contain static styles?

[Andarist]

If your dynamic classes have just a couple of variants then it's fine - don't do this with super dynamic things though (like drag positions)

[happy-little-one]

Make sence, thanks!

[penx]

@srmagura @Andarist my understanding is that performance issues often come from Function Interpolation, i.e.

FunctionInterpolation:

styled.div(({disabled}) => ({
  opacity: disabled ? 0.5 : undefined,
}))

over

CSSObject:

styled.div({
  "&[aria-disabled=true]": {
    opacity: 0.5,
  },
})

The above is a simple example and I'm not saying would on its own be the cause of a performance issue, but I think avoiding function interpolations is a good general principle. I think this also helps with server side static extraction.

I was wondering about continuing to use emotion but opting out of Function Interpolations. I wonder if it would be worth having a package that doesn't export this functionality, or any other known bottlenecks?

Alternatively perhaps this could be enforced via TypeScript by overriding the FunctionInterpolation to be never, or excluding it from Interpolation?

[penx]

I think this can be done with

import * as Serialize from "@emotion/serialize";

declare module "@emotion/serialize" {
  export interface FunctionInterpolation<Props> {
    (props: never): Serialize.Interpolation<Props> & never;
  }
}

I would prefer to mark it as deprecated than never, but not figured that out yet.

Would be good to hear others thoughts on this approach!

[Andarist]

Yeah, function interpolations definitely have some cost - at the same time, they are one of the primary appeals of runtime CSS-in-JS. It's a clever way to "forbid" this with never like this - nice work. I don't think though that this is something that should be added to Emotion itself.

[penx]

function interpolations were certainly one of the things I used to love about CSS-in-JS, as it can make some simple things easy, but as time has gone on I've found alternative approaches that I prefer and I think I can avoid them for all use cases now.

I've added the above to our codebase with a note about alternative approaches.

One of the reasons I am wondering if there's value in having a "lite" version of emotion that doesn't include features like this, is perhaps that would aid static extraction solutions or at least prevent the need for a double render in some SSR setups?

Here's roughly what we have, if it's of any use to other users. I don't think the @deprecated has much effect but seemed like the correct thing to add locally.

declare module "@emotion/serialize" {

declare module "@emotion/serialize" {
   /**
    * @deprecated Avoid function interpolations to improve performance and server side static extraction (?)
    *
    * Common use cases and alternatives:
    *
    * ### Accessing the theme in react-native
    *
    * Either
    *
    * - Define your react-native component in a package that does not import this override
    * - Use useTheme
    *
    * ### Inserting dynamic dimensions
    *
    * Use an inline style prop, so that a new class is not generated for every option.
    *
    * ```ts
    * const MyComponent = styled.div<Props>`
    *   width: ${({ viewportWidth }) => viewportWidth - SOME_VAR}px;
    *   height: ${({ viewportHeight }) => viewportHeight - SOME_VAR}px;
    * `;
    * ```
    *
    * Becomes:
    *
    * ```ts
    * <div
    *   style={{
    *     height: `${viewportWidth - SOME_VAR}px`,
    *     width: `${viewportHeight - SOME_VAR}px`,
    *   }}
    * >
    * ```
    *
    * ### Responding to prop changes
    *
    * Set an inline aria or data attribute, and respond to those:
    *
    * ```ts
    * styled.div(({ disabled }) => ({
    *   opacity: disabled ? 0.5 : undefined,
    * }));
    * ```
    *
    * Becomes:
    *
    * ```ts
    * styled.div({
    *   "&[aria-disabled=true]": {
    *     opacity: 0.5,
    *   },
    * });
    * ```
    *
    * ### Accessing theme variables
    *
    * Store theme variables in CSS variables, accessing them through a typed helper function
    *
    * ```ts
    * columnGap: theme.space[4],
    * ```
    *
    * Becomes
    *
    * ```ts
    * columnGap: cssvar("space-4"),
    * ```
    */
   export interface FunctionInterpolation<Props> {
     (props: never): Serialize.Interpolation<Props> & never;
   }
 }

Common use cases and alternatives:

Accessing the theme in react-native

Either

• Define your react-native component in a library that does not import this override
• Use useTheme

Inserting dynamic dimensions

Use an inline style prop, so that a new class is not generated for every option.

const MyComponent = styled.div<Props>`
  width: ${({ viewportWidth }) => viewportWidth - SOME_VAR}px;
  height: ${({ viewportHeight }) => viewportHeight - SOME_VAR}px;
`;

Becomes:

<div
  style={{
    height: `${viewportWidth - SOME_VAR}px`,
    width: `${viewportHeight - SOME_VAR}px`,
  }}
>

Responding to prop changes

Set an inline aria or data attribute, and respond to those:

styled.div(({ disabled }) => ({
  opacity: disabled ? 0.5 : undefined,
}));

Becomes:

styled.div({
  "&[aria-disabled=true]": {
    opacity: 0.5,
  },
});

Accessing theme variables

Store theme variables in CSS variables, accessing them through a typed helper function

columnGap: theme.space[4],

Becomes

columnGap: cssvar("space-4"),

[Andarist]

is perhaps that would aid static extraction solutions

It could aid them but at the same time - nobody on the team has the time capacity to actually work on this right now.

or at least prevent the need for a double render in some SSR setups?

I think that the future of React's SSR is about streaming rendering - you don't get double render issues with this anyway (as you just can't double render things).

[hinell]

I'm a bit late to the party but I think the best way to dynamically manipulate directly via DOM.