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

optional simulate & wallet, editable TransactionBuilder #921

Merged
merged 37 commits into from Mar 12, 2024

Conversation

chadoh
Copy link
Contributor

@chadoh chadoh commented Feb 7, 2024

  • Remove TimeoutInfinite, instead allowing people to set a timeoutInSeconds when they initialize an AssembledTransaction. Default: 10.

  • No more wallet parameter. Instead, you pass:

    • publicKey – Will be used to construct the Account object that is used as the source of the transaction. Can be undefined, which means the null account will be used. Can be a string or, to ease operation with Freighter and other async-key-lookup in browser wallets, a promise of a string.

    • signTransaction: matches the signTransaction signature from Freighter. Can be left blank when you initialize the ContractClient and only provided at the time that you call signAndSend({ signTransaction: (...) => { ... } })

    • signAuthEntry: matches the signAuthEntry signature from Freighter. Can also be left initially blank, but is needed if/when you call signAuthEntries.

  • You can now pass simulate: false when first creating your transaction to skip simulation. You can then modify the transaction using the TransactionBuilder at tx.raw before manually calling simulate. Example:

    const tx = await myContract.myMethod(
      { args: 'for', my: 'method', ... },
      { simulate: false }
    );
    tx.raw.addMemo(Memo.text('Nice memo, friend!'))
    await tx.simulate();
    
  • Make .simulation getter public

  • Error types are now collected under AssembledTransaction.Errors and
    SentTransaction.Errors.

  • Move ContractClient, AssembledTransaction to separate entrypoints, so that they are not included in the global API or bundle size, but can still be packaged together with all the related stellar-sdk logic.

  • Export ExampleNodeWallet from its own entrypoint, rather than hiding this logic entirely in the tests. @kalepail found this useful enough that he thought it would be worth exporting so other people can use it in their Node apps.

Shaptic and others added 9 commits January 9, 2024 12:12
* Fixup deprecation to specify exact version
* Upgrade references to use latest modules
Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.3 to 1.15.4.
- [Release notes](https://github.com/follow-redirects/follow-redirects/releases)
- [Commits](follow-redirects/follow-redirects@v1.15.3...v1.15.4)

---
updated-dependencies:
- dependency-name: follow-redirects
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Add checks to ensure incorrect fields don't sneak in
* Upgrade all dependencies besides chai
* Add changelog entries
Eliminated the 'utility-types' package since its functionalities are likely
replaced by native TypeScript features. This change includes cleaning up imports
and references in the codebase and updating the package.json and yarn.lock
accordingly, resulting in a leaner dependency graph and potentially reducing
installation times and package size.

Co-authored-by: Sérgio Luis <sergiocl@airtm.io>
* Upgrade dependencies and stellar-base
- Can now pass an `account` OR `wallet` when constructing the
  ContractClient, or none! If you pass none, you can still make view
  calls, since they don't need a signer. You will need to pass a
  `wallet` when calling things that need it, like `signAndSend`.

- You can now pass `simulate: false` when first creating your
  transaction to skip simulation. You can then modify the transaction
  using the TransactionBuilder at `tx.raw` before manually calling
  `simulate`. Example:

      const tx = await myContract.myMethod(
        { args: 'for', my: 'method', ... },
        { simulate: false }
      );
      tx.raw.addMemo(Memo.text('Nice memo, friend!'))
      await tx.simulate();

- Error types are now collected under `AssembledTransaction.Errors` and
  `SentTransaction.Errors`.
src/soroban/contract_client.ts Outdated Show resolved Hide resolved
src/soroban/contract_client.ts Outdated Show resolved Hide resolved
/**
* The maximum amount of time to wait for the transaction to complete. Default: {@link DEFAULT_TIMEOUT}
*/
timeoutInSeconds?: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To move the discussion from here over:

Do you think this is important enough to bring to people's attention that we should uglify every method call in this way, or do you think there's a good-enough default?

Honestly? Yes. I'm open to opinions from users but from a security standpoint, this should be an explicit choice every time. Also from a consistency standpoint, you have to call setTimebounds/setTimeout on your TransactionBuilder no matter what and intentionally opt-in to TimeoutInfinite if you decide to make that (bad) choice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to make sure we're on the same page—this change removes the TimeoutInfinite default. People would need to opt into that. The default is now ten seconds.

If you already understood that, sorry for over-explaining. If that's new information, does it change your opinion?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh thanks for clarifying - I guess I missed that. I don't think there should be any default at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a huge change from current TS Bindings behavior and I'd like to hold off on it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

works for me 👍 then a non-inf default is better

src/soroban/assembled_transaction.ts Outdated Show resolved Hide resolved
src/soroban/assembled_transaction.ts Show resolved Hide resolved
Shaptic and others added 4 commits February 12, 2024 11:42
* Add README entry about React-Native compiler requirements
* Fixup the jsdoc for an entry
* Upgrade stellar-base
* Update all dependencies to their latest compatible versions
Tyler van der Hoeven thought this would be useful.

The current place it's exported from is surpassingly silly. But it
functions properly and the tests fail the same way they failed before.
Copy link

socket-security bot commented Feb 22, 2024

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert Package NoteSource
Non OSI license npm/caniuse-lite@1.0.30001587
  • License: CC-BY-4.0

View full report↗︎

Next steps

What is a non OSI license?

(Experimental) Package has a non-OSI-approved license.

Consider the terms of the license for your given use case.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/foo@1.0.0 or ignore all packages with @SocketSecurity ignore-all

  • @SocketSecurity ignore npm/caniuse-lite@1.0.30001587

@chadoh chadoh force-pushed the feat/more-better branch 6 times, most recently from 4959e4d to f757433 Compare February 27, 2024 20:34
- New `clientFor` that instantiates a ContractClient for given
  contract, as well as initializes a new account, funding it with
  friendbot
- Can also use `generateFundedKeypair` directly, as with test-swap
- Stop generating anything in initialize.sh. Just check that the network
  is running and the pinned binary is installed, and fund the
  `$SOROBAN_ACCOUNT`.

  Ideally we wouldn't use the binary at all, but for now the tests are
  still shelling out to the CLI, so it's worth keeping the pinning
  around
Instead, just accept the things that Wallet contained.

This avoids the conundrum of what to call the thing.

- `Wallet` seems too high-level. Too high-level to be the concern of
  stellar-sdk, and too high-level for the thing being described here.
  It's really just two functions: `signTransaction` and `signAuthEntry`.
- No need for this thing to defined `getPublicKey`, let alone any of the
  more complicated wrappers around it that it used to. Just have people
  pass in a `publicKey`. For convenience' sake, I also allowed this to
  be a Promise of a string, so that you don't need to instantiate
  ContractClient asynchronously, instead doing something like:

      new ContractClient({
        publicKey: asyncPublicKeyLookupFromWallet(),
        ...
      })

  This helps when getting public keys in a browser environment, where
  public key lookup is async, and adds little complexity to the logic
  here.
@chadoh
Copy link
Contributor Author

chadoh commented Mar 5, 2024

@Shaptic I still don't have write access to this repository—could you merge if you approve? @kalepail you might also be able to merge?

@kalepail
Copy link
Contributor

kalepail commented Mar 5, 2024

I don't feel comfortable merging as I'm not reviewing code as much as functionality. I'll leave that for @Shaptic

* master:
  Drop all usage of array-based passing (stellar#924)
  Release v11.2.2 (stellar#918)
  Ensure that event streaming tests write a valid stream (stellar#917)
  Release v11.2.1 (stellar#913)
  Eliminating `utility-types` dependency entirely (stellar#912)
  Prepare v11.2.0 for release (stellar#908)
  Update README to flow better (stellar#907)
  Add support for new `sendTransaction` response field (stellar#905)
  Export the individual event response instance (stellar#904)
  Bump follow-redirects from 1.15.3 to 1.15.4 (stellar#906)
  Update examples to use new module and package structure. (stellar#900)
No need to pollute the global API or bundle size with this.
Copy link

socket-security bot commented Mar 5, 2024

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package New capabilities Transitives Size Publisher
npm/@babel/cli@7.23.9 Transitive: environment, eval, filesystem, network, shell, unsafe +85 12.5 MB nicolo-ribaudo
npm/@babel/core@7.23.9 environment, filesystem, unsafe Transitive: shell +52 10.8 MB nicolo-ribaudo
npm/@babel/eslint-parser@7.23.10 unsafe Transitive: environment, eval, filesystem, shell +147 21.7 MB nicolo-ribaudo
npm/@babel/helper-create-class-features-plugin@7.23.10 Transitive: environment, filesystem, shell, unsafe +58 11.2 MB nicolo-ribaudo
npm/@babel/parser@7.23.9 None 0 1.88 MB nicolo-ribaudo
npm/@babel/preset-env@7.23.9 environment Transitive: filesystem, shell, unsafe +161 15.3 MB nicolo-ribaudo
npm/@babel/template@7.23.9 Transitive: environment +15 4.59 MB nicolo-ribaudo
npm/@babel/types@7.23.9 environment +3 2.49 MB nicolo-ribaudo
npm/@definitelytyped/dtslint@0.1.5 environment, filesystem Transitive: eval, network, shell, unsafe +320 449 MB definitelytyped-publisher
npm/@jridgewell/trace-mapping@0.3.22 None +2 265 kB jridgewell
npm/@stellar/stellar-base@11.0.0 Transitive: environment, filesystem +12 9.3 MB stellar-npm-ci
npm/@types/eslint@8.56.2 None +2 243 kB types
npm/@types/node@20.11.17 None +1 4.07 MB types
npm/@typescript-eslint/parser@6.21.0 Transitive: environment, eval, filesystem, shell, unsafe +114 13.7 MB jameshenry
npm/@typescript-eslint/types@6.21.0 None 0 156 kB jameshenry
npm/@typescript-eslint/typescript-estree@6.21.0 Transitive: environment, filesystem +33 2.67 MB jameshenry
npm/@typescript-eslint/utils@6.21.0 Transitive: environment, eval, filesystem, shell, unsafe +116 14.1 MB jameshenry
npm/array-buffer-byte-length@1.0.1 Transitive: eval +12 245 kB ljharb
npm/available-typed-arrays@1.0.6 None 0 20.4 kB ljharb
npm/axios@1.6.7 network Transitive: environment, filesystem +8 2.21 MB jasonsaayman
npm/browserslist@4.22.3 environment, filesystem Transitive: shell +6 2.37 MB ai
npm/call-bind@1.0.6 Transitive: eval +10 214 kB ljharb
npm/chai@4.4.1 None +7 923 kB keithamus
npm/chokidar@3.6.0 environment, filesystem +14 531 kB paulmillr
npm/core-js-compat@3.35.1 Transitive: environment, filesystem, shell +7 3.06 MB zloirock
npm/define-data-property@1.1.3 Transitive: eval +8 173 kB ljharb
npm/es-errors@1.3.0 None 0 12.3 kB ljharb
npm/follow-redirects@1.15.5 network 0 29.4 kB rubenverborgh
npm/get-intrinsic@1.2.4 eval +5 124 kB ljharb
npm/has-tostringtag@1.0.2 None +1 38.2 kB ljharb
npm/ignore@5.3.1 None 0 51.5 kB kael
npm/is-array-buffer@3.0.4 Transitive: eval +11 232 kB ljharb
npm/is-typed-array@1.1.13 Transitive: eval +16 359 kB ljharb
npm/json-schema-faker@0.5.5 environment Transitive: eval, filesystem, network, unsafe +9 4.44 MB pateketrueke
npm/karma-webpack@5.0.1 filesystem Transitive: environment, eval, network, shell, unsafe +90 21.5 MB evilebottnawi
npm/lint-staged@15.2.2 Transitive: environment, filesystem, shell +53 2.47 MB okonet
npm/mocha@10.3.0 environment, eval, filesystem +62 4.29 MB joshuakgoldberg
npm/prettier@3.2.5 environment, filesystem, unsafe 0 8.39 MB prettier-bot
npm/webpack@5.90.1 environment, filesystem, network, unsafe Transitive: eval, shell +76 19.5 MB evilebottnawi
npm/which-typed-array@1.1.14 Transitive: eval +15 336 kB ljharb

🚮 Removed packages: npm/@babel/cli@7.23.4, npm/@babel/core@7.23.7, npm/@babel/eslint-parser@7.23.3, npm/@babel/helper-create-class-features-plugin@7.23.7, npm/@babel/parser@7.23.6, npm/@babel/preset-env@7.23.8, npm/@babel/types@7.23.6, npm/@definitelytyped/dtslint@0.1.2, npm/@jridgewell/trace-mapping@0.3.20, npm/@stellar/stellar-base@10.0.1, npm/@types/eslint@8.56.1, npm/@types/node@20.10.8, npm/@typescript-eslint/parser@6.18.1, npm/@typescript-eslint/types@6.18.1, npm/@typescript-eslint/typescript-estree@6.18.1, npm/@typescript-eslint/utils@6.18.1, npm/axios@1.6.5, npm/browserslist@4.22.2, npm/call-bind@1.0.5, npm/chai@4.4.0, npm/core-js-compat@3.35.0, npm/define-data-property@1.1.1, npm/follow-redirects@1.15.4, npm/get-intrinsic@1.2.2, npm/ignore@5.3.0, npm/is-array-buffer@3.0.2, npm/is-typed-array@1.1.12, npm/json-schema-faker@0.5.4, npm/karma-webpack@5.0.0, npm/lint-staged@15.2.0, npm/mocha@10.2.0, npm/prettier@3.1.1, npm/utility-types@3.10.0, npm/webpack@5.89.0, npm/which-typed-array@1.1.13

View full report↗︎

These are a bit higher-level and experimental, at this point, so let's
not clutter the global API or the bundle size unless people really want
it.
src/contract_client.ts Outdated Show resolved Hide resolved
src/contract_client.ts Outdated Show resolved Hide resolved
src/contract_client.ts Outdated Show resolved Hide resolved
src/contract_client.ts Outdated Show resolved Hide resolved
src/example_node_wallet.ts Outdated Show resolved Hide resolved
src/example_node_wallet.ts Outdated Show resolved Hide resolved
@Shaptic
Copy link
Contributor

Shaptic commented Mar 6, 2024

@chadoh lmk if you'd rather I merge this and you resolve feedback in a later PR! doesn't matter to me

@chadoh
Copy link
Contributor Author

chadoh commented Mar 6, 2024

@Shaptic ok, I addressed all your feedback here. I think this is ready to merge to bindings. I'll then open a PR from bindings back to master—I think it's probably good enough to get it merged! I really want to remove the stale logic that's hard-coded into TS Bindings and rely on this instead.

Copy link
Contributor

@Shaptic Shaptic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is turning into a really strong set of tools! Thanks for bearing with all of the back-and-forth on the design 👏

@chadoh
Copy link
Contributor Author

chadoh commented Mar 7, 2024

Thanks, @Shaptic! You'll have to merge, as I do not have permission.

I personally find TS enums a little surprising to work with, and my own
codebases already have network passphrases littered throughout. I think
we can upgrade to use the enum later, after more discussion about the
exact interface. Let's not tangle that up in this change.
the README.md file is not included in the `lib/rust_types` built
version, so it's better to include it in a file that people can find by
using the go-to-definition function in their editor, such as a
`rust_types.ts` file directly, which gets built as
`lib/rust_types.d.ts`.
Our suggested approach of spreading `signer` into `ContractClient`
constructors causes typing issues, since `networkPassphrase` is a
private field inside BasicNodeSigner. This means the `signer` needs to
be spread in before the inclusion of `networkPassphrase`, otherwise it
gets overwritten with `undefined` (or maybe TypeScript just thinks it
will get overwritten).
@Shaptic Shaptic merged commit bdf7495 into stellar:bindings Mar 12, 2024
7 checks passed
@chadoh chadoh deleted the feat/more-better branch March 12, 2024 19:54
Shaptic added a commit that referenced this pull request Mar 20, 2024
* Add generation of contract clients and an `AssembledTransaction` abstraction (#891)
- new e2e tests copied from cli `ts-tests` for the generated bindings, but
  with TypeScript removed because the ContractClient is generated here
  dynamically at run time, so we cannot know the types at compile time in
  the tests.
- generate JSON specs from local .wasm files during initiaze.sh instead
  of generating TS bindings. As explained in the new wasms/specs/README,
  this is a bummer, but is temporary
* Update soroban-cli and sync with upstream `master` (#911)

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: George <Shaptic@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Make simulation optional, simplify wallet/signer interface (#921)

* Update examples to use new module and package structure. (#900)

* Fixup deprecation to specify exact version
* Upgrade references to use latest modules

* Bump follow-redirects from 1.15.3 to 1.15.4 (#906)

Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.3 to 1.15.4.
- [Release notes](https://github.com/follow-redirects/follow-redirects/releases)
- [Commits](follow-redirects/follow-redirects@v1.15.3...v1.15.4)

---
updated-dependencies:
- dependency-name: follow-redirects
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Export the individual event response instance (#904)

* Add support for new `sendTransaction` response field (#905)

* Add checks to ensure incorrect fields don't sneak in

* Update README to flow better (#907)

* Prepare v11.2.0 for release (#908)

* Upgrade all dependencies besides chai
* Add changelog entries

* Eliminating `utility-types` dependency entirely (#912)

Eliminated the 'utility-types' package since its functionalities are likely
replaced by native TypeScript features. This change includes cleaning up imports
and references in the codebase and updating the package.json and yarn.lock
accordingly, resulting in a leaner dependency graph and potentially reducing
installation times and package size.

Co-authored-by: Sérgio Luis <sergiocl@airtm.io>

* Release v11.2.1 (#913)

* Upgrade dependencies and stellar-base

* fix: stop using TimeoutInfinite

* optional simulate & wallet, editable TransactionBuilder

- Can now pass an `account` OR `wallet` when constructing the
  ContractClient, or none! If you pass none, you can still make view
  calls, since they don't need a signer. You will need to pass a
  `wallet` when calling things that need it, like `signAndSend`.

- You can now pass `simulate: false` when first creating your
  transaction to skip simulation. You can then modify the transaction
  using the TransactionBuilder at `tx.raw` before manually calling
  `simulate`. Example:

      const tx = await myContract.myMethod(
        { args: 'for', my: 'method', ... },
        { simulate: false }
      );
      tx.raw.addMemo(Memo.text('Nice memo, friend!'))
      await tx.simulate();

- Error types are now collected under `AssembledTransaction.Errors` and
  `SentTransaction.Errors`.

* Ensure that event streaming tests write a valid stream (#917)
* Release v11.2.2 (#918)
* export ExampleNodeWallet from lib

Tyler van der Hoeven thought this would be useful.

The current place it's exported from is surpassingly silly. But it
functions properly and the tests fail the same way they failed before.

* Drop all usage of array-based passing (#924)

* feat(e2e-tests): new account & contract per test

- New `clientFor` that instantiates a ContractClient for given
  contract, as well as initializes a new account, funding it with
  friendbot
- Can also use `generateFundedKeypair` directly, as with test-swap
- Stop generating anything in initialize.sh. Just check that the network
  is running and the pinned binary is installed, and fund the
  `$SOROBAN_ACCOUNT`.

  Ideally we wouldn't use the binary at all, but for now the tests are
  still shelling out to the CLI, so it's worth keeping the pinning
  around

* wallet/signer only needs three methods

* feat: no more `Wallet` interface

Instead, just accept the things that Wallet contained.

This avoids the conundrum of what to call the thing.

- `Wallet` seems too high-level. Too high-level to be the concern of
  stellar-sdk, and too high-level for the thing being described here.
  It's really just two functions: `signTransaction` and `signAuthEntry`.
- No need for this thing to defined `getPublicKey`, let alone any of the
  more complicated wrappers around it that it used to. Just have people
  pass in a `publicKey`. For convenience' sake, I also allowed this to
  be a Promise of a string, so that you don't need to instantiate
  ContractClient asynchronously, instead doing something like:

      new ContractClient({
        publicKey: asyncPublicKeyLookupFromWallet(),
        ...
      })

  This helps when getting public keys in a browser environment, where
  public key lookup is async, and adds little complexity to the logic
  here.

* rm getAccount from exposed interface

* make simulation public; wrap comments

* explicit allowHttp

* test(ava): set timeout to 2m

* build: move ExampleNodeWallet to own entrypoint

No need to pollute the global API or bundle size with this.

* build: move ContractClient & AssembledTransaction

These are a bit higher-level and experimental, at this point, so let's
not clutter the global API or the bundle size unless people really want
it.

* fix: allow overriding 'publicKey' for 'signAuthEntries'

* feat(contract-client): require publicKey

* fix: use Networks from stellar-base

* doc: explain 'errorTypes' param

* build: ContractClient-related things in one dir

* typo

* move primitive type defs to contractclient

* rm ContractClient.generate; do it in constructor

* feat: separate rust_types to own import path

* feat: don't make people import and use Networks enum

I personally find TS enums a little surprising to work with, and my own
codebases already have network passphrases littered throughout. I think
we can upgrade to use the enum later, after more discussion about the
exact interface. Let's not tangle that up in this change.

* doc: include rust_types readme info in build

the README.md file is not included in the `lib/rust_types` built
version, so it's better to include it in a file that people can find by
using the go-to-definition function in their editor, such as a
`rust_types.ts` file directly, which gets built as
`lib/rust_types.d.ts`.

* build: make it easier to import rust_types

* feat: basicNodeSigner as a plain-object factory

Our suggested approach of spreading `signer` into `ContractClient`
constructors causes typing issues, since `networkPassphrase` is a
private field inside BasicNodeSigner. This means the `signer` needs to
be spread in before the inclusion of `networkPassphrase`, otherwise it
gets overwritten with `undefined` (or maybe TypeScript just thinks it
will get overwritten).

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: George <Shaptic@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Sérgio Luis <sergiolclem@gmail.com>
Co-authored-by: Sérgio Luis <sergiocl@airtm.io>

* fix(contract-client): stop jsifying method names

This implementation needs to match what is done in the TS Bindings in
Rust. Keeping "JSification" logic consistent in both is not worth the
slight nicety of allowing people to type camelCaseMethodNames in JS.

Additionally, having camelCaseMethodNames in one context when the real
method name is probably_snake_case could lead to confusion. If someone
types a camelCaseName in their CLI, the CLI will complain, and they
might not know what's going on.

* docs(contract-client): clean api, write a book

Yes, a whole book about AssembledTransaction. It needed documentation;
why not make it useful.

This also removes an obsolute method, marks a couple as private,
adds detail to other comments, fixes the `fee` type, updates
SentTransaction docs, and organizes the code a bit.

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: George <Shaptic@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Sérgio Luis <sergiolclem@gmail.com>
Co-authored-by: Sérgio Luis <sergiocl@airtm.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants