v0.4 > v0.5 migration guide
This section contains migration guide for SDK v0.4.* -> v0.5.*
Introduction
In the SDK v0.5
release, we introduce some breaking changes. You can find the full list of the release changes in the CHANGELOG.md
file, but in this docs section, we will be focused on some real code snippet migration from the SDK v0.4
to v0.5
Let's migrate the v0.4
jetton to TON swap example code to the v0.5
:
Contracts export change
The first thing you will face after the SDK update is that Module '"@ston-fi/sdk"' has no exported member Router
.
This is because contracts (such as Router
, Pool
, LpAccount
, etc) now no longer exported by their names. We start to use the export of domain related objects that will contain all the contracts.
At the current state SDK exports 3 domain object DEX
, FARM
, pTON
.
So the first required change to our code is to replace the import of Router
contract with the DEX
object.
Contract revision drop
Because multiple versions of the contracts appeared with uncomparable interfaces, we were forced to drop the architecture with revisions and the root class that obtained multiple revisions.
before:
after:
If you use extends or overrides contract revisions from the SDK anywhere in your code, you will now need to override the contract class instead.
If you use the override of the revision to define custom gas constants, it's now possible to pass gas constants as constructor parameters.
Contract version
Since we dropped revisions but still need to be able to separate different contracts, every contract now provides the statice field version
. And to math this, *_REVISION
enums was renamed to *_VERSION
.
Now you can use it like this:
*_VERSION
enum values is in lover case (v1
) to match the STON.fi API responses
Back to our code - you can just remove import and usage of the ROUTER_REVISION
completely and instead, to determine witch version of the DEX contract you would like to use, use version key of the domain object (DEX
in this case)
Contract address constant drop
For contracts with known addresses (for example, a router), the address is available as a static field on the class and is no longer required to be specified in the constructor.
The following changes need to be made on this step
Contract constructor parameters
All contract constructors now require 1 object with tonApiClient
field to be passed. tonApiClient
is a name for what in TonWeb is named provider
.
Optionally, you can pass an instance of stonApiClient
. This is a class from @ston-fi/api
package. If it is passed, STON.fi public REST API will be used to fetch data instead of using direct on-chain methods called via TON API.
At the current state of the package development, this client is optional, but we expect it to be required in the future when it no longer is possible to get some data required for the SDK to work from on-chain and
Contracts method renaming
In v0.5
, some of the contract methods were renamed:
|
|
|
|
|
|
|
|
Our code snippet using renamed fn buildSwapJettonTxParams
that was split in two: buildSwapJettonToJettonTxParams
& buildSwapJettonToTonTxParams
. Since we are swapping a jetton to TON, we will use a new fn buildSwapJettonToTonTxParams
buildSwapJettonToTonTxParams
fn now explicitly requires us to pass the address of the pTON contract to be used in the swap. Previously, it required the same, but under the askJettonAddress
name, that was confusing.
pTON contract
Because pTON class is now exported from the SDK we can use address from the pTON contract instead of a hardcoded string value in our code
Conclusion
And in the end this is a code we have migrated to
Last updated