You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe typing in the anchor TS library could be greatly improved
The way types are generated currently is a bit of a maze, and this complexity even surfaces to the user
For example, today it took me > 1h to figure out how to properly type an account retrieved when listening to account changes for a given program:
constrequest: IdlAccounts<Chainference>["inferenceRequestAccount"]=chainference.coder.accounts.decode(// @ts-expect-error: we have to access a private field here.chainference.account.inferenceRequestAccount._idlAccount,account.accountInfo.data);
Not even chatgpt was a good help there, and docs for the anchor TS lib are not that comprehensive and don't mention this kind of functionality either.
For this situation the ideal would be for there to be a properly typed decode method that doesn't need any typing at all, or passing in the account name (which I am getting from an obscure private field there because having hardcoded magic strings is not a good idea - it could break silently if the program changes).
But I think this is just an illustration of the kinds of problems that are arising from the current typing implementation.
One can envision a much cleaner approach where instead of generating a huge type for the entire program IDL, separate types would be generated for each account type, for example.
Edit: Another example of poor typing would be the tooltip for calling a method:
it should be clear what parameters are expected and what is returned, but the user is presented with a complex set of type annotations which take some time to decipher.
Edit 2: the following day I had to write this:
The text was updated successfully, but these errors were encountered:
I believe typing in the anchor TS library could be greatly improved
The way types are generated currently is a bit of a maze, and this complexity even surfaces to the user
For example, today it took me > 1h to figure out how to properly type an account retrieved when listening to account changes for a given program:
Not even chatgpt was a good help there, and docs for the anchor TS lib are not that comprehensive and don't mention this kind of functionality either.
For this situation the ideal would be for there to be a properly typed decode method that doesn't need any typing at all, or passing in the account name (which I am getting from an obscure private field there because having hardcoded magic strings is not a good idea - it could break silently if the program changes).
But I think this is just an illustration of the kinds of problems that are arising from the current typing implementation.
One can envision a much cleaner approach where instead of generating a huge type for the entire program IDL, separate types would be generated for each account type, for example.
Edit: Another example of poor typing would be the tooltip for calling a method:
it should be clear what parameters are expected and what is returned, but the user is presented with a complex set of type annotations which take some time to decipher.
Edit 2: the following day I had to write this:
The text was updated successfully, but these errors were encountered: