Using imported variables to define styles

[kevintyj]

I was wondering if there was any way to get imported values working in StyleX like so:

// colorTokens.stylex.ts

import { something } from './test'; // const something = '#ffffff'

const testBg = something;

export const DARK_MODE = '@media (prefers-color-scheme: dark)';

export const colorTokens = stylex.defineVars({
	bgColor: {
		default: testBg,
		[DARK_MODE]: testBg,
	},
});

I cannot tell If this is a supported pattern. I am currently getting the error Only static values are allowed inside of a stylex.create() call.

[nmn]

This is not a supported pattern. StyleX is a compiler so all values need to be defined locally. The only exception to this rule is Variables defined with defineVars in a .stylex.js file.

In the case of variables, we don't actually read the file being imported at all. Instead we rely on the import name, and file path (relative to rootDir) to hash and generate variable names.

In your example, it is possible to use one variable to define another variable. So if ./test.stylex was imported, and you exported variables with defineVars in that file, that would.

---

You might want to share values across files. There are two patterns to achieve this:

You can export compiled styles with stylex.create() directly

// foo.js

export const colorStyles = stylex.create({
  white: {color: '#fff'},
});

// bar.js
import {colorStyles} from './foo';

const x = stylex.props(
  // ... other styles ...,
  colorStyles.white,
  // ... other styles ...,
);

// OR
const styles = stylex.create({
  container: {
    ...stylex.include(colorStyles.white),
    // ... other styles ...
  },
})

You can use types to enforce consistency

If you want to share the same media queries in various files, you can use a type to enforce that they're all the same.

// common-types.ts
export type TDarkMediaQuery = '@media (prefers-color-scheme: dark)';

// Some component file
const DARK_MODE: TDarkMediaQuery = '@media (prefers-color-scheme: dark)';

---

Only defineVars are allowed in .stylex.ts files.

In your example, you're exporting a media query as value. This doesn't work in general. But also, the only exports allowed in a .stylex.ts file are variables defined with defineVars.

---

Sharing Media queries for real

There is a CSS proposal for defining custom media queries and PostCSS plugin to polyfill it.

We're in the process of adding some additional capabilities when defining variables. The current plan is to add support for generating @property declarations for variables to give them a type (like <color>) so that they can be animatable, for example.

We could extend this feature to add support for custom media queries where we would generate @custom-media declarations for media query variables and then use the polyfill after generating the CSS file to inline the values back into usage.

The biggest concern here is that @custom-media, unlike other variables, is a constant and cannot be overridden. This limitation doesn't entirely fit within the API design.

[codynova]

@nmn Thanks so much for your thoughtful response!

I would go further and ask if the styles are truly "shared"? I've been trying to formulate my thoughts on this but the question is if the styles for the various components "happen to be the same" or are they enforced by design to be the same?

Basically we have a canonical set of design tokens, and a set of "primitive" UI components like Box, Button, Checkbox, TextInput, etc. We want every primitive UI component to have access to the underlying design tokens via props (what I've been referring to as "style props"). This is a pattern I've seen in some other libraries like styled-system. The style props like background will restrict the values to only the available design system color tokens like primary, secondary, etc. So I would say that they are enforced by design to be the same.

Now, let me make it clear that the getStyles() function you mentioned is supported with StyleX. I just don't think it's a good pattern to use. So if you disagree with my opinions here, you can choose to use it.

I did notice that it works - however Stylex feels like a shift in my mental model for CSS (similar to when CSS-in-JS became popular), so I want to make sure I fully understand the Stylex best practices before I decide I know better 😆 Can you elaborate more on the style optimizations that the getStyled() function prevents?

Two other questions that have come up in my experiments - is it possible to support merging the className prop without overwriting the className provided by stylex.props? And is there an elegant way to create inline styles from primitive prop values (e.g. create inline styles like width={50} instead of style={{ width: 50 }})? I want to do something like this:

<Button variant="primary" width={100} className="hello-world" />

I'm not sure if it's possible to support the className prop without overwriting the className prop that stylex.props is applying? Could I do something like this? Or somehow use stylex.includes()?

const Button = ({ className }) => {
  const stylexProps = stylex.props(styles.base)
  return (
    <button
      className={`${stylexProps.className} ${className}`}
      style={stylexProps.style}
    />
  )
}

I know I can achieve the width={100} prop like so:

const dynamic = stylex.create({
  width: (width) => ({ width }),
})

But this creates a CSS variable, when I really just want to set the width inline style. I know I can do this:

const Button = ({  background, style }) => (
  <button
    {...stylex.props(
      backgrounds[background],
      style,
    )}
  />
)

Then I can use it like:

<Box background="primary" style={{ width: 50 }} />

But can I achieve this API somehow, without creating CSS variables?

<Box background="primary" width={50} />

[nmn]

Can you elaborate more on the style optimizations that the getStyled() function prevents?

Today, when you define and use styles within the same file it can be completely compiled away. When you do any kind of cross file composition of styles, we need to use the stylex.props function at runtime which merges classNames at runtime. It's a small cost - you're merging a some objects to generate the final className string, similar to cn, but if it's used everywhere it can become a hot path. This is why we've spent a lot effort in making the object merging logic as fast as possible and use memoization etc.

In the future, we should be able to compile away certain cross-module style merges as well. However, props and functions cannot be compiled away. Again, it's not a big deal from a perf point of view. The code quality is my bigger concern. I feel like it adds unnecessary indirection in an attempt to make your code more DRY.

---

In terms of the pattern you're describing, you really should be using the variables API.

'm not sure if it's possible to support the className prop

You want to Pass styles as props to components

IMO, You should accept a single styles prop and use type to constrain what it accepts. The tradeoff here is that there will be slightly more boilerplate when the component is being used but you'll achieve more clarity about what is happening and remove indirection.

import * as stylex from '@stylexjs/stylex'
import typeof { colors } from './vars.stylex.ts'

type Props = {
  style: StyleXStyles<{
    backgroundColor?: colors[keyof colors],
    borderWidth: 1 | 5,
    width?: number,
    height?: number
  }>,
  ...
}

// Box has no variants
export const Box = ({ style, ...props }: Props) => (
  <div
    {...props}
    {...stylex.props(
      styles.base,
      style,
    )}
  />
)

---

And is there an elegant way to create inline styles from props?

You might want to look at #534

[codynova]

@nmn Thanks again, I've familiarized myself with the stylex.props API and experimented a lot. It seems there is no way to merge with className, but I wasn't sure about stylex.include as I couldn't find it in the docs

I'm thinking about the possibility for a component created with Stylex to work with styled-components. Today we're using Linaria for our design system, but styled-components is used in many apps. The desire would be to interoperate with styled-components via className like const StyledBox = styled(Box) Currently I can allow this by completely overwriting the Box className, but I was hoping to support merging

EDIT: After testing, this seems to work, but I'm not sure if this is breaking any rules?

const Box = ({ background, width, height, className, ...props }) => {
  const stylexProps = stylex.props(
    styles.base,
    backgrounds[background],
  )
  return (
    <div
      {...props}
      className={`${stylexProps.className}${className ? ` ${className}` : ''}`}
      style={{
        ...stylexProps.style,
        width,
        height,
      }}
    />
  )
}

Although I realize that just using Stylex here will be recommended for many reasons, I'm considering how to support migrations 😄

I appreciate the power of the StyleXStyles prop pattern, but aren't these the equivalent options?

<Box background="primary" />

vs

import { color } from './vars.stylex.ts'
const styles = stylex.create({ base: { background: color.primary } })
<Box style={styles.base} />

I work in the developer experience org at Coinbase and we're considering Stylex for an upgrade to our Coinbase Design System. I believe Stylex would be a significant improvement over Linaria for us, but I have to sell those benefits, and devex is our biggest focus. Currently our devs are used to these style prop patterns, so I'm exploring how / if I can implement them with Stylex. These patterns could potentially make the difference in adoption for us (our problem, not yours), even if they are not perfectly idiomatic to Stylex

[codynova]

Regarding dynamic inline styles without CSS variables, I'll definitely just use the variables API for dynamic styles if that's what's most correct - it just seemed like a "waste" to be creating a className + inline styles with a CSS variable, when a simple inline style would suffice. I figured that would reduce the overall CSS bundle

[nmn]

I'm thinking about the possibility for a component created with Stylex to work with styled-components. Today we're using Linaria for our design system, but styled-components is used in many apps.

Don't do this. Don't mix different styling systems as you lose all the guarantees when merging styles. Existing system either generate styles at runtime which is slow. Or they just apply multiple classNames that can apply conflicting CSS. StyleX solves all of this but only when it's used exclusively on an element.

I'm considering how to support migrations

For migrations I would suggest either:

1. Codemods - styled-components, emotion and linaria can all be codemodded to be StyleX in the vast number of cases. The only exceptions would be super dynamic things which may or may not be supported by dynamic styles in StyleX today.
2. Transition on a per-component bases. While migrating ensure that you don't mix multiple styling systems on the same component. Two separate components can keep using two separate systems.

but aren't these the equivalent options?

Not really.

This is supported in StyleX. You just need to implement this with conditional styles in the original component. This is where we started with your getStyles() function. Although I prefer you to duplicate that functionality in each component, that's a stylistic opinion.

<Box background="primary" />

but I have to sell those benefits, and devex is our biggest focus

It can be tricky to define devX in this context.

This would be equivalent to what you have now:

<Box background="primary" />

But, the mroe scalable solution is indeed something like this:

import { color } from './vars.stylex.ts'

const styles = stylex.create({ 
  base: { background: color.primary }
})

<Box style={styles.base} />

You may think this is verbose and worse for devX. We also have PR up to define styles inline, which would enable something like this:

import { color } from './vars.stylex.ts'

<Box style={stylex.inline({ background: color.primary })} />

While this is still being discussed, something like this can be implemented today as a separate Babel plugin that can be configured to run before StyleX does the compilation.

There's probably still a couple of questions here. Is it annoying to have to import color and use color.primary a bit. Yes. But is it worse for DevX overall? I would argue not. It's very obvious and explicit what color.primary is in this example by opening the file or simply looking at the TS type. When using a string like "primary", what it means is unknown and not easy to understand. This is also why I think getStyles() leads to worse DevX in the long run. Investigating what styles are being applied takes multiple jumps for the developer.

Is stylex.inline better for DevX? Yes and no. In the short term, this will likely convince more people as it feels like less overhead and a more concise way to do things. But having all styles for every component file be in the same location in a single stylex.create file can be very valuable for the long term readability of a codebase.

My recommendation

Start with the stylex.inline solution. I'm slowly working to build a standalone Babel plugin to enable this while we discuss whether or not it is a good idea for StyleX itself. Hopefully, this API is enough to make a case for StyleX's devX.

Over time, if it makes, you can code-mod your codebase to move to a single consistent pattern of using either stylex.create or stylex.inline and disallow one of the two patterns.

[kevintyj]

This is actually really informative and really helpful! Perhaps this should be a topic that is covered in the docs? I am assuming many are trying to use existing tokens with StyleX.

[nmn]

What specifically would you like to see in the docs? We don't want to talk about Shared Media queries yet, because we don't know what it will look like.

[kevintyj]

What specifically would you like to see in the docs? We don't want to talk about Shared Media queries yet, because we don't know what it will look like.

Just did some further testing:
It seems that when importing variables from external libraries, it doesnt work even within defineVars. I maintain a personal color library for the colors that I use for my personal projects and some projects at work, would love to directly import and use these colors as variables into a project like so:

import * as colors from '@me/my-personal-colors'

export const colorTokens = stylex.defineVars({
	bgColor: colors.neutral.0
});

But the part about adding to the docs was more on the sharing values across files. But since it is a temporary limitation with a new process of adding additional capabilities when defining vars in on the horizon, perhaps we could wait for the implementation to come. But I think it would also be helpful to document a few purposeful limitations/patterns like the ones you shared above and many others in the issue board.

[nmn]

It seems that when importing variables from external libraries, it doesnt work

Because the compiler needs to read the contents of that file and StyleX only compiles a single file at a time.

But since it is a temporary limitation

It's not temporary...

Let me try to clarify the rules of compilation:

• Every StyleX function other than stylex.props() (and the deprecated stylex()) is essentially a macro that is compiled away.
• Therefore, all arguments passed into stylex.create, stylex.defineVars etc, need to be statically analysable in the same file.
• There is ONE exception to the no imports rule. Any file can import a named export of stylex.defineVars call from a .stylex.js file. This exception applies to both stylex.create, stylex.createTheme and other stylex.defineVars calls.

Does that make sense?

---

Some additional notes:

• The evaluation of constants, math expressions etc for compilation within a file is quite robust. This is why my example showed an object being used rather than many const strings.
• We avoid reading the contents of other files during compilation for two reasons:
  • Build performance
  • Every file compilation is atomic for cacheability. If we supported the pattern you shared, if you edited the imported file, every file that imports it would need to be recompiled. With StyleX only the file that is edited needs to be recompiled.
• The way we make Variables work is by hashing filepath + export name + key name.

[kevintyj]

Ah got it! I just somehow understood it completely the wrong way. This is some great info on the design choices! I just saw the open-props package inside styleX, probably the best way to share props this way is through a library that directly invokes stylex functions as mentioned above.

[nmn]

Yup. Look through open-props for an example of how to share styles. I'm working on removing unused CSS variables after generating the CSS bundle. This will just be a Postcss plugin.

[o-alexandrov]

@nmn have you tried adding a new concept calling it “special global variables” that get replaced at build time before stylex plugin?

Such global variables would get replaced using replace plugin, for example: rollup-plugin-replace.

• every bundler (webpack, esbuild, etc. has a similar plugin)

Such global variables should work even without stylex adding them. It’d be great to know, if anyone tried it to avoid the extremely bad DX with only statically analyzable variables.

Another pattern would be Facebook’s prepack, but it’d be much more complicated

[nmn]

@nmn have you tried adding a new concept calling it “special global variables” that get replaced at build time before stylex plugin?

I have been thinking along similar lines to create a standalone project to implement something like Bun's macro system in Babel. But this would be a project separate from StyleX itself. You're allowed to use any transformation steps you want before StyleX, but StyleX won't handle this for you.

---

Also, the question in this issue seems to have been addressed, so I'm converting this to a discussion.

[HQ92]

I was looking at the current state of the defineVars and stylex.types.atRule functions and they don't really solve what i was looking to do. Currently I use styled-components and was looking to slowly convert a small project over to stylex to feel how it works and if I preferred it for the future but there's a few major blocks i am currently running into. i understand that css values need to be static at compile time but i feel there are some really useful libraries available or simple functions you can write yourself that take out a lot of the repetitiveness of rewriting code on each and every css line.

An example would be using the chroma-js library for modifying colours within styles. Technically this fails the only static values are allowed limitation, but this is something that in theory would not change and does not need to be executed within the runtime cycle, but can be done at compile time.

// index.tsx

import chroma from 'chroma-js';

const s = stylex.create({
  wrapper: {
    width: '100%',
    // backgroundColor: '#ff9264',
    backgroundColor: `${chroma('red').brighten(2).hex()}`,
  },
});

Another example would be to simplify repeating tedious calculations by allowing execution of simple functions that modify a variable defined from stylex, and even allow definevars to self reference values that are calculated from each other, for example a function that scales a size value:

// globalTokens.stylex.ts

import stylex from '@stylexjs/stylex';

export const grid = stylex.defineVars({
  columns: {
    default: '10',
    [`@media (max-width: 1024px)`]: '5',
  },
  atom: `calc(100vw / ${REFERENCE.columns})`, // instead of the current method of having to define this line inside another defineVars variable export that references grid
});

// index.tsx

import { grid } from './globalTokens.stylex';

const ga = (scale: number) => `calc(${grid.atom} * ${scale})`;

const s = stylex.create({
  wrapper: {
    // width: '20vw',
    width: `${ga(2)}`, // instead of repeating `calc(${grid.atom} * 2)` everywhere with different values for the scale factor
    height: `${ga(20)}`,
    gap: `${ga(2)}`,
  },
});

I feel like these might be a big deal for reducing repetitive code and to make the framework more ergonomic to use unless if there's another way that stylex can handle these patterns?

[nmn]

backgroundColor: `${chroma('red').brighten(2).hex()}`,

Instead of using chroma-js, you can CSS to do this using the color-mix function or the new relative color syntax:

// with color-mix
backgroundColor: `color-mix(red, white 20%)`, // red but 20% more white

// with relative color syntax (No Firefox support)
backgroundColor: `oklch(from red calc(l + 20) c h);`

This is a more powerful system because you can use variables in CSS which is resolved contextually by the browser rather than having to know the actual color as a JS value.

color-mix is well supported in all modern browsers, and a PostCSS/LightningCSS plug-in can pre-compute such functions when given static values for older browsers.

---

I don't think this is all that problematic:

import stylex from '@stylexjs/stylex';

export const refs = stylex.defineVars({
  columns: {
    default: '10',
    [`@media (max-width: 1024px)`]: '5',
  },
});
export const grid = stylex.defineVars({
  columns: refs.columns,
  atom: `calc(100vw / ${refs.columns})`,
});

The problem with allowing references to self within the same defineVars call is that it becomes much harder to disallow cyclic references. The current design makes that impossible while still allowing variables to refer to other variables.

We prioritise safety, correctness and deterministic behaviour over convenience.

---

import { grid } from './globalTokens.stylex';

const ga = (scale: number) => `calc(${grid.atom} * ${scale})`;

const s = stylex.create({
  wrapper: {
    // width: '20vw',
    width: `${ga(2)}`, // instead of repeating `calc(${grid.atom} * 2)` everywhere with different values for the scale factor
    height: `${ga(20)}`,
    gap: `${ga(2)}`,
  },
});

Something like this is already in the works. It might even work already. It's not documented because evaluating static functions at compile-times fails sometimes. We're still finding and fixing the issues.

[HQ92]

Native css patterns are always better :D

I can work with the refs pattern and understand the cyclic references issue. It makes sense and isn't too much more code whilst making it much more predictable, so can support that. Hopefully you can get the static function evaluations working properly because at the moment I've paused testing on stylex due to this issue with duplication of code that makes it much more difficult to work with at the moment.

[nmn]

To be clear the functions that are supposed to work right now are:

1. Arrow functions
2. With only named arguments
3. With an expression return. (No {} block. () => expr)

The same work underpins dynamic styles.

---

The refs pattern can be cleaned up with proper function support in the future too.

import stylex from '@stylexjs/stylex';

const columns = {
  default: '10',
  [`@media (max-width: 1024px)`]: '5',
};
// These functions have to be written in a very particular
// way :(
const map = (val, mapper) => 
  typeof val === 'string' ? 
    mapper(val)
  : Object.fromEntries(Object.entries(
      (entry) => [entry[0], mapper[entry[1]]]
    ));

export const grid = stylex.defineVars({
  columns: columns,
  atom: map(columns, col => `calc(100vw / ${col})`),
});

---

What I really want is for broad support for Macros in JS and I like what Bun has done. The code above could then be:

import {map} from './utils' with {type: 'macro'};
import stylex from '@stylexjs/stylex';

const columns = {
  default: '10',
  [`@media (max-width: 1024px)`]: '5',
};

export const grid = stylex.defineVars({
  columns: columns,
  atom: map(columns, col => `calc(100vw / ${col})`),
});

[HQ92]

I've also been wondering if stylex.include actually works because I haven't been able to get it to work so far. i saw a discussion on one issue somewhere here but can't remember exactly where on whether it was even useful. I can see it being used to encapsulate small groups of css into reusable components essentially that can be used to build more layered style collections inside stylex rather then in components. An example would be as follows:

const commonFrame = stylex.create({
  base: {
    height: `100%`,
    width: `100%`,
    paddingTop: `0`,
    paddingBottom: `0`,
    paddingLeft: `30px`,
    paddingRight: `30px`,
    position: 'relative',
    margin: 'auto',
    minHeight: `100px`,
    display: 'block',
  },
});
const frame = stylex.create({
  content: {
    ...stylex.include(commonFrame.base),
    paddingLeft: {
      // eslint-disable-next-line @stylexjs/valid-styles
      [greaterThanIncSmallDesktop]: `210px`,
    },
    paddingRight: {
      // eslint-disable-next-line @stylexjs/valid-styles
      [greaterThanIncSmallDesktop]: `210px`,
    },
  },
});
const flex = stylex.create({
  container: {
    display: 'flex',
    minHeight: 0,
    minWidth: 0,
    flexDirection: 'row',
    flexWrap: 'wrap',
    justifyContent: 'space-between',
    alignItems: 'flex-start',
  },
});
const s = stylex.create({
  wrapper: {
    ...stylex.include(frame.content),
    ...stylex.include(flex.container),
    height: 'auto',
    width: '100%',
    flexFlow: 'column',
    flexWrap: 'wrap',
    justifyContent: 'flex-start',
    backgroundColor: '#060908',
    gap: `50px`,
    paddingTop: `100px`,
    paddingBottom: `100px`,
  },
});

export const El = () => (
    <div {...stylex.props(s.wrapper)}>item</div>
)

At the moment the above does not seem to work, it only works if applying the separate stylex classnames directly to the component itself:

export const El = () => (
    <div {...stylex.props(commonFrame.base, frame.content, flex.container, s.wrapper)}>item</div>
)

[nmn]

This should work. If it's not working, please create an issue. You may have discovered a bug.

[pksorensen]

I think this question is related.

We are building a project where the users (devs) is allowed to redefined the variable values in their own consuming projects. The consuming projects dont really need to use stylex.

Our project outputs the css and js file.

The problem is now that the variables that they should put into their tag on their site is those hashed names.

How do we do a defineVar call and specify that we want "pretty" names such its easy for the consuming project to redefine/override those variables?

[nmn]

This isn't supported yet, but is something we intend to do later.

In the meantime, you should be able to do this for own code by adding an extra transform step after the CSS and JS files have been generated to rename all the hashes with pretty names in both the CSS and JS.

[pksorensen]

Are you sugesting that given the token name in our code, we would be able to know the hash that is created for that token, and the replace them back to pretty names? Or some other route?

[nmn]

Yes that. But also, let me clarify that should not need to post-process your JS, only your CSS.

After compilation, CSS variables exist only in the CSS file as the JS only uses classNames. You should be able to read the configuration given to defineVars to convert the generated CSS variables in the CSS file to readable names. This process could be as simple as a find and replace.

---

I will add that using StyleX like this kind of defeats the purpose of using StyleX in the first place. If the users (devs) using your project were using StyleX themselves, you'd get better guarantees.

[Luko248]

I need help

When working with styleX, I keep running into the same problem. As long as I import the files where the stylex variables are defined directly into the .ts file with the component, everything works fine.

colors.stylex.ts

export const colorBtn = defineVars({
  btnPrimaryBgActive: "var(--colorBtnPrimaryBgActive)",
  btnPrimaryBgBase: "var(--colorBtnPrimaryBgBase)",
  btnPrimaryBgHover: "var(--colorBtnPrimaryBgHover)",
  btnPrimaryTextBase: "var(--colorBtnPrimaryTextBase)",
  btnPrimaryTextHover: "var(--colorBtnPrimaryTextHover)",
  btnPrimaryTextActive: "var(--colorBtnPrimaryTextActive)",
  btnSecondaryBgBase: "var(--colorBtnSecondaryBgBase)",
  btnSecondaryBgHover: "var(--colorBtnSecondaryBgHover)",
  btnSecondaryBgActive: "var(--colorBtnSecondaryBgActive)",
  btnSecondaryTextBase: "var(--colorBtnSecondaryTextBase)",
  btnSecondaryTextHover: "var(--colorBtnSecondaryTextHover)",
  btnSecondaryTextActive: "var(--colorBtnSecondaryTextActive)",
  btnSecondaryBorderBase: "var(--colorBtnSecondaryBorderBase)"
});

myComponentStyle.tsx

import {
  colorColor,
  colorBtn
} from "../../stylex/tokens/colors.stylex";
import {
  measuresSpacing,
  measuresBorderWidth,
  measuresBorderRadius
} from "../../stylex/tokens/measures.stylex";

const BUTTON_STYLE = stylex.create({
  default: {
    cursor: "pointer",
    borderWidth: measuresBorderWidth.borderWidthBtn,
    borderStyle: "solid",
    borderRadius: measuresBorderRadius.borderRadiusBtn,
  },
  disabled: {
    color: colorColor.colorDisabledText,
    backgroundColor: colorColor.colorDisabledBg,
    borderColor: colorColor.colorDisabledBorder,
    cursor: "not-allowed",
  },
  primary: {
    color: {
      default: colorBtn.btnPrimaryTextBase,
      ":hover": colorBtn.btnPrimaryTextHover,
    },
    backgroundColor: {
      default: colorBtn.btnPrimaryBgBase,
      ":hover": colorBtn.btnPrimaryBgHover,
    },
    borderColor: {
      default: colorBtn.btnPrimaryBgBase,
      ":hover": colorBtn.btnPrimaryBgHover,
    },
  },
  secondary: {
    color: {
      default: colorBtn.btnSecondaryTextBase,
      ":hover": colorBtn.btnSecondaryTextHover,
    },
    backgroundColor: {
      default: colorBtn.btnSecondaryBgBase,
      ":hover": colorBtn.btnSecondaryBgHover,
    },
    borderColor: {
      default: colorBtn.btnSecondaryBorderBase,
      ":hover": colorBtn.btnSecondaryBgHover,
    },
  },
  small: {
    paddingInline: measuresSpacing.spacingBtnSmallPaddingInline,
    paddingBlock: measuresSpacing.spacingBtnSmallPaddingBlock,
    fontSize: "12px",
    lineHeight: "1",
  },
  medium: {
    paddingInline: measuresSpacing.spacingBtnMediumPaddingInline,
    paddingBlock: measuresSpacing.spacingBtnMediumPaddingBlock,
    fontSize: "16px",
    lineHeight: "1.25",
  },
  large: {
    paddingInline: {
      default: measuresSpacing.spacingBtnLargePaddingInline,
      "@media (width <= 1024px)": measuresSpacing.spacingBtnMediumPaddingInline,
    },
    paddingBlock: {
      default: measuresSpacing.spacingBtnLargePaddingBlock,
      "@media (width <= 1024px)": measuresSpacing.spacingBtnMediumPaddingBlock,
    },
    fontSize: "18px",
    lineHeight: "1.5",
  }
});

export default BUTTON_STYLE;

myComponent.tsx

import * as stylex from "@stylexjs/stylex";
import { StylexTestComponentProps } from "./StylexTestComponent.types";
import BUTTON_STYLE from "./StylexTestComponent.styles";

export const StylexTestComponent: React.FC<StylexTestComponentProps> = ({
  variant = "primary",
  size = "medium",
  disabled,
  children,
  style
}) => {
  return (
    <button {...stylex.props(
      BUTTON_STYLE.default,
      BUTTON_STYLE[variant],
      BUTTON_STYLE[size],
      disabled && BUTTON_STYLE.disabled,
      style)}
      disabled={disabled}
      aria-disabled={disabled}>
      {children}
    </button>
  );
};

But what if I want to wrap all the variables in an index file that I want to import, as we are used to, I always get the same message: Only static values are allowed inside of a stylex.create() call.

export * from "./colors.stylex";
export * from "./fonts.stylex";
export * from "./gradients.stylex";
export * from "./measures.stylex";
export * from "./shadows.stylex";

If I name the index like index.stylex.ts, it works fine but the custom css properties that styleX generates does't contain any values.

I need to distribute styleX variables that contain design tokens from Figma in the form of an NPM package, but the actual logic of how styleX works doesn't allow me to do that, or it's not documented. Is this possible? Alternatively, how do I achieve this? @nmn The idea of using it is:

import { whatever } from @my/stylex/variables

My custom styleX css definitions in the current application.

[nmn]

I believe I already responded to you in a different discussion topic. This is not a supported pattern and it is documented on the sections about theming on the StyleX website.

1. All defineVars should be defined as named exports in .stylex.ts files
2. They must be imported DIRECTLY from the files they are defined in
3. They CANNOT be re-exported.

These rules makes stylex cache-able on a per-file bases and the compilation never needs to read across files.

[Luko248]

Thank you for your answer :)