feat(package/react): Add react-native support #2299
Conversation
* Native Entry Points: Added files like client.native.ts, index.native.tsx, ssr.native.ts, and native versions of the focus/online hooks so Metro resolves to RN-specific implementations that never import react-dom/server. * Manifest & Build Updates: packages/react/package.json now maps every export (., ./client, ./ssr/ssr) to the native bundle first and drops the wildcard ./*. bob-esbuild.config.ts rewrites dist/package.json so the published tarball keeps those native mappings. * Local Hook Helpers: Add our own hooks.ts (useRerender, useUpdateEffect, etc.) instead of @react-hookz/web to avoid a peer dependency on react-dom. No behavioural change, just implementation detail. * Docs: Added a short “React Native” section to the README describing the limitations (SSR still web-only, effects use AppState).
|
@JohannesHome Given the scope I'll need more time to think it through, especially on the Rest assured, this PR will be merged in some way. If I ever wanted to split it up into smaller chunks in the process, you will be credited as Co-Author in those commits. What do you think? |
Thanks, you don't need to credit me if it adds unnecessary work. Take your time to think it through. |
I tried using gqty in react-native and ran into the issue that there are dependency pointing to react-dom, leading to an issue with the metro bundler pulling web resources. There where two dependencies that pull in react-dom, the hooks from
@react-hookz/weband the ssr implementation usingreact-dom/server.This PR introduces react-native support for @gqty/react. I did the following updates:
@react-hookz/webwith local hook helpers via hooks.ts (useRerender, useUpdateEffect, etc.) to avoid the peer dependency on react-dom. No behavioural change, just implementation detail. May need more testing.There are some risks in this approach as far as I can tell the removal of the wildcard could be a problem and would break anyone using
@gqty/react/*imports. Also the custom implementation of the hooks maybe a risk.As an alternative I could also create a new
@gqty/react-nativepackage in order to keep the react package as is. There is some code duplication of course, it maybe possible to move certain things into a shared package but will take more time.