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 think it's confusing how some names are converted to camel case when being written to the IDL, and then the Typescript client adds some camel casing of its own. It means the IDL names don't match either the smart contract code or the client code.
This gets extra confusing when writing Python client code where the casing conventions line up with Rust conventions - if the camel casing was all deferred to Typescript then the Python names could match the Rust names and the IDL names.
I'd be willing to make a PR for this. The result would be that IDLs would change but there would be no breaking changes for Typescript client users.
The text was updated successfully, but these errors were encountered:
I think this is worth changing, as the IDL casing isn't very consistent. But in regardless, clients should probably just change the case into whatever it wants and try to be agnostic to the IDL casing. The typescript client, for example, should always translate into the camel case.
I think it's confusing how some names are converted to camel case when being written to the IDL, and then the Typescript client adds some camel casing of its own. It means the IDL names don't match either the smart contract code or the client code.
This gets extra confusing when writing Python client code where the casing conventions line up with Rust conventions - if the camel casing was all deferred to Typescript then the Python names could match the Rust names and the IDL names.
I'd be willing to make a PR for this. The result would be that IDLs would change but there would be no breaking changes for Typescript client users.
The text was updated successfully, but these errors were encountered: