feat: New Serialization Paradigm

[tannerlinsley]

• This reworks the entire serialization model including deferred streaming of data.
• Instead of using stream injection, it uses suspense for promises and recursive suspense for streams.
• defer(promise) is no longer needed, since we are walking the loader return and extracting promises and streams now.
• Await is still required in React <19 to consume deferred promises, but in 19, use will work just fine.
• The SSR and start examples now use the new , , and tags, which are also required for non React 19 full document hydration
• It begins (but doesn't fully flesh out), a universal server entry via createStartHandler. More work is needed for non-start SSR envs to use it, which is where createRequestHandler needs some more polish.
• Provides experimental support for RSCs. This does not include using client components yet (which will require a bit more work around RSC manifests for the client. @devagrawal09?)
• RSC requires that you override the react and react-dom version at the mono repo level. There are temp- entries there for what I know works
• Rendering RSCs requires the new renderRsc function, exported from @tanstack/start, which uses the new react-server-dom/client to isomorphically create React elements from either Readable's on the server or ReadableStreams/Fetches on the client. One of the reasons for this renderRsc() step is so that RSCs remain primitive streams until they can be handled by the router for SSR and caching, after which they are released back to the user via useLoaderData for consumption. Diving deeper, the primary reason for this is so that we can gain access to the original binary chunks of RSC syntax that are being streamed across the wire. Without access to those chunks, we cannot serialize and recreate the RSC across any serialization boundary.
• Some components and utilities have been further extracted into their own files to avoid circular deps, types and ultimately, mixing of client and server imports during RSC. There will be a lot more work to do here when we enable client components, as we will need to make sure server-capable router imports do not bring in useState, etc. I still have strong feelings that these imports shouldn't be invariants during bundling and should only warn at runtime... but I digress.
• The component got serious upgrades along with an undocumented feature of using the .tsr-once class to ensure than an element is completely removed before hydration is attempted.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 3b35e77. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 4 targets

• nx run-many --target=test:e2e:replay
• nx affected --targets=test:format,test:eslint,test:unit,test:build,build --parallel=3
• nx affected --target=test:types --exclude=examples/**
• nx run-many --target=build --exclude=examples/**

---

Sent with 💌 from NxCloud.

[tannerlinsley]

I'm not completely sure how to get things passing without forcing the entire monorepo into React 19...