Strongly typed response

[nickbar01234]

Hi maintainers, really cool project here! I've been building Chrome extension on top of LC and this would be very helpful to expedite dev process!

Would you consider a contribution to include zod validation / any object parser library to parse Graphql responses. My thoughts are

1. Encode any assumptions about the response we expect from LC graphql. This is better than the current state of the world with any.
2. We can build a client library with strongly typed response and published to npm for client consumptions

[alfaarghya]

Hii @nickbar01234 ,

1. I could not find any type in our current implementation. Could you please mention the code and the file here so I can track it down?

2. Building an npm package is a good idea, and I also thought about it for a long time. But there are a few considerations we have to think about -

   • As you may know, we are using the leetcode/graphql API to fetch data. So now, if we create an npm package and any user tries to send multiple requests through our npm package, it may choke the leetcode server.

[nickbar01234]

1. any type is implicit from Graphql fetch response. For example, in fetchSingleProblem controller, formatData expects a certain shape, but we won't get any signals from res.data.
2. Yep that makes sense. I think any client library should still be a proxy to your server but with a strongly typed response and input (query / params etc)

[nickbar01234]

Any thoughts here @alfaarghya? Or am I missing some context in the motivation?

[alfaarghya]

1. any type is implicit from Graphql fetch response. For example, in fetchSingleProblem controller, formatData expects a certain shape, but we won't get any signals from res.data.

Yeah, you are right! So what would you suggest?

[alfaarghya]

2. Yep that makes sense. I think any client library should still be a proxy to your server but with a strongly typed response and input (query / params etc)

Yeah, we can also add an option env to add a server link

[nickbar01234]

I think the first-class solution would be to somehow fetch Graphql schema from Leetcode server, but afaik, that's not possible. My proposal would be to encode the response in zod objects, which we then validate against from the server. So something like

// objects.ts
const problemSchema = z.object(
  {
    slug: z.string(),
    // ...some more types
  }
);

export type ProblemSchema = typeof problemSchema

// controllers.ts

const res = fetch(graphql url);
const problem = problemSchema.parse(res.data);
// do something with problem

Additional benefit: Publish the type definition -- currently client usage would require duplicating types / inspecting the screenshot you share in the README.

[alfaarghya]

Yeah! It would be a great Idea!!

[nickbar01234]

sounds good! Are you open to PR contributions?

[alfaarghya]

Sure :)