eth_scanner
Explore posts from serversall my inferred typings on the frontend are `any`
I have a backend trpc router like this:
I import the type into my React Native client.
But when I try to use inferences, it gets typed weirdly:
Gets typed as:
Why is this happening? My versions across client and server are synced, and I have strict mode on.
4 replies
The inferred type of 'trpc' cannot be named without a reference to '...'
I have a monorepo setup like this:
root
-tsconfig.json
-frontend
--tsconfig.json
-backend
--tsconfig.json
I added a reference in the client tsconfig:
I added
"composite": true
to my backend tsconfig.
In my root tsconfig, I have:
However, now in my client, when I create my trpc instance:
export const trpc = createTRPCReact<AppRouter>();
I get a bunch of typing errors:
Where is this coming from and how can I fix it?42 replies
My TRPC hooks are getting typed as `any`
I'm using a Typescript + Express backend (Node.js, version 18), and a React Native (Typescript) frontend. For some reason by TRPC tanstack-query hooks don't seem to be typing things correctly. I am trying to understand why.
I have a monorepo setup with a file structure like this:
root
-frontend
-backend
So the frontend and backend files can import from each other, and everything lives under one
.git
in the root.
In my backend, I create a router and export the type:
Here is an example typing I get when I hover over a procedure in one of my subrouters. I don't return any
in any of my procedures.
In my React Native app, I import the type:
Then in my App.tsx
, I create the trpcClient
:
Now when I use a hook:
My data
gets typed as any
, what am I doing wrong in my setup?7 replies
PPrisma
•Created by eth_scanner on 6/6/2024 in #help-and-questions
Question about designing friend request / follow system with relational tables
I'm using Prisma on top of PostgreSQL. In my app, I have a
Follow
table, denoting follow relationships, and a FollowRequest
table, denoting pending follow requests.
I've enforced that in both the Follow
and FollowRequest
table, the permutation of two users is unique. So we can't have multiple duplicate FollowRequests
.
I want to write a function for my expres s server that can reject a follow request. I have the user context already. I see two ways of writing it:
1) Get the followRequestId
from the request. Lookup the FollowRequest
row in Prisma. If the user context matches with the FollowRequest
, delete the row. This is two sequential database interactions.
2) Get the sourceUserId
and the targetUserId
in the request (basically the person who made the follow request, and the person who was requested). I can then check if the user context matches the targetUserId
, but this time I don't need a database read to do so. I can then perform a Prisma delete with the unique combination (sourceUserId, targetUserId)
. This is just one database interaction.
The second one feels a bit odd, because I'm not working with the unique followRequestId
which is part of my FollowRequest
table. I'm leveraging the fact that (sourceUserId, targetUserId)
is unique.
Are there recommendations for how to approach this? I'm asking here because I'm not sure if I'm missing considerations on efficiency / how Prisma works.4 replies