trpc / next-13 Goto Github PK

• Gotta be a client-side component
• Unsure if we should use react-query for mutation, we could or use @trpc/client directly

Currently, we use rsc.* to fetch data on the server and trpc.* on the client.

I wish this was the same object used so you didn't have to care if you're on the server or the client.

• I want to test protected pages
• I want to test non-public procedures how they feel

Blocker for #9

Add prisma similar to https://github.com/trpc/examples-next-prisma-starter

npm install throws below error messages to console log

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/next
npm ERR!   next@"^13.0.1-canary.3" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer next@"^12.2.5" from [email protected]
npm ERR! node_modules/next-auth
npm ERR!   next-auth@"4.14.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

probably, change version to next@"^13.0.3" from next@"^13.0.1-canary.3" and "next-auth": to "4.16.4", will work.

Thank you to anyone who takes the time to respond or share their thoughts on this matter.
With the condition that the app folder was used exsclusevly with client components (to gain access to the nested layouts feature),
is there a way to setup tRPC 10 to work in the app dir?

Thanks again

Maybe we want to do

function MyComponent() {
  const post = use(trpc.post.byId({ id: "1"}))
  // [...]

In order to enable parallelization and using Promise.all, etc

Just dumping some thoughts / half-baked ideas here

• With RSC - is there a point of tRPC? Is there a "lighter" approach that might be nice(r)? Maybe, but not for all
• With RSC - is there a point of react-query? yes, there's still client components
• Will there be a way to sync state and make sync the underlying state of the queries from RSC -> client & make isomorphic components?
  • Biggest question - unsure how state sync can work from a root "use client" Provider that renders on the server to the client that uses it.
• Will importing the full router on every RSC-request add any significant overhead?
• Will React Context providers be available on the server? If so, it be possible to do any "isomorphic" context providers? Will components be able to be isomorphic? This was a misconception. We'll do a root "use client" component & likely not sync state from actual RSC-components to client
  • If query state could be synced from server to client and context providers + components could be isomorphic, we could do stuff like using optimistic updates of a component that was initially rendered on the server.
• How to deal with caching?
• [..]

Yup: import { PropsWithChildren } from "react";

The way we hydrate the react-query cache on the client is a bit convoluted and unnecessarily complex DX.

I think I could make mine a bit easier to deal with so it's more generic instead:

• In RSC, create a real queryClient from react-query & populate it's cache when calling stuff
• Pass queryClientData={hydrate(queryClient}} to the Client component
• Have a generic HOC on client components that expects a queryClientData & uses setQueryData

API on the server (here) could look something like:

// page.tsx
function PostListRSC() {
  const postList = rscClient.post.list.fetch({});

  return (
    <PostList
      queryClientData={rscClient.hydrate()}
    />
  );
}

// page.tsx
function PostListRSC() {
  const postList = rscClient.post.list.fetch({});

  return (
    <Hydrated
      queryClient={rscClient.hydrate()}
      Component={PostList}
    />
  );
}

Then, the client could "just work" in a pre-hydrated way where we wouldn't need to pass initialData.

Overview of how to do it

• Create a new recursive proxy like the one we have in /@trpc
• Create new QueryClient() and populate it as we're calling (similar to our utils.*.fetch()

• Don't take the API design above as absolute truth, it's probable that it will have to be slightly different
• One important caveat is that we need to make sure this queryClient isn't used across multiple clients' requests.

In #23 I tried to be smart. That seem to have been a mistake.