Road from Polkadot-JS to Polkadot-API

[vikiival]

Context

As you may know our code currently relies on polkadot/api package the bundle is kinda big (~1.15mb) and cause slowdown of build and app itself.

The proposed alternative is to use polkadot-api package that is 2-times smaller (~650 kb, but some say around 50kb tree-shaken) and can additionally run in the worker, so it does not need to eat the thread ^-^.

Usage in KodaDot

Currently we have rely on

• 49 calls (api.tx.) in 21 files
• 7 queries (api.queries.) in 7 files
• 8 constants (api.consts.) in 2 files

Limitations

1. We rely on very legacy package I wrote @kodadot1/sub-api, therefore we would need to adapt out useApi into PAPI

2. Signers, this would probably need input from my side as I have originally wrote transactionExecutor.ts (working stable since 2021 c08f3bf)

3. Wallet connectors - probably @Tbaut could help us with that ❤️

4. Utils/formatters - most utils can be reused in first iteration from polkadot-js/utils or else we can unify utils with EVM stuff through @wevm OX lib.

Reading

• https://polkadot.js.org/docs/
• https://papi.how
• https://www.youtube.com/watch?v=fRI96YD105E

[vikiival]

To Current maintainers of @polkadot-api (@carlosala, @josepot):

• Are there any caveats people should be aware of?
• Is there something that is unimplemented yet?
• Is it somehow doable to make a library on top of PAPI?

[josepot]

Is it somehow doable to make a library on top of PAPI?

Of course! And very much encouraged! 🙂

[dudo50]

Switching KodaDot to PAPI would be a great enhancement for us in ParaSpell also. We wish to fully migrate XCM SDK to PAPI as soon as possible. But we are waiting for other projects to migrate to PAPI also, that is why we kept PJS compatibility still :).

[Tbaut]

The wallet connector I'm using in Multix and Delegit is https://dotconnect.dev from @tien as mentioned in my talk from Sub0. It does come with the reactive-dot dependency, but it's a small concession to make to get access to this super useful tool, and Tien's reactivity in case you have any issue is stellar!

[michaeldev5]

Hi @vikiival,

it's great to hear about this move towards the new Polkadot API. Our experience with PAPI has been very positive so far. We noticed faster responses and cleaner documentation. For example, when setting up fail-safe mechanisms for multiple WebSocket endpoints, we found no documentation for this in PJS.

One thing to beware is that Papi is using named enums instead of normal JS objects, which means you’ll need to update some parts of the code. Every other thing that we had problem with the maintainers quickly solved. For now we use the non-typed version of the api since we support many chains. But we plan to migrate towards typed api soon.

[josepot]

One thing to beware is that Papi is using named enums instead of normal JS objects

This is not completely accurate... For instance, this:

const foo = MultiAddress.Id(someAddress)

is the same as:

const foo = Enum('Id', someAddress)

which is also the same as:

const foo = { type: 'Id', value: someAddress }

That being said, when the enums are very complex (like XCM) and they have circular dependencies and what not, then the "known enums" that we export from the descriptors (the first example), offer much better typings, because the other 2 options rely purely on TS inference, which -as I already mentioned- when there are many nested enums with complex/circular types sometimes the TS server fails to properly infer them.

However, it is very true that the way that PAPI decodes enums is quite different than the way that PJS decodes enums... That's because we want to have better typings when reading on-chain responses that have enums.

For now we use the non-typed version of the api since we support many chains. But we plan to migrate towards typed api soon

For a library like yours it probably makes sense to use the compatibility API to figure out whether the chain that you are working against uses XCM v4 or XCM v5, and then have your own "safe" API for the XCM interactions... We are currently working on an SDK for cross-chain interactions, it's probably worth to have a sync once we have it a bit more mature... 😉