Headless Component Library

[Tech-Dex]

Hello, I am looking forward to use StyleX with a headless library like Radix UI primitives or Ark-ui.
I see that they use styled function, but I am not sure how this can be achieved as I don't see that in StyleX docs.

[necolas]

Like this:

<Accordion.Item {...stylex.props(styles)} />

Except you can't style state via data-state; it looks like a limitation of Radix UI is the lack of component event callbacks for state changes.

Source: https://www.radix-ui.com/primitives/docs/guides/styling

Radix Primitives are unstyled—and compatible with any styling solution—giving you complete control over styling.

All components and their parts accept a className prop. This class will be passed through to the DOM element.

[Tech-Dex]

Yes, that is exactly what I was looking for.
Both Radix UI and Ark UI are using data-state flavor and this is the interesting part where I wanted to use StyleX. I am not aware of other headless libraries that might do a different approach that will allow StyleX to interact with state changes.

Does the team have something in mind for that in the near feature or it will be the component libraries job to integrate stylexjs?

[necolas]

The radix documentation wasn't clear to me, but probably you can use props like onValueChange to determine which item is open and then use that to set open-state styles. Radix claims the data-* props are only there for convenience, so presumably everything is also accessible via the JS API that you'd have to use for logging and any other behavior associated with a given component being interacted with.

[nmn]

I found the documentation a bit unclear as well, but if you need to observe data-state within StyleX, it's possible with a workaround:

const styles = stylex.create({
  accordianItem: {
    borderBottomWidth: {
      default: 1,
      ':is([data-state=open])': 2,
    },
    borderBottomStyle: 'solid',
    borderBottomColor: 'gainsboro',
  }
});

NOTE: This is a workaround and may stop working sometime in the future.

[Tech-Dex]

That looks great! Thank, nmn!

In another order of ideas what headless library would you recommend that integrates well with Stylex?

[nmn]

@Tech-Dex I'm not sure TBH. I build my own components and haven't used any of these headless libraries in a few years.

[vladmoroz]

Hey, I'm a maintainer on the Radix team. The data attributes are indeed designed to be used for styling the component states as shown in the example. If StyleX supports that, great. If that’s potentially going away, your second best bet is probably to make all your components controlled and hook into the JS state. We don’t plan to change anything for compatibility with StyleX just yet as Radix primitives are agnostic to styling and will work with anything that resembles how vanilla CSS works.

[nmn]

@vladmoroz Could you please elaborate how to hook into JS state? The documentation for doing this wasn't particularly clear.

[Lukjuh]

What is the best way for react-aria-components to get the render prop inside the {...stylex.props(...)} object in order to toggle conditional styles.

https://react-spectrum.adobe.com/react-aria/Button.html#styling

({ isFocusVisible }) => isFocusVisible && styles.focusVisible

import {
  Button as AriaButton,
  type ButtonProps as AriaButtonProps,
} from "react-aria-components";
import type { StyleXStyles } from "@stylexjs/stylex";
import * as stylex from "@stylexjs/stylex";

type ButtonProps = Omit<AriaButtonProps, "style">;

const styles = stylex.create({
  base: {
    fontWeight: 500,
  },
  focusVisible: {
    outlineColor: "red"
  }
});

const Button = ({
  style,
  ...props
}: ButtonProps & { style?: StyleXStyles }) => (
  <AriaButton {...props} {...stylex.props(styles.base, style)}></AriaButton>
);

export { Button };

[nucleartux]

Little off-topic here,

@nmn, you mention multiple times that the 'is' selector is a workaround and may be deleted in the future. Do you have an idea of what we should (or will) use instead? What if I don't have any other options except a data attribute selector?

[nmn]

@nucleartux There are a few scenarios where an attribute selector is necessary, so we will probably keep it around in some form. The API will probably change as you shouldn't need to use :is to make this work. Not sure what that will look like yet.

TLDR; Don't worry, when we remove support for :is selectors there will be a different solution available.

[BMCwebdev]

Really glad I found this. Started working on the same Button component and ran into this issue.

RAC is getting pretty widespread use, hopefully a more graceful solution will find its way.

I’m using the simple is() method for now, but might switch to the spread reusable function. The other option would be too much to implement in every component. Thanks for this @nmn

[BMCwebdev]

Follow up about getting RAC state into Stylex spread function.
#509

[predaytor]

yeah, we can even limit styles to static only (stylex.StaticStyles) to avoid passing dynamic styles. A simplified example of NavLink from Remix:

export interface NavLinkProps extends Omit<RemixNavLinkProps & LinkOptions, 'className' | 'style'>, LinkVariants {
	style?: stylex.StyleXStyles | ((props: NavLinkRenderProps) => stylex.StyleXStyles);
}

export const NavLink = forwardRef<React.ElementRef<'a'>, NavLinkProps>((props, ref) => {
	const { size, variant, style, ...rest } = props;

	const styleXProps = [styles.base, size && sizes[size], variant && variants[variant]];

	return (
		<RemixNavLink
			ref={ref}
			className={state => stylex.props(...styleXProps, typeof style === 'function' ? style(state) : style).className}
			style={state => stylex.props(...styleXProps, typeof style === 'function' ? style(state) : style).style}
			{...rest}
		/>
	);
});
NavLink.displayName = 'NavLink';

///

<NavLink
	to={route.path}
	prefetch="intent"
	style={({ isActive }) => [
		isActive ? linkVariants.foregroundHigh : linkVariants.foregroundGray,
		styles.navLink,
	]}
>
	{({ isActive }) => <></>}
</NavLink>