Analytics libraries like datadog patch React.createElement to override onPress prop for tracking. Here
Although, not a huge fan of the approach taken here by the datadog library as alternate solutions exist. But I think react-native-css-interop should support such a usecase as the original React.createElement doesn't prevent patching.
Approach
RN CSS interop uses named import createInteropElement to replace createElement, this prevents patching, as babel transpiles such imports to read-only. The approach taken in this PR is to use namespace imports. e.g. createElement will become ReactNativeCSSInterop.createInteropElement. Such an import is not considered read-only and users can perform patching ReactNativeCSSInterop.createInteropElement = () => {}
Note
This PR is a partial solution to allow patching React.createElement. NativeWind's current tsc approach to build distribution packages generates below output. This output lacks ability to mutate createInteropElement as it only has a getter in Object.define, no writable. I think we should distribute packages with esnext module preset in tsconfig or use expo module scripts for distribution builds. Would love to know your thoughts on this.
Issue
Analytics libraries like datadog patch
React.createElement
to override onPress prop for tracking. HereAlthough, not a huge fan of the approach taken here by the datadog library as alternate solutions exist. But I think
react-native-css-interop
should support such a usecase as the originalReact.createElement
doesn't prevent patching.Approach
RN CSS interop uses named import
createInteropElement
to replacecreateElement
, this prevents patching, as babel transpiles such imports to read-only. The approach taken in this PR is to use namespace imports. e.g.createElement
will becomeReactNativeCSSInterop.createInteropElement
. Such an import is not considered read-only and users can perform patchingReactNativeCSSInterop.createInteropElement = () => {}
Note
This PR is a partial solution to allow patching
React.createElement
. NativeWind's currenttsc
approach to build distribution packages generates below output. This output lacks ability to mutatecreateInteropElement
as it only has a getter inObject.define
, nowritable
. I think we should distribute packages withesnext
module preset in tsconfig or use expo module scripts for distribution builds. Would love to know your thoughts on this.