Describe the issue
When using css.defineVars() in React Strict DOM on native, variables whose keys contain hyphens fail to resolve at runtime.
This commonly affects generated design-token packages, where token paths are emitted as kebab-case keys such as:
export const tokens = css.defineVars({
'components-button-primary-background': '#4f6af0',
});
Using that variable in css.create() on React Native produces a warning like:
React Strict DOM: unrecognized custom property "--components-button-primary-background__id__1"
The same pattern works on web/Next.js, and the same native repro works when the token key is changed to camelCase.
Expected behavior
css.defineVars() should resolve variables consistently on native regardless of whether the variable key is camelCase or kebab-case.
The following should work on native without warnings:
const tokens = css.defineVars({
'components-button-primary-background': '#4f6af0',
});
const styles = css.create({
root: {
backgroundColor: tokens['components-button-primary-background'],
},
});
This is important for generated design-token packages, where kebab-case keys are common and valid JavaScript object keys.
Steps to reproduce
I created a minimal Expo reproduction that follows the React Strict DOM Expo setup guide, which can be found here.
Steps to reproduce:
pnpm install
pnpm repro:android
or:
pnpm install
pnpm repro:ios
On native, the kebab-case token doesn't resolve and produces a warning:
React Strict DOM: unrecognized custom property "--components-button-primary-background__id__1"
The camelCase control does not warn and resolves as expected.
Test case
No response
Additional comments
To achieve the expected behavior, apply the patch using the following commands:
pnpm patch:apply
pnpm repro:android
Information about the environment:
react-strict-dom: 0.0.55
expo: 56.0.x
react: 19.2.3
react-dom: 19.2.3
react-native: 0.85.3
package manager: pnpm 11
platform: React Native / Expo native
Issue investigation
This appears to be caused by a mismatch in the native custom-property lookup path.
The native runtime appears to generate a custom property name that preserves the original key:
components-button-primary-background__id__1
But the lookup path normalizes the CSS custom property name by camel-casing it before reading from the custom property registry:
componentsButtonPrimaryBackground__id__1
That means the registry stores one key but native lookup checks another key, causing the value to be treated as unrecognized.
The camelCase control works because camel-casing does not change the key.
This is related to a long-standing open PR from 2024 which never got merged, and would fix this issue.
Suggested fix
Do not camel-case the native custom property name during lookup, just like PR 73 did.
Conceptually:
-return camelize(name.substring(2));
+return name.substring(2);
This makes native lookup use the same generated key format that defineVars() stores.
The repro includes a pnpm patch with that change for react-strict-dom@0.0.55.
With the patch applied:
the kebab-case token no longer warns and resolves the token
the camelCase control still works
the same app code and Expo setup are used before and after the patch
Why this matters
Generated token systems commonly use kebab-case names derived from design-token paths to better align between design and development. Requiring camelCase-only keys means generated token output that works on web can fail on native, even though the code uses css.defineVars() and css.create() through the public API.
While developing a universal design-system using kebab-case vars, I hit this issue myself, so I'd love to see this get fixed.
Describe the issue
When using css.defineVars() in React Strict DOM on native, variables whose keys contain hyphens fail to resolve at runtime.
This commonly affects generated design-token packages, where token paths are emitted as kebab-case keys such as:
Using that variable in css.create() on React Native produces a warning like:
React Strict DOM: unrecognized custom property "--components-button-primary-background__id__1"
The same pattern works on web/Next.js, and the same native repro works when the token key is changed to camelCase.
Expected behavior
css.defineVars() should resolve variables consistently on native regardless of whether the variable key is camelCase or kebab-case.
The following should work on native without warnings:
This is important for generated design-token packages, where kebab-case keys are common and valid JavaScript object keys.
Steps to reproduce
I created a minimal Expo reproduction that follows the React Strict DOM Expo setup guide, which can be found here.
Steps to reproduce:
or:
On native, the kebab-case token doesn't resolve and produces a warning:
React Strict DOM: unrecognized custom property "--components-button-primary-background__id__1"
The camelCase control does not warn and resolves as expected.
Test case
No response
Additional comments
To achieve the expected behavior, apply the patch using the following commands:
Information about the environment:
Issue investigation
This appears to be caused by a mismatch in the native custom-property lookup path.
The native runtime appears to generate a custom property name that preserves the original key:
components-button-primary-background__id__1
But the lookup path normalizes the CSS custom property name by camel-casing it before reading from the custom property registry:
componentsButtonPrimaryBackground__id__1
That means the registry stores one key but native lookup checks another key, causing the value to be treated as unrecognized.
The camelCase control works because camel-casing does not change the key.
This is related to a long-standing open PR from 2024 which never got merged, and would fix this issue.
Suggested fix
Do not camel-case the native custom property name during lookup, just like PR 73 did.
Conceptually:
-return camelize(name.substring(2));
+return name.substring(2);
This makes native lookup use the same generated key format that defineVars() stores.
The repro includes a pnpm patch with that change for react-strict-dom@0.0.55.
With the patch applied:
the kebab-case token no longer warns and resolves the token
the camelCase control still works
the same app code and Expo setup are used before and after the patch
Why this matters
Generated token systems commonly use kebab-case names derived from design-token paths to better align between design and development. Requiring camelCase-only keys means generated token output that works on web can fail on native, even though the code uses css.defineVars() and css.create() through the public API.
While developing a universal design-system using kebab-case vars, I hit this issue myself, so I'd love to see this get fixed.