TypeScript errors

[shashkovdanil]

I noticed that in many files there are TS errors. After tsc --noEmit I saw this

Found 112 errors in 50 files.

I think these errors are worth fixing, also update the types if they are written incorrectly. This will help improve the reliability and predictability of the code

@roiLeo @preschian wdyt?

[shashkovdanil]

@roiLeo I see that many errors connected with types from GraphQL responses, can I setup codegen? If you're not familiar with it, it's a CLI tool for generating types based on the GraphQL scheme, meaning you don't need to manually write types for each entity.

More info is here: https://the-guild.dev/graphql/codegen

[roiLeo]

can I setup codegen?

I like zod

[shashkovdanil]

can I setup codegen?

I like zod

you mean this https://github.com/withshepherd/graphql-codegen-zod?

Usually zod is used for validation, I have never seen it used to generate types for graphql. Can you share some example?

[roiLeo]

Usually zod is used for validation, I have never seen it used to generate types for graphql. Can you share some example?

okay this is not related

More info is here: https://the-guild.dev/graphql/codegen

How will you handle this since:

• schema is in external project
• schema can change
• schema can be different from chain

[shashkovdanil]

schema is in external project

Do we have public link for schema? Or maybe we can fetch it?

schema can change

The purpose of codegenerating types from a schema is precisely to make it easy to update types after a schema change. In my projects I just run the generate script in the pre-commit hook, or on CI

schema can be different from chain

We can generate types for different schemes

In my experience, having type generation from the schema is a must-have, because it greatly improves the readability and reliability of the code. You won't be able to pass wrong variables, you won't be able to access a property that doesn't exist, the code editor will have an autocomplete that shows what variables are passed, and what data comes in.

[shashkovdanil]

If you don't mind I can do Proof of Concept and show how it works

[roiLeo]

I know there is somewhere an issue about global (shared) schema between chains

may @vikiival give his opinion?

[vikiival]

Do we have public link for schema? Or maybe we can fetch it?

https://squid.subsquid.io/stick/graphql

Replace stick with any of snekk, speck, rubick, marck

I know there is somewhere an issue about global (shared) schema between chains

All is tracked here.

https://github.com/kodadot/loligo/issues

global (shared) schema

Yup KodaDot currently uses Universal Schema (v1) which can guarantee that majority of fields are the same.

I can do Proof of Concept

Let's try for AH* other chains

How will you handle this since:

This is true :) schema change is very hard to track, however if we can manage to cover USv1 it can solve some bugs

[shashkovdanil]

@vikiival

This is true :) schema change is very hard to track, however if we can manage to cover USv1 it can solve some bugs

I have understood correctly that this is why you can always get the current fresh scheme at this https://squid.subsquid.io/stick/graphql?

[vikiival]

Yes, I can update prod enpoint on the go, it helps us to fix stuff faster.

Mind that stick is indexer only for

[roiLeo]

• link multi chain NFT scheme type #4544