On Type Inference

On Type Inference · @radekmie’s take on IT and stuffOn Type Inference By Radosław Miernik · Published on 31 July 2026 · Comment on RedditTable of contents IntroBackgroundWhere it all startedA follow up questionWhat about arguments?Something in betweenClosing thoughtsIntro A few days ago, I started reviewing a rather simple pull request from one of my team members. I added a few comments here and there, but there was one thing that triggered me: an explicit generic type annotation was now needed in a place it wasn’t before. It was but one type, but still.We started a discussion about whether it’s a bug in the package we’re using, or if it’s something we did incorrectly… Or at least I was, because my colleague wanted to get over it. But as it’s one of the hills I will die on, we started talking.This text is more or less a summary of our discussion.Background Our application has three API layers: an internal DDP API (Meteor-specific), a REST API we developed years ago, and a GraphQL API we slowly migrate all third parties to. When it comes to types, we need three different approaches. We use GraphQL Codegen, and it’s great! When it comes to DDP, we type it manually, mostly due to a lot of old and untyped code1.As for the REST API, we started gradually typing it, endpoint by endpoint. The actual implementation is rather straightforward: we have a single type that maps the endpoints to the params and response types. A slightly simplified version looks more or less like this:export type Restaurant = { id: string; logoUrl: string; /* ... */ };

export type ApiEndpoints = { 'restaurants/v1/get': { params: { id: string }; response: { restaurant: Restaurant }; }; 'restaurants/v1/list': { params: { search?: string }; response: { restaurants: Restaurant[] }; }; /* ... */ }; Of course, the ApiEndpoints type is, well, only a type, so we can’t really use it to fetch anything from the REST API. In the runtime, we need to execute the request somehow; either by using fetch or some popular wrapper you like. More importantly though, it must take care of authorization and the Accept-Language header. In types, it’s defined using a rather simple generic type:export type ApiFunction = Endpoint extends keyof ApiEndpoints>( url: Endpoint, params: ApiEndpoints[Endpoint]['params'], language: string, ) => PromiseApiEndpoints[Endpoint]['response']>; Now that we have it all set up, let’s talk about how we could use it in our React components. The api: ApiFunction is already there2, so we only need a hook around it. Ideally, it would take care of caching and other stuff, so we went with swr, as we already used it elsewhere. The hook looked like this:import useSWR from 'swr'; import type { ApiEndpoints, ApiFunction } from '../api';

export const useRestApi = Endpoint extends keyof ApiEndpoints>({ api, language, params, url, }: { api: ApiFunction; language: string; params: ApiEndpoints[Endpoint]['params'] | null; url: Endpoint; }) => useSWR(params ? [url, params] : null, args => api(...args, language)); If you never used swr, here’s how it works: it accepts a key (here: the [url, params] tuple) that is passed to the fetcher (here: the function calling api). Caching is based on the key, and if it’s null, the query is not executed. Here’s an example of using it:// `data` is of type `{ restaurant: Restaurant } | undefined`. const { data, error, isLoading } = useRestApi({ api, language: 'en', params: { id: 'example' }, url: 'restaurants/v1/get', }); Where it all started What was changed in the pull request? We needed to pass an additional config to some requests, i.e., we couldn’t handle it with a global configuration. Here’s the proposed change:+import type { SWRConfiguration } from 'swr'; export const useRestApi = ({ api, + config, language, params, url, }: { api: ApiFunction; + config?: SWRConfiguration; language: string; params: ApiEndpoints[Endpoint]['params'] | null; url: Endpoint; -}) => useSWR(params ? [url, params] : null, args => api(...args, language)); +}) => + useSWR( + params ? [url, params] : null, + ([url, params]) => api(url, params, language), + config, + ); Can you spot the problem? I can assure you, it works as expected - config is optional, and typed correctly when passed to useRestApi. The explicit type argument passed to useSWR is noisy, but I guess we all could live with it (yes, I know I said I’d fight, but bear with me).The thing that drew my attention was the change in the fetcher function: why are the params now expanded? Was that intentional, or collateral damage a result of LLM usage? I did a quick check, and my intuition was right – it was intentional because it was “needed”… Because args was now any, and you can’t spread it. But you can destruct it in the arguments, so… A workaround.Now, what was the reason? Weren’t the inferred (implicit) types exactly the same before? Well, almost. You see, useSWR and SWRConfiguration take four and three generic types respectively, not one. There’s obviously the result (the one...

On Type Inference

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills

Google will expand age checks on Android worldwide till the end of the year