Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor contract calls: convenience methods in SDK and SophiaTypes in SDK #64

Open
2 tasks
marc0olo opened this issue Jul 6, 2021 · 1 comment
Open
2 tasks

Comments

@marc0olo
Copy link
Member

marc0olo commented Jul 6, 2021

I was thinking about how to improve pure SDK usage for contract calls and I think the JS-SDK is doing this quite will right now. it is converting the Sophia types.

Example calls that should be possible using the SDK:

  • deploy(txOptions: ContractTxOptions)
  • call(contractId: String, entrypoint: String, txOptions: ContractTxOptions) (for stateful and payable calls)
  • callReadOnly(contractId: String, entrypoint: String) (for read-only dry-run calls)

I see following tasks in this issue:

  • use the new convenience methods in the SDK
  • use SophiaType classes of the SDK wherever it's possible and makes sense
@marc0olo
Copy link
Member Author

marc0olo commented Jan 3, 2022

I started type integration in the sdk with kryptokrauts/aepp-sdk-java#211

there are now convenience methods in the SDK for contract creation and regular stateful calls where a ContractTxOptions object can be passed to that can contain different params.

for read-only (dry-run) calls there is also a specific convenience method in the SDK now where we don't need any additional params as we always use the zero-address in those read-only dry-runs.

@marc0olo marc0olo changed the title consider outsourcing default Sophia types & type-conversion refactor contract calls: convenience methods in SDK and SophiaTypes in SDK Jan 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants