#More flexibility to soroban contract bindings

11 messages · Page 1 of 1 (latest)

languid frigate
#

I Soroban contract bidings are great! However I would like to see more flexbility.
I didn't know if to post this here or in Github... well...

After changing from @soroban-react to the soroban contract binding, there are less flexibility in the soroban-example-dapp.

Specifically:

  • The generated libs are fixed to an specific network
  • Fixed with an specific contract id
  • Are fixed with an specific wallet (Freigher)

What if we give some flexibility, there we could generate "general" contract bindings that will work:

  • regardless on where the contract has been deployed,
  • regardless on the wallet that will be used
  • regardless on the network that has been deployed

I want to use multichain dapps. This is the same contract that has been deployed in more than one chain (mainnet, testnet), without needing to bind twice, managing twice the amount of typescript packages.

And of course, I want to give the user the ability to choose the wallet

As a supporter of the @soroban-react library I would like to use the power of contract bindings at the same time of the ability of the React dapp to follow the user change of wallet, change of address and change of network

What do you think @brittle imp @hushed yew @wanton folio ?

Maybe we can still set a default network and default contract id
But I want to have the possibility to do crowdfundContract.deadline(network, contractid)

And instead of

await deposit({
        user: props.account,
        amount: BigInt(amount * 10**decimals),
      }

I want to have the possibility to do:

await deposit(
              userWalletSignMessageFunction,
              userNetwork,
              contractId
{
        user: props.account,
        amount: BigInt(amount * 10**decimals),
      }
weary flax
#

NETWORK_PASSPHRASE could be initialized from an rpc.getNetwork() call at least (except it's a best practice to hard code the network 🤔 )

brittle imp
#

Yes, this is definitely on the roadmap. For the sake of having a minimal-viable API on the initial release, I pushed for keeping it pretty rigid in this version. Something I really like about the current version is that you can import { balance } from 'ft-contract', rather than something like ```ts
import { Contract } from 'ft-contract'
const contract = new Contract({ rpc: '…', passphrase: '…' })
const { balance } = contract

Or something like instantiating `contract` at the time of call, based on the currently selected network in the user's browser.
#

We 100% need the ability to customize which network & contract ID, and 100% need to be able to work with any wallet. I just want a minimal starting version and then some good discussion around the API we choose for making it more flexible.

#

follow the user change of wallet, change of address and change of network
imo, Freighter and other wallets need to make it easier to subscribe to changes to these things, which could work with both React and other frontend solutions. soroban-react shouldn't have needed sophisticated logic for this. See https://github.com/stellar/freighter/issues/846

GitHub
Need a way to subscribe to network & account changes · Issue #846 ·...

What problem does your feature solve? Right now, in order to have an app respond to a user's network & account changes in Freighter, an app needs to poll Freighter every X seconds. Example ...

#

I purposely rolled back logic around this in the dapp example when I switched it to the generated JS libs approach, because I want to wait until there's a "correct" way to do it (that is, the way we bake into Freighter), rather than having a half-measure get duplicated & modified over & over throughout the nascent ecosystem.

# 
              userWalletSignMessageFunction,
              userNetwork,
              contractId
{
        user: props.account,
        amount: BigInt(amount * 10**decimals),
      }```
I was thinking something more like what I showed above, `const contract = new Contract({ id: '…', rpc: '…', passphrase: '…', wallet: SomeWalletClass }`, but I agree it would be nice to have it be overridable on a per-function basis. I was thinking we could add these networking options in the options object that is currently the second argument to the exported functions (first & only, for methods which take no arguments):

```ts
await deposit({ user, amount }, { responseType: 'full', rpc: '…', passphrase: '…', … })```
#

Maybe the best way to approach this design discussion would be to make a Google Doc proposal and get some feedback from everyone?

languid frigate
languid frigate
languid frigate