Managing Client/Server Types

[akevinge]

Moved from: #330

A pattern that occurred in the codebase before the refactor was duplicating types (IIRC there was multiple Course and Semester types).

Some considerations

• tRPC has a RouterOutputs type

  type GetPlanByIdResponse = NonNullable<RouterOutputs['plan']['getPlanById']>;
  type Plan = GetPlanByIdResponse['plan'];
  type Semester = Plan['semesters'];

• Prisma has partials

  const userWithPosts = Prisma.validator<Prisma.UserArgs>()({
     include: { posts: true },
  });
  
  type UserWithPosts = Prisma.UserGetPayload<typeof userWithPosts>;

[akevinge]

With the size of our current app, this seems like a non-issue.

Taking inspiration from Dogehouse, they wrote a TS API wrapper around their Elixir API and used those types directly.
TRPC handles this for us, so in theory, as long as we query from top-level components we can avoid the need to duplicate concrete types.

[akevinge]

Here are some conversations we had on Discord:

Me

The issue is basically we duplicate the same type multiple times. There's only two reasons we would do this (that I can think of).

1. A component has specific needs ie. custom fields (ie Planner.tsx)
2. We need a concrete type

In case 1, I think it's best we define the client type explicitly.

In case 2... well why do we need a concrete type exactly?
There are really two scenarios of what happens a React tree:

• In a basic example, the top most component should be making the query and drilling down the properties in the query result.
  For ex: a TitleComponent does not need access to the entire query, just one property -> no need for concrete type
• But if for whatever reason a child component/service needs to access the entire query, we can use tRPC's RouterOutput type.

I was reading Dogehouse's codebase (which is hella clean), and I realized they follow a similar structure. The only diff between Dogehouse and ^ is that they don't have tRPC and created an API wrapper with response types.

Lastly, I have three issues with partials.

1. They don't necessarily represent the data that come out of tRPC, only prisma queries.
2. If we tried to use partials as general types, they may or may not represent what the client needs.
3. Trying to compose partials would be a mess of its own

TLDR: let's just use tRPC RouterOutput only when needed but try to write code that doesn't require the entire query to be passed all over
the place(?)

Caleeb — 01/25/2023 9:42 PM

Hmm okay so gave this some thought and I think after reading what y'all said here's my thoughts on it. I drew out how I think we could architect our app.

Regarding types, I think we should maintain separate types for backend & client

backend: use prisma client types & partial types in tRPC routes; store partial types inside src/server/types

frontend: manually define types & store inside src/types; use RouterOutput if needed

I agree w/ Kevin that partial types only represent data in prisma queries. As such it makes sense to keep it within the tRPC routes. Types for use in the client would then be separately maintained. This approach gives us some advantages:

1. Changing data from the route will ONLY affect the wrapper component
2. Needing to change types in client when passing more data from the server I think is actually an advantage. It ensures that the props passed into a component is always as intended and forces us to be deliberate when modifying props for components

We should strive to avoid needing to define additional types by writing components/methods/queries that use as little information as possible. We can also take advantage of the extensive type inferencing from tRPC and prisma so we only need that info when defining methods or components. I think I'm starting to see how tRPC allows us to achieve so much typesafety w/o needing to write as much typescript which is cool. Lmk what y'all think of this

Me — 01/25/2023 11:13 PM

Maybe I’m missing something I don’t really see the point of partials here. You said you wanted server/client separation, which is a valid point. I agree that explicity is good if a client type is needed. If we were to define partials in server/types, would we import them on the client? The point of partials is to give a concrete type to an inferred type, but if those partial types aren’t being imported anywhere they’re kinda pointless
Ya I also completely agree with what you said in the last paragraph

Caleeb — 01/25/2023 11:19 PM

Oh in my head the partials would be used within the tRPC router only. This is useful when you need to manipulate data from multiple prisma queries. So for example say we make two prisma queries and then perform work on the data. W/o partials you have to explicitly define anytime you need concrete types (i.e. parameters for methods) okay I completely reverse my stance on this I think explicitly defining is actually the move because similar to explicitly defining on the client, we want to operate on as atomic of data as possible (i.e. all our methods should just use the data being passed in). Partials just makes things more confusing by allowing us to simply pass in the entire query which creates antipatterns in the codebase imo

[akevinge]

A few things unsettled me from #367

• We're importing types from components/planner/types.ts into utils/utilFunctions.ts.
• pages/app/onboarding.tsx relies on the Credit type from components/credits/types.ts.

My impression was that types defined incomponent/**/types.ts would be used in that location and that types shared across many locations should be defined globally. I like the idea of "[Placing] code as close to where it’s relevant as possible."

Let me know what you guys think.