This post comes in 2 halves:tRPC Router FactoriesConsuming Router Factories in a React applicationLet's say you have a series of tRPC routes that look something like this:import { router, publicProcedure } from './trpc'const appRouter = router({ cities: router({ list: publicProcedure./*etc*/, get: publicProcedure./*etc*/, update: publicProcedure./*etc*/, delete: publicProcedure./*etc*/, }), cars: router({ list: publicProcedure./*etc*/, get: publicProcedure./*etc*/, update: publicProcedure./*etc*/, delete: publicProcedure./*etc*/, }), people: router({ list: publicProcedure./*etc*/, get: publicProcedure./*etc*/, update: publicProcedure./*etc*/, delete: publicProcedure./*etc*/, }),})It's clear that these routers will share a lot of functionality. They'll each operate on a different entity from your ORM or external API, but otherwise the logic and inputs/outputs will be abstractly similar. In the spirit of DRY we don't want to write and test all the endpoints multiple times if we can avoid

PrefaceIn 2023, Typescript is rarely questioned as an important tool for modern JavaScript developers, but one of its biggest limitations is the lack of added runtime type safety, particularly when dealing with IO at the boundaries of your application.To solve this problem a number of popular runtime validation and type-safety tools have popped up, usually competing on runtime parsing speed, API expressiveness, and a TypeScript vs JSON-schema based core.What seems to be degrading is performance of the developer experience. TypeScript drives the code intelligence of many popular editors, and as you add type complexity and size to an application or monorepo, code-completion and type-checking starts to draaaaag. This is because driving features like autocomplete means compiling your code on the fly repeatedly, and the more types & files needed to populate autocomplete for a line of code, the longer it takes to get a response.This is compounded by the growing movement of fully and deeply t

I had an interesting problem with Unreal Engine today. I have a Mech character which I want to attach stuff to, maybe it's segments of armour, or internal components, or weapons and other "stuff". Managing all these attach points and attachments is a pain, so I wanted to codify it in a data model, using Data Assets and Data Tables. This way I can have 100 mechs in the future with different skeletons and varieties of attachments, and codify them entirely as data with a single "MechCharacter".Given my background as a full stack software engineer, my instinct it to reach for a relational database of sorts, which can:Drive common behaviour with dataTie together multiple data sourcesSelf validate and restrict inputsThis isn't necessarily a complete or cohesive list. I'm writing this quite quickly. But basically I want to build a data model and code which gives me an amazing developer experience while building future assets. No weird bugs because I made a minor typo in one row somewhere!Last