Feature Request: Support data-* attributes on React Native (Parity with NativeWind)

[Sanchitv3]

Hi Uniwind team 👋
First of all, great work on Uniwind — we’re actively evaluating it and are very close to integrating Uniwind into gluestack-ui as our styling solution.

While testing, we noticed a gap in support for data-* attributes on React Native, which currently works well in NativeWind but does not seem to work in Uniwind (native).
Problem Statement

In NativeWind, we rely heavily on data-* attributes to drive state-based styling, especially for:

• Component states (open / closed / active / disabled)
• Compound components
• Accessibility-driven UI states
• Headless / unstyled primitives

Feature Request
Add support for data-* attributes on React Native, similar to NativeWind, so that the following work consistently:

data-[hover=true]:
data-[active=true]:
data-[disabled=true]:
data-[focus-visible=true]:

Context
We are almost done integrating Uniwind into gluestack-ui
This feature is one of the final blockers for full adoption
Happy to test, validate, or help with implementation feedback if needed

Thanks 🙏
Thanks again for building Uniwind — it’s shaping up really well.
Looking forward to your thoughts on this and whether it’s something that can be supported.

Let us know how we can help 🚀

[jpudysz]

Hey! 👋

Thanks so much for the kind words and for considering Uniwind for gluestack-ui. That's really exciting to hear! 🎉

Really appreciate you taking the time to share this feedback about data-* attribute support. We definitely see how important this is for state-based styling, especially for component libraries like yours.

We're actively looking into the best way to implement this. The thing is, we want to avoid wrapping everything in context like NativeWind did because that hits performance pretty hard, and keeping the core fast is super important to us. We're exploring other approaches that won't slow things down.

Timeline wise, we're planning to tackle this in Q1. Right now our main focus is getting the pro version ready, but this is high on the list after that. We want to make sure we implement data-* attributes properly without sacrificing the performance that makes Uniwind different.

Let us know if you have any other questions or suggestions in the meantime!

[Sanchitv3]

Hi @jpudysz ,
Thanks a lot for the detailed response — really appreciate the transparency here 🙌
Totally makes sense to avoid a context-heavy approach if it compromises performance. We definitely value Uniwind’s focus on keeping the core fast, especially for large-scale apps and libraries.

Great to hear that data-* attribute support is already on your radar and planned for Q1 and Best of luck with the pro launch 🚀
Looking forward to what’s coming next with Uniwind 💨

[Brentlok]

Hi @Sanchitv3
We've released https://github.com/uni-stack/uniwind/releases/tag/v1.3.0 with support for data-* attributes 🙌

[Alvi24]

Hi @Sanchitv3 We've released https://github.com/uni-stack/uniwind/releases/tag/v1.3.0 with support for data-* attributes 🙌

does it work with more advances selectors like data-hello:data-world:bg-white?

[Brentlok]

Yes, it works

[Sanchitv3]

Hi @Sanchitv3
We've released https://github.com/uni-stack/uniwind/releases/tag/v1.3.0 with support for data-* attributes 🙌

Hey, this is awesome — congrats on the v1.3.0 release 🙌
data-* support is a big step forward for state-based variants.

One thing we’ve been running into (mainly with gluestack-ui):
gluestack passes component state via a dataSet prop (e.g. dataSet={{ disabled: 'true' }}), but Uniwind variants expect actual data-disabled / data-active props at the element level. Since dataSet doesn’t automatically fan out to data-*, those variants don’t activate.

Right now, we’re handling this by converting dataSet → individual data-* props at runtime via a small HOC, so both systems stay in sync.

Are you planning to introduce a NativeWind-style plugin that could handle this kind of mapping at compile time instead?
That would remove the runtime bridge entirely and make integrations like Gluestack feel seamless out of the box.

Would love to hear your thoughts — and great work on the release 🚀

[Brentlok]

We can support dataSet prop, but there's no type definition for it. Are you using some kind of library that extends RN's type to include dataSet? Or you have your own type to extend those?

[Sanchitv3]

NativeWind actually already solves this problem on native platforms at runtime, so I wanted to share how that works in case it’s useful context for Uniwind.

On iOS / Android there’s no DOM, so NativeWind doesn’t rely on real data-* attributes. Instead, it reads the dataSet prop directly at runtime and uses it to resolve data-[...] variants internally.

For example:

<Pressable
  dataSet={{ disabled: 'true', active: 'true' }}
  className="data-[disabled=true]:opacity-50 data-[active=true]:scale-95"
/>

Under the hood, NativeWind:

• Treats dataSet as the source of truth for data variants
• Resolves data-[key=value] selectors from props instead of attributes
• Applies styles at runtime without requiring data-* props to exist

That’s why dataSet works cross-platform in NativeWind, even though data-* attributes don’t exist on native.

In contrast, Uniwind’s current data-* support is web/compile-time focused and expects actual data-* props, which is why dataSet from libraries like gluestack-ui isn’t picked up automatically.

Right now, to bridge this on web, we expand dataSet → data-* at runtime via a small wrapper. Long-term, a NativeWind-style approach (reading dataSet directly, or compiling it into data-*) would eliminate the need for that bridge entirely.

Hope this helps explain the difference in behavior

Adding this as a suggestion, aligning on a similar pattern between Uniwind and NativeWind could be really nice. From the gluestack side we can also expose actual data-* props where needed in components, so this isn’t blocking—just something that could simplify things and reduce glue code in the ecosystem.

[Sanchitv3]

Example creator code with nativewind:

dataSet={{
hover: isHoveredProp || isHovered ? 'true' : 'false',
focus: isFocusedProp || isFocused ? 'true' : 'false',
active: isPressedProp || isPressed ? 'true' : 'false',
disabled: isDisabled ? 'true' : 'false',
focusVisible:
isFocusVisibleProp || isFocusVisible ? 'true' : 'false',
}}

Example creator code with uniwind:

data-hover={isHoveredProp || isHovered ? 'true' : 'false'}
data-focus={isFocusedProp || isFocused ? 'true' : 'false'}
data-active={isPressedProp || isPressed ? 'true' : 'false'}
data-disabled={isDisabled ? 'true' : 'false'}
data-focus-visible={isFocusVisibleProp || isFocusVisible ? 'true' : 'false'}

Example creator code if we want to support both:

// for nativewind data attributes
dataSet={{
hover: isHoveredProp || isHovered ? 'true' : 'false',
focus: isFocusedProp || isFocused ? 'true' : 'false',
active: isPressedProp || isPressed ? 'true' : 'false',
disabled: isDisabled ? 'true' : 'false',
focusVisible:
isFocusVisibleProp || isFocusVisible ? 'true' : 'false',
}}
// for uniwind data attributes
data-hover={isHoveredProp || isHovered ? 'true' : 'false'}
data-focus={isFocusedProp || isFocused ? 'true' : 'false'}
data-active={isPressedProp || isPressed ? 'true' : 'false'}
data-disabled={isDisabled ? 'true' : 'false'}
data-focus-visible={isFocusVisibleProp || isFocusVisible ? 'true' : 'false'}

[Brentlok]

What about type definitions? Because React Native doesn't have dataSet prop, so passing that results in a type error

[Brentlok]

Since RNW doesn't support data-* and instead it uses dataSet to inject data attributes into html elements we've resolved it in this PR - #443

We don't want to support dataSet directly because as far as I know it's not typed by default in react native