Video wird geladen...
Video konnte nicht geladen werden
Are React Server Components web-only or can they be used anywhere? What would it look like if @Expo added React Server Components for native iOS and Android platforms... 🧵 Find out now ↓
233,085 Aufrufe • vor 3 Jahren •via X (Twitter)
10 Kommentare

Project idea came from @acdlite / @sebmarkbage of Meta/Vercel Implementation ended up looking kinda like Next 13 / SvelteKit but with client-components by default. Web support working is a happy-accident, I'm more interested in the native applications.

To get this working, I extended @Expo CLI's implementation of universal @MetroBundler to generate server components which "stream" to the client. A suspense boundary fetches and caches components based on the incoming props.

React Native elements are sent via .rsc files as `<export>?module=<pkg>` which are then rehydrated client-side based on pre-registered modules (injected by Expo based on the runtime). Probably a better way to do this but I needed to work around useContext not being available.

Routes with the `+server` suffix (shoutout to sveltekit) are rendered twice with Metro, once for client-side components <Loading /> (suspense fallback), and <ErrorBoundary /> (React Error Boundary), then a second time for the async React Server Component.

Had to patch React (got to finally play with __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED) to support getCacheForType on native. A lot of little patches like this talk longer than a single day to get upstreamed. This is usually where release delays originate.

's crazy caching enables us to aggressively point the bundler at a file and bundle it multiple times with different settings. I did have to patch NODE_REQUIRE for `react-server-dom-webpack` as externals aren't supported in Metro yet.

To get the modules working I needed to shim react-native with Metro to use a special export that looks a bit like: export const Text = "Text?module=react-native" as typeof import("react-native").Text The alias dynamically changes based on the runtime env we're targeting.

Some things that don't work (as of last night): - Production builds lol - Streaming to native - Fast Refresh - Fetch caching Possibly more missing. I just eyeball'd the implementation based on some resources from @dan_abramov & post from @lydiahallie ↓

I mentioned that some people are "skeptical of server components" I meant "skeptical for native RSC". This is cuz users care a lot about apps being instantly responsive. @Expo auto-caches client-components using a policy similar to stale-while-revalidating, rsc are always fresh.

Was a fun experiment! Would love to see more developer resources from the React team so I can sanity check that my implementation is even right haha. Someone should make a `.rsc` extension for VS Code!
