[shiny]

Awesome, thanks a ton. Sounds like your lib would be perfect for me. Also, kudos to somehow typing that on your phone.

Looks like I need to incorporate encoders/decoders into my scheme. I might just steal that code outright.

Thanks for the Zapatos rec, that looks perfect.

fyi, my current generic method sigs looks like:

  export const makeRequest = <Name extends keyof Endpoints>(
    _name: Name,
    method: Endpoints[Name]['method'],
    path: Endpoints[Name]['path'],
    props: {
      data: Endpoints[Name]['clientSends'];
      onSuccess: (json: Endpoints[Name]['serverResponds']) => void;
      onError: (json: any) => void;
    }
  ) => { // ...

Dropping all of these typing shenanigans and going back to Elixir/Phoenix is always half-tempting, but I will soldier on for now...

[eyelidlessness]

Fwiw I didn’t type all of it on my phone, I copypasta’ed from a draft blog post then manually indented lol. The approach you’re showing makes sense and it’s not unlike how I’d approach a one off/internal project where I know the routes are all defined in a predictable structure. The benefit of the pseudo types I shared is that the only predetermined structure is the route factory call. It only needs to know input output and serialization types. It can be extended to use TS 4.1 template literal types to validate path parameters. But it’s application agnostic.