NPerhaps you should just rewrite it as a selector and have a pattern of passing it to the
.select option of useQuery? 'Build libraries not frameworks' and all thatNLooking at that code it does seem like you're triggering some unnecessary effects and re-renders with the way it's structured, it could be more pure
NOr if it absolutely has to have some async work, why not decrypt on the API/procedure side?
AHow come you need this at all? Not using ssl?
NI had a feeling that might happen
NMakes sense now why you needed the effects
NThere's probably a feature request for react-query in here, would be nice if select could be asynchronous and was cached, but I guess the problem is only created by how tRPC wraps it, because normally you'd be in control of the internals of the promise
NBut yes I'd probably just have a useDecryption(myData) hook, seems simplest overall
NSpecial but e2e encryption is pretty popular as a concept these days
NMaybe if tRPC's abstraction had an option like
async processResponse<R, D>(R): Promise<D>, though I wouldn't be shocked to hear that adding functionality to the react-query wrapper is out of scope.Ayou might be able to do this stuff as a link
ALinks enable you to customize the flow of data between the tRPC Client and Server. A link should do only one thing, which can be either a self-contained modification to a tRPC operation (query, mutation, or subscription) or a side-effect based on the operation (such as logging).
