feat(ts-bindings)!: now powered by ContractClient #1258
Conversation
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/@stellar/freighter-api@1.7.1, npm/@stellar/stellar-sdk@11.2.0, npm/@stellar/stellar-sdk@11.2.2, npm/@types/node@20.10.4, npm/@typescript-eslint/eslint-plugin@6.14.0, npm/@typescript-eslint/parser@6.14.0, npm/dotenv@16.3.1, npm/eslint@8.55.0 |
Most logic in the TS Bindings has now been implemented in stellar-sdk as a `ContractClient` that dynamically fetches the contract's XDR and generates JS for each contract method at runtime. This means logic like `AssembledTransaction` now lives entirely in stellar-sdk, and can be relied on by each library generated by TS Bindings, rather than duplicating this logic in each of these libraries. TS Bindings now has a much smaller focus—basically, only to generate the types. This shrinks the TS Bindings, importing and using this new ContractClient logic.
All tests that are being removed are now duplicates of tests that are in stellar-sdk. So are the test-custom-types tests, but those ones actually caught some edge cases, so maybe they're worth keeping.
chadoh
force-pushed
the
feat/ts-bindings-minimization
branch
from
0688a7e
to
5161053
Compare
|
@leighmcculloch The current failing action here doesn't seem to provide any info on the error, just that there was one. |
…ate.rs Co-authored-by: Willem Wyndham <willem@ahalabs.dev>
Other than the two you commented on, which have now been removed, I don't see any other new |
|
@leighmcculloch when I run the failing build's command locally, I get this output. No idea what to do with this information. |
chadoh
force-pushed
the
feat/ts-bindings-minimization
branch
from
9a516c2
to
43e38e5
Compare
The history of this build is we added it in some lower level repos that had complex workspace setups (e.g. env and sdk) and we kept breaking rust-analyzer which was destroying our IDE productivity. Things have changed, the sdk repo is not as complex as it was, the env still is. But in any case none of the problems we had would ever happen in this repo.
👋🏻 Couple questions about this change: Does this mean that use of the bindings always downloads the contract spec in the user browser? Or is the contract spec embedded and the type generation is just dynamic? Is this change a breaking change? Does the interface change that a developer interacts with? Saw one crew running into issues after updating to v20.3.4 saying that the interface was radically different. |
|
After upgraded to the latest version of ts-bindings generated by soroban-cli 20.3.4, the signAndSend function always returns txTooLate error. The previous ts-bindings version works fine. (I'm interacting with the example increment contract deployed to testnet). @chadoh Could you please take a look? Thanks. Here is the demo repo: https://github.com/shan-57blocks/soroban-ts-bindings-playground Here is the error message: |
The contract spec and the types are fetched at build time only. If you inspect a generated library, it now looks like this (using the export interface Client {
/**
* Construct and simulate a hello transaction. Returns an `AssembledTransaction` object which will have a `result` field containing the result of the simulation. If this transaction changes contract state, you will need to call `signAndSend()` on the returned object.
*/
hello: ({to}: {to: string}, options?: {
/**
* The fee to pay for the transaction. Default: BASE_FEE
*/
fee?: number;
/**
* The maximum amount of time to wait for the transaction to complete. Default: DEFAULT_TIMEOUT
*/
timeoutInSeconds?: number;
/**
* Whether to automatically simulate the transaction when constructing the AssembledTransaction. Default: true
*/
simulate?: boolean;
}) => Promise<AssembledTransaction<Array<string>>>
}
export class Client extends ContractClient {
constructor(public readonly options: ContractClientOptions) {
super(
new ContractSpec([ "AAAAAAAAAAAAAAAFaGVsbG8AAAAAAAABAAAAAAAAAAJ0bwAAAAAAEQAAAAEAAAPqAAAAEQ==" ]),
options
)
}
public readonly fromJSON = {
hello: this.txFromJSON<Array<string>>
}
}
Yes, it is a breaking change! And we didn't do enough testing on it, tbh 😞 Some fixes are rolling in, for
The updates to
I'm sorry you're running into this, @shan-57blocks. I'm not yet sure why the default timeout of 10 seconds wouldn't be enough for this; maybe the logic is off and the actual timeout is less than 10. I should have an answer on this later today. For now, you can try increasing the timeout. But! There's a bug in how you do this. This will fix part of the bug, once it's released and the CLI is updated to use it: But for now, to increase the timeout, you can try this: // @ts-ignore types generated in library do not match interface created in stellar-sdk!
const tx = await client.increment(undefined, { timeoutInSeconds: 30 })Without the |
|
@chadoh Just tested it with the below code and it worked: Looking forward to the new release. |
What
Most logic in the TS Bindings has now been implemented in stellar-sdk as
a
ContractClientthat dynamically fetches the contract's XDR andgenerates JS for each contract method at runtime. This means logic like
AssembledTransactionnow lives entirely in stellar-sdk, and can berelied on by each library generated by TS Bindings, rather than
duplicating this logic in each of these libraries. TS Bindings now has a
much smaller focus—basically, only to generate the types.
This shrinks the TS Bindings, importing and using this new
ContractClient logic.
Why
Simplicity, code cleanliness, keeping JS in a JS library, making
dependencies easior to troubleshoot and improve
Known limitations
[TODO or N/A]