search

ton-connect / sdk

SDK for TON Connect 2.0 — a comprehensive communication protocol between wallets and apps in TON ecosystem
Apache License 2.0
330 stars 98 forks source link

Allow passing in manifest data directly #14

Closed shaharyakir closed 1 year ago

shaharyakir commented 1 year ago

Context

Currently, user has to provide a URL which contains the manifest. This creates friction and slows down development cycles, leading to weird workaround such as reusing an already existing manifest etc.

Suggestion

  1. Allow url, iconUrl to be optional (currently the work with empty strings but we can make it more explicity)
  2. Allow passing in metadata props to the bridge directly (in addition to the URL as being done today)

I'd suggest showing a warning if data was passed directly, but since there's no verification being done (i.e. you could pass in any existing manifest belonging to a different app) at the moment I'm not sure that's required.

inartin commented 1 year ago

Good idea. Providing a URL to the manifest even leads to new issues as described in this thread https://github.com/ton-connect/sdk/issues/12 This can be avoided by simplifying the configuration as you described.

k6c8e4 commented 1 year ago

@shaharyakir yes, agree @siandreev it will also solve this step aswell https://github.com/ton-connect/sdk/issues/12

Thank you for well argument @shaharyakir

siandreev commented 1 year ago

Hi @shaharyakir , could you provide more details on the frictions you are facing?

For local development you can place the manifest on the local server and run you app on LAN. (for instance, if you use Vite, run a webserver with the --host option vite --host)

inartin commented 1 year ago

IMO by frictions OP means the general use of the SDK, to be as simple as possible and "friendly"

Take for example web3.js or etherjs, you just set one or two parameters and you are ready to go without the need to host a separate JSON file somewhere. This additional step here can lead to additional mistakes during the development, for example, the use case that we mentioned in #12 where it is a completely different environment and a simple change in the JSON means needing to reupload the file...

siandreev commented 1 year ago

@inartin I agree with you that SDK should be simple. Mentioned libraries do not provide a connection to the wallet, and you do not need to change your manifest, you should upload it once. For me it seems like describing the manifest in json file, or TonConnect constructor are the same. However, there is an important advantage of the json manifest file -- wallets can show a dApp meta information even if the dApp is not connected yet

shaharyakir commented 1 year ago

I agree that the JSON file has an advantage, but I'm not suggesting to replace it, only to provide an option to pass information through the constructor (or even omit metadata altogether) for prototyping purposes.

@siandreev I think that even vite --host creates friction we can avoid. It'd just be a better DX without mandating it.

See for example Step 4 in this tutorial -> https://ton-community.github.io/tutorials/03-client/ where we provide a temporary published manifest. Ideally, I'd like to be able to avoid that and add the manifest later.