react-native-css-interop cache is huge due to safelist in tailwind config

[evelant]

Description

Using the tailwind.config.js from gluestack-ui-v2 node_modules/react-native-css-interop/.cache/android.js is a 4.3MB minified js file that takes ~250ms to load on app start. That is a significant chunk of load time.

CodeSandbox/Snack link

https://github.com/evelant/css-interop-large-cache-example

Steps to reproduce

Copied from issue filed at nativewind here: nativewind/nativewind#1071

Describe the bug
Using the tailwind.config.js from gluestack-ui-v2 node_modules/react-native-css-interop/.cache/android.js is a 4.3MB minified js file that takes ~250ms to load on app start. That is a significant chunk of load time.

Is this intended or expected behavior? Does it come with a runtime performance penalty beyond the loading of the large file?

If this is expected behavior maybe a warning should be added to the docs.

Reproduction
https://github.com/evelant/css-interop-large-cache-example

npm install
npx expo export -p android

observe that node_modules/react-native-css-interop/.cache/android.js is very large and that it slows down app load significantly

Expected behavior
Nativewind adds little/no overhead to app loading and runtime

Additional context
nativewind/nativewind#1071 (comment)
nativewind/nativewind#1071 (comment)

gluestack-ui Version

latest

Platform

• Expo
• React Native CLI
• Next
• Web
• Android
• iOS

Other Platform

No response

Additional Information

No response

[marklawlor]

Breaking down this quote

Quote: nativewind/nativewind#1071 (comment)

@evelant @marklawlor, We are working on this problem by writing tailwind-plugin.

Use Case: We're working on a solution where we need to apply state-based styling to our components. Currently, in NativeWind, this is achievable using conditional className assignments.

Example:

<Modal className={isOpen ? "bg-transparent" : "bg-primary"} />

However, in Tailwind, it's possible to handle this with data-* attributes for cleaner state management:

Example:

<Modal className="bg-transparent data-[open=true]:bg-primary" />

To bring this functionality to NativeWind, we've written a Higher-Order Component (HOC) that provides developers with a familiar data-* attribute API. This HOC attaches and detaches className values based on the component's state.

Currently, we remove the data-* portion of the className and convert:

data-[open=true]:bg-primary

into:

bg-primary

However, this means that bg-primary won't be injected by default, so we require the use of a safelist to ensure the class is applied.

In the future, we plan to submit a pull request (PR) to officially support data-* attributes in NativeWind.

@evelant this is more of gluestack-ui problem than nativewind. you can open a issue on gluestack-ui repo we can follow up there.

---

NativeWind has already started added support for data-* https://github.com/nativewind/nativewind/blob/03b78ce3519d6d832b45b4f9977058d1c4c36654/packages/react-native-css-interop/src/__tests__/attributes.test.tsx#L41-L93

I don't have tests for the other operators, but I think they should be working https://github.com/nativewind/nativewind/blob/03b78ce3519d6d832b45b4f9977058d1c4c36654/packages/react-native-css-interop/src/runtime/native/conditions.ts#L391-L447

We use dataSet as the React Native prop for data-* as this aligns with React Native Web. But it can be used for other props as well.

[Viraj-10]

Thanks @marklawlor, This will reduce our size css file size by 1/10th. We will update our code base.

[Viraj-10]

@evelant support for v4.1 will come this week which will include all this changes as well.