To smurf or not to smurf? That is the question

[KATT]

When almost every class has the same prefix. IE, when a user clicks on the button, a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController. The SmurfID is used to fetch a SmurfOrderHistory which is passed to the SmurfHistoryMatch before forwarding to either SmurfHistoryReviewView or SmurfHistoryReportingView. If a SmurfErrorEvent occurs it is logged by SmurfErrorLogger to ${app}/smurf/log/smurf/smurflog.log

— https://blog.codinghorror.com/new-programming-jargon/#21

@dodas brought up a good question today which lead me to think about our exposed interfaces, should those all contain TRPC in the naming somehow?

I'm personally a bit annoyed whenever I use a "generic" name like createClient or createContext within VSCode, I often don't get the suggestion I want.

Should tRPC be exposing smurfed interfaces or non-smurfed functions? It would be good to get consistency in this for V10.

Examples:

• initTRPC vs init
• setupNext vs setupTRPCNext
• setupReact vs setupTRPCReact

[ixahmedxi]

smurf ftw

[sachinraja]

Smurf all or smurf none (as you noted). I'm fine with smurfing to avoid name collisions and provide better autocomplete.

[KATT]

Also, in the new version you'll really mainly do 1 import on the front-end and 1 on the backend which is calling a factory fn that you can declare as whatever you want

[dodas]

could we also export wildcard as trpc?
e.g.

// external/index.ts
export { init } from "./init";
export { router } from "./router";

// index.ts
export * from "./external";
export * as trpc from "./external";

this is basically what zod does

[mmkal]

I really like that. And to @KATT's point about IDEs/intellisense, I love how typing z. is enough for vscode to automatically add the import, and I think this is the reason.

[sachinraja]

Not to be that guy again but esbuild failed to tree shake the above (Rollup and Webpack succeeded). Generally I'd rather not do things that reduce the chance of tree shaking happening.

[mmkal]

If we follow zod's example, we could export { trpc } and people who are using esbuild and don't want to file an issue on esbuild asking why they fail when others succeed, can use wildcard exports. The switch is just import { trpc } from '@trpc/whatever' to import * as trpc from '@trpc/whatever' on the user side. The cost on this repo's side is a one liner export and (maybe) a note about it in the docs.

[ChiChuRita]

I think smurfing is appropriate, especially since it's only 4 letters more. Better autocompletion, no name collisions... as long as we don´t name functions like TypedRemoteProcedureCallContextCreator.

[samal-rasmussen]

No smurf please - I like my stuff clean. The namespace is already clear from the import, and if you happen to have a name collision somewhere you can always just add a smurf with as in the import.

[CoenWarmer]

All good for smurfing.

[aradalvand]

Gonna play the devil's advocate: Don't smurf.
Especially because acronyms like tRPC look extra awkward in camelCase.

And secondarily because it's just tedious to write; brevity ftw.
The context is derived from the import, no need to cram unnecessary words in there.

[ChiChuRita]

Thats why we write TRPC not tRPC. (in the smurf context)

[capaj]

tedious to write? When using typescript autocomplete is actually more helpful with smurfing. Without it, you might get dozens of unrelated init functions etc.

[iway1]

Would this mean TRPCClientError being renamed ClientError? Not sure I like that.

Smurfing improves readability of the code even though it's uglier. I think it's a mistake to optimize for aesthetics over readability.

Plus, when you have a name space you get some really cool auto complete/auto import functionality. IE you can type "TRPC" and just arrow key through all its exported members. Not sure that's particularly useful here, but just an example of why it might be advantageous.

[samal-rasmussen]

I think we must be defining readability very differently because I am much more able to read ClientError than TRPCClientError.

[capaj]

Smurf all the way, everyhwhere.