tRPC query gets the type right on the way in and wrong on the way out?
This is a weird one. I have a public procedure (query) that takes a string as an input. Part of the procedure calls the Clerk API to get all users. I then need to extract just one property from each user and turn it toLowerCase() so that I can compare against the input string.
I was getting a "can't read properties of undefined (reading .toLowerCase()) error, so I started logging stuff to the console and discovered that there's something weird going on with the types. On the way in, the query correctly logs out the type "string" for the property "artistName". But on the return (which is the second console.log at the bottom of the screenshot) it logs the type as undefined. Anyone know what's going on/what I'm doing wrong here?
4 Replies
Why have 2 properties when you can have just artistName and check if the user has it, then filter them according to this check.
This way, probably, you won't run into undefined.
Well I'm trying to build a simple search feature where a user types into a text input and the artists with names that match the string input get returned and displayed.
I wanted to do all of the filtering logic on the server so that the returned { data } would be just the names that match, but with the weird undefined thing it doesn't let me perform the comparison.
Are you suggesting I just return all artists and then do the filtering on the client?
Not really. I think your way is okay, but as far as I can tell, isArtist and artistName both must be truthy for an artist in your app. So why have isArtist, when you can check for whether a user has artistName right away and thus, may be, get rid of this undefined issue?
Hmm well I went ahead and implemented with client-side filtering but I’ll give what you’re saying a go and see if it solves the undefined issue