v0.4 a v0.5

Guía de migración del SDK v0.4 a v0.5: actualiza tu integración con cambios incompatibles

Introducción

En el SDK v0.5 lanzamiento, introducimos algunos cambios incompatibles. Puedes encontrar la lista completa de los cambios del lanzamiento en el CHANGELOG.md archivo, pero en esta sección de la documentación nos centraremos en la migración de algunos fragmentos de código reales desde el SDK v0.4 to v0.5

Vamos a migrar el v0.4 código de ejemplo de intercambio de jetton a TON al v0.5:

import TonWeb from 'tonweb';
import { Router, ROUTER_REVISION, ROUTER_REVISION_ADDRESS } from '@ston-fi/sdk';

const WALLET_ADDRESS = ''; // ¡ reemplaza con tu dirección
const JETTON0 = 'EQA2kCVNwVsil2EM2mB0SkXytxCqQjS4mttjDpnXmwG9T6bO'; // STON
const PROXY_TON = 'EQCM3B12QK1e4yZSf8GtBRT0aLMNyEsBc_DhVfRRtOEffLez'; // ProxyTON

const provider = new TonWeb.HttpProvider();

const router = new Router(provider, {
  revision: ROUTER_REVISION.V1,
  address: ROUTER_REVISION_ADDRESS.V1,
});

const tonToJettonTxParams = await router.buildSwapJettonTxParams({
  userWalletAddress: WALLET_ADDRESS,
  offerJettonAddress: JETTON0,
  offerAmount: new TonWeb.utils.BN('1000000000'),
  askJettonAddress: PROXY_TON,
  minAskAmount: new TonWeb.utils.BN('1'),
  queryId: 12345,
});

Cambio en la exportación de contratos

Lo primero que encontrarás después de la actualización del SDK es que el módulo '"@ston-fi/sdk"' no tiene un miembro exportado Enrutador.

Esto se debe a que los contratos (como Enrutador, Pool, LpAccount, etc.) ya no se exportan por sus nombres. Empezamos a usar la exportación de objetos relacionados con dominios que contendrán todos los contratos.

En el estado actual, el SDK exporta 3 objetos de dominio DEX, FARM, pTON.

Así que el primer cambio necesario en nuestro código es reemplazar la importación de Enrutador contrato con el DEX objeto.

- import { Router, ROUTER_REVISION, ROUTER_REVISION_ADDRESS } from '@ston-fi/sdk';

+ import { DEX, ROUTER_REVISION, ROUTER_REVISION_ADDRESS } from '@ston-fi/sdk';

Eliminación de revisiones de contratos

Debido a que aparecieron múltiples versiones de los contratos con interfaces no comparables, nos vimos obligados a eliminar la arquitectura con revisiones y la clase raíz que obtenía múltiples revisiones.

antes:

.
└── dex
    └── Router
        └── Router
            ├── RouterRevisionV1
            └── RouterRevisionV2

después:

.
└── dex
    └── Router
        ├── RouterV1
        └── RouterV2

Si usas extends o sobrescribes revisiones de contratos del SDK en cualquier parte de tu código, ahora necesitarás sobrescribir la clase del contrato en su lugar.

Si usas la sobrescritura de la revisión para definir constantes de gas personalizadas, ahora es posible pasar las constantes de gas como parámetros del constructor.

Versión del contrato

Como eliminamos las revisiones pero aún necesitamos poder separar distintos contratos, ahora cada contrato proporciona el campo estático versión actual. Y para coincidir con esto, *_REVISION los enums fueron renombrados a *_VERSION.

Ahora puedes usarlo así:

import { DEX, DEX_VERSION } from '@ston-fi/sdk';

DEX.v1.Router.version === DEX_VERSION.v1

*_VERSION los valores del enum están en minúsculas (v1) para coincidir con las respuestas de la API de STON.fi

Volviendo a nuestro código: puedes simplemente eliminar por completo la importación y el uso de ROUTER_REVISION y, en su lugar, para determinar qué versión del contrato DEX te gustaría usar, utiliza la clave version del objeto de dominio (DEX en este caso)

- import { DEX, ROUTER_REVISION, ROUTER_REVISION_ADDRESS } from '@ston-fi/sdk';

+ import { DEX, ROUTER_REVISION_ADDRESS } from '@ston-fi/sdk';

-  const router = new Router(provider, {
-   revision: ROUTER_REVISION.V1,
+  const router = new Dex.v1.Router(provider, {
    address: ROUTER_REVISION_ADDRESS.V1,
  });

Eliminación de la constante de dirección del contrato

Para los contratos con direcciones conocidas (por ejemplo, un router), la dirección está disponible como un campo estático en la clase y ya no es necesario especificarla en el constructor.

import { DEX, pTON } from '@ston-fi/sdk';

DEX.v1.Router.address; // EQB3ncyBUTjZUA5EnFKR5_EnOMI9V1tTEAAPaiU71gc4TiUt
pTON.v1.address; // EQCM3B12QK1e4yZSf8GtBRT0aLMNyEsBc_DhVfRRtOEffLez

Los siguientes cambios deben hacerse en este paso

- import { DEX, ROUTER_REVISION_ADDRESS } from '@ston-fi/sdk';
+ import { DEX } from '@ston-fi/sdk';

  const router = new Dex.v1.Router(provider, {
-  address: ROUTER_REVISION_ADDRESS.V1,
  });

Parámetros del constructor del contrato

Todos los constructores de contratos ahora requieren 1 objeto con tonApiClient campo que se debe pasar. tonApiClient es un nombre para lo que en TonWeb se llama provider.

-   const provider = new TonWeb.HttpProvider();

- const router = new Dex.v1.Router(provider, {
+ const router = new DEX.v1.Router({
+    tonApiClient: new TonWeb.HttpProvider(),
  });

Opcionalmente, puedes pasar una instancia de stonApiClient. Esta es una clase de @ston-fi/api paquete. Si se pasa, la API REST pública de STON.fi se usará para obtener datos en lugar de usar métodos directos en la cadena llamados a través de la API de TON.

En el estado actual del desarrollo del paquete, este cliente es opcional, pero esperamos que sea necesario en el futuro cuando ya no sea posible obtener algunos datos requeridos para que el SDK funcione desde la cadena y

Cambio de nombre de métodos de contratos

En v0.5se renombraron algunos de los métodos del contrato:

v0.4	v0.5
buildSwapJettonTxParams	buildSwapJettonToJettonTxParams & buildSwapJettonToTonTxParams
buildSwapProxyTonTxParams	buildSwapTonToJettonTxParams
buildProvideLiquidityProxyTonTxParams	buildProvideLiquidityTonTxParams

Nuestro fragmento de código usando la fn renombrada buildSwapJettonTxParams que se dividió en dos: buildSwapJettonToJettonTxParams & buildSwapJettonToTonTxParams. Como estamos intercambiando un jetton por TON, usaremos una nueva fn buildSwapJettonToTonTxParams

-   const tonToJettonTxParams = await router.buildSwapJettonTxParams({

+   const tonToJettonTxParams = await router.buildSwapJettonToTonTxParams({

buildSwapJettonToTonTxParams la fn ahora nos exige explícitamente pasar la dirección del contrato pTON que se usará en el intercambio. Anteriormente, requería lo mismo, pero bajo el nombre askJettonAddress , que era confuso.

-  askJettonAddress: PROXY_TON,

+  proxyTonAddress: PROXY_TON,

contrato pTON

Como la clase pTON ahora se exporta desde el SDK, podemos usar la dirección del contrato pTON en lugar de un valor de cadena codificado en nuestro código

- import { DEX } from '@ston-fi/sdk';
+ import { DEX, pTON } from '@ston-fi/sdk';

- const PROXY_TON = 'EQCM3B12QK1e4yZSf8GtBRT0aLMNyEsBc_DhVfRRtOEffLez'; // ProxyTON
+ const PROXY_TON = pTON.v1.address;

Conclusión

Y al final este es el código al que hemos migrado

import TonWeb from 'tonweb';
import { DEX, pTON } from '@ston-fi/sdk';

const router = new DEX.v1.Router({
  tonApiClient: new TonWeb.HttpProvider(),
});

const tonToJettonTxParams = await router.buildSwapJettonToTonTxParams({
  userWalletAddress: "", // ! reemplaza con tu dirección
  offerJettonAddress: 'EQA2kCVNwVsil2EM2mB0SkXytxCqQjS4mttjDpnXmwG9T6bO', // STON
  offerAmount: new TonWeb.utils.BN('1000000000'),
  proxyTonAddress: pTON.v1.address,
  minAskAmount: new TonWeb.utils.BN('1'),
  queryId: 12345,
});