Logic within dynamic styles

[edamascus]

I have the following code which controls visibility of an element based on a visible state:

const styles = stylex.create({
  base: (visible: boolean) => ({
    display: {
      default: visible ? 'flex' : 'none',
      [md]: 'flex',
    },
  }),
});

// ... within the compoenent
const [visible, setVisible] = useState<boolean>(false);

<div {...stylex.props(styles.base(visible))}>
// ...
</div>

Is there something wrong in using the operator visible ? 'flex' : 'none', within the dynamic style function? Because I see the following ESLint error: @stylex/valid-styles: display value must be one of... for this part, although the styles are applied as intended.

[nmn]

While some logic is allowed within dynamic styles and it's an issue of our ESLint rule not being smart enough, you should never use dynamic styles for such cases. Do this instead:

const styles = stylex.create({
  base: {
    display: {
      default: 'none',
      [md]: 'flex',
    },
  },
  visible: {
    display: 'flex',
  }
});

// ... within the compoenent
const [visible, setVisible] = useState<boolean>(false);

<div {...stylex.props(styles.base, visible && styles.visible)}>
// ...
</div>

[nmn]

Here if visible is false you'll get two classes and just one if true. The original code would always have two classes and an inline style.

[edamascus]

That was so simple! 🤦🏻‍♂️

Is using a dynamic style, as follows, to pass the width and height of an element as props also a bad use case?

type Dimension = number | 'auto';

const styles = stylex.create({
  dimensions: (width: Dimension, height: Dimension) => ({
    width,
    height,
  }),
});

//...

const Component = ({
  width = 'auto',
  height = 'auto',
}: Props) => {
  return (
    <div
      {...stylex.props(styles.dimensions(width, height))}
    />
  );
};

[nmn]

@edamascus If you know what the style is, or what the style could be, you should not be using dynamic styles. Dynamic styles are for very rare cases where you would normally not be able to write CSS at all and would need inline styles generated at runtime.

An examples:

• You're using CSS to create a bar chart using data from an API. The height is unknown till after you fetch the data and so it needs to be dynamic.

What you're doing in your example above is just accepting styles as a prop. Even if this component doesn't know the height and width, the component rendering this component does. So just use style composition.

const styles = stylex.create({
  base: {
    color: 'red',
    // ...
  }
});

type Props = {
  style?: stylex.StyleXStyles<{width?: number, height: number}>
}

const Component = ({
  style
}: Props) => {
  return (
    <div
      {...stylex.props(styles.base, style)}
    />
  );
};

[edamascus]

Thank you for the clarification. The principles of passing styles as props and style composition are clear and intuitive. However, suppose that we have an Image component that expects to receive the width and height of the image via props. Now, every time we need to use this component, instead of doing this:

import Image from 'some-library'

<Image width="720" height="400" />

We should do this:

import Image from 'some-library'
import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  image: {
    width: 720,
    height: 400
  }
});

<Image style={styles.image} />

I guess the value in this case would be performance at runtime. Even if we have so may images with different sizes and that will be compiled to many width and height declarations; and even if this means writing a bit more code to achieve the same result.

---

It is a mere suggestion, in order to write less code, something in line with the below can be thought about:

<Image style={stylex.declare({width: 720, height: 400})} />

This would be exactly the same as passing styles.image but the name of the style (CSS block) will be auto-generated. The .declare API would only accept CSS declarations.

[nmn]

Your example here wouldn't work very well, since when setting width and height attributes, styles that set them to the same values are redundant. However, if you do have a use-case where you need a value in JS in addition to styles, it's OK to use dynamic styles. They are not slow, they just incur the cost of an inline style that sets a CSS variable. Nothing to be concerned about in one-off cases. I just wanted to dissuade you from using dynamic styles as the default. They should be used sparingly as the documentation states.

---

Your suggestion for passing styles inline has been proposed before and something we're keeping an eye on. We want to avoid adding new API if possible and are exploring a few approaches within the existing APIs before we try something like this.