v0.5 a v1

Guía de migración del SDK v0.5 a v1.0: transición a una API estable con funciones mejoradas

Introducción

En el SDK v1.0.0 lanzamiento, introducimos algunos cambios incompatibles. Puedes encontrar la lista completa de cambios del lanzamiento en el CHANGELOG.mdarrow-up-right 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.5.* to v1.0.0

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

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,
});

reemplazo del paquete TonWeb por @ton/ton

La principal fuente de los cambios incompatibles de este lanzamiento es la migración desde el tonwebarrow-up-right al @ton/tonarrow-up-right paquete. Así que, el primer paso es añadir el paquete @ton/ton a tu proyecto. Para hacerlo, sigue el paso de instalación de su documentaciónarrow-up-right.

Como resultado de este paso, necesitamos poder crear una instancia de TonClient que el paquete @ton-ton usa para hacer solicitudes en la cadena.

Cambio en la interfaz del constructor del contrato

Dado que el paquete @ton realiza una solicitud en la cadena inyectando el proveedor en los métodos de contrato abiertos, los contratos del SDK ya no necesitan requerir un tonApiClient en los parámetros del constructor. Por lo tanto, la interfaz del constructor del contrato se ha cambiado para aceptar la dirección como primer parámetro y el objeto de configuración como segundo parámetro.

Eso significa que la creación del contrato router en el código que estamos migrando tuvo que cambiarse a lo siguiente:

Router.v1 tiene una dirección predeterminada conocida, así que el primer parámetro del constructor, en este caso, es opcional. Para otros contratos, no hay una dirección predeterminada, por lo que debe especificarse

Si especificaste gasConstants personalizados para un contrato, todavía es posible hacerlo. Solo que en lugar de pasarlos como parte del objeto del primer parámetro del constructor, necesitas pasarlos en un segundo objeto

"Apertura" de los contratos

El paquete @ton/ton necesita abrirse para usarlo al hacer solicitudes en la cadena desde el contrato.

build*TxParams cambio de nombre de métodos

Todos los contratos build*TxParams métodos fueron renombrados a get*TxParams. Esto fue necesario para coincidir con la convención del paquete @ton/ton para métodos que podían hacer solicitudes en la cadena

reemplazo de BN.js por BigInt nativo

En la versión anterior del paquete SDK, para representar la cantidad usábamos BN.js, que venía como parte del paquete TonWeb y era accesible mediante TonWeb.utils.BN. El paquete @ton/ton usa JavaScript nativo BigInt en lugar de BN.js.

Y la migración es bastante fácil: como los constructores de BN y BigInt son comparables. Solo necesitamos reemplazar la clase que representa la cantidad

Operaciones con pTON

Anteriormente, cada operación que trabajaba con TON nativo solicitaba una proxyTonAddress. Pero como estamos desarrollando la próxima versión del contrato proxyTon con algunas diferencias en la transacción de envío de TON en lugar de solo la dirección, necesitamos saber más sobre el proxyTon.

Así que ahora las operaciones con TON nativo requieren la instancia de los contratos pTON.

txParams cambio de forma y MessageData eliminación del tipo

Para ajustarnos mejor a las interfaces del paquete @ton/ton, cambiamos ligeramente la forma del objeto que devuelve los get*TxParams métodos. El cambio es solo en los nombres; el propósito de este campo siguió siendo el mismo. Describe la transacción que, si se envía, causará la acción solicitada en el DEX.

Este cambio nos permite usar la salida de los get*TxParams métodos directamente en la funcionalidad de envío de @ton/ton.

Antes

Después

Como cambiamos de nuestra MessageData interfaz a @ton/ton SenderArguments tipo, MessageData la exportación del paquete SDK fue eliminada

Cambio de nombre de métodos de contratos

En v1.0.0se renombraron algunos de los métodos del contrato:

v0.5.*

v1.0.0

RouterV1.getData

RouterV1.getRouterData

PoolV1.getData

PoolV1.getPoolData

LpAccountV1.getData

LpAccountV1.getLpAccountData

Conclusión

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

Última actualización