* Align costs typing with queries
* better...
* ... and better
* ... progress
* better, down to 8
* ... down to 3
* ... 2
* Down to 1
* It builds.
* ... it really builds
* Known upgrade points for on-chain version skip
* Update packages/types-known/src/index.ts
* Update packages/api/src/base/Init.ts
* Actual known upgrade blocks for Polkadot & Kusama
* Update with known Kusama upgrade history
* linting
* Update definitions.ts
Will fix the decoding of these types. Sadly cannot provide a compact test case.
* Add more tests.
* Make the tests work.
* Fix linting as well.
* [NEW] Support for custom headers with providers
This allows the user to supply arbitrary headers when constructing the
providers.
* [FIX] null -> undefined, use isChildClass
Co-authored-by: Brad Larson <brad@polychain.capital>
* Bump metadata, allow type alias on events
* Update packages/api/src/submittable/createClass.ts
* Update packages/metadata/src/Metadata/v11/static-substrate.json
* Fresh, no config changes
* feat: add external pagination support
* Ordering, no functionality changes
* fix: use correct assertion condition
Also moved the PaginationOptions type to the base types file
* Apply suggestions from code review
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Allow keyPrefix to accept an additional argument for double maps
* Make key creators accept an optional parameter for key construction
* Remove .only from a test case
Co-authored-by: Xiliang Chen <xlchen1291@gmail.com>
* Cache prefix key when no arguments are supplied
* Address review comments
* Update packages/metadata/src/Decorated/storage/fromMetadata/createFunction.spec.ts
Co-authored-by: Xiliang Chen <xlchen1291@gmail.com>
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Fix incorrect ws connect test cases
* Make endpoint an array of endpoints
* Add requirement that WsProvider endpoint arrays must not be empty
* Simple endpoint increment
* Add multi-endpoint test for endpoint closing its connection
* Implement endpoint round robin
* Revert change to mock's TEST_WS_URL
* Address Lint errors
* Change endpoint variable to plural in WsProvider
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Review corrections to WsProvider
* Grouping improvement in WsProvider connect
* Correct endpoint logging to only show the specific endpoint involved
* Correct ordering of endpoint increment on connect
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Make the 2nd argument to SubmittableExtrinsic.sign/signAsync optional
* Use default argument for optionsOrNonce
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
This library provides a clean wrapper around all the methods exposed by a Polkadot/Subtrate network client and defines all the types exposed by a node. For complete documentation around the classes, interfaces and their use, visit the [documentation portal](https://polkadot.js.org/api/).
This library provides a clean wrapper around all the methods exposed by a Polkadot/Substrate network client and defines all the types exposed by a node. For complete documentation around the classes, interfaces and their use, visit the [documentation portal](https://polkadot.js.org/api/).
If you are an existing user, please be sure to track the [CHANGELOG](CHANGELOG.md) and [UPGRADING](UPGRADING.md) guides when changing versions.
@@ -27,7 +27,6 @@ The API is split up into a number of internal packages -
Type definitions for interfaces as exposed by Polkadot & Substrate clients -
- [@polkadot/jsonrpc](packages/jsonrpc/) Definitions for JSONRPC endpoints
- [@polkadot/types](packages/types/) Codecs for all Polkadot and Substrate primitives
Th block author is encoded inside the consensus logs for the block. To extract, you need to decode the log (which the API does do) and then map the index of the validator to the list of session validators. This extraction is however available on the api derive for new head subscriptions, which returns an extended header with the author populated (assuming that the digest logs are known).
The block author is encoded inside the consensus logs for the block. To extract, you need to decode the log (which the API does do) and then map the index of the validator to the list of session validators. This extraction is however available on the api derive for new head subscriptions, which returns an extended header with the author populated (assuming that the digest logs are known).
```js
// subscribe to all new headers (with extended info)
The transactions are included in a signed block as part of the extrinsics - some of these will be unsigned and generated by the block author and some of these may be submitted from external sources and be signed. (Some palettes do use unsigned transactions, so signed/unsigned is not an indication of origin). To retrieve the block and display the transaction information, we can do the following -
```js
// no blockHash is specified, so we retrieve the latest
In the above `.toHuman()` is used to format into a human-readable representation. You can inspect/extract specific fields from the decoded extrinsic as required, for instance `ex.method.section` would return the pallete that executed this transaction.
@@ -16,9 +16,9 @@ const info = await api.tx.balances
// log relevant info, partialFee is Balance, estimated for current
console.log(`
class=${class.toString()},
weight=${weight.toString()},
partialFee=${partialFee.toHuman()}
class=${info.class.toString()},
weight=${info.weight.toString()},
partialFee=${info.partialFee.toHuman()}
`);
```
@@ -97,12 +97,12 @@ api.tx.utility
## How do I take the pending tx pool into account in my nonce?
The `system.account` query will always contain the current state, i.e. it will reflect the nonce for the last known block. As such when sending multiple transactions in quick succession (see batching above), there may be transactions in the pool that has the same nonce that `signAndSend` would apply - this call doesn't do any magic, it simply reads the state for the nonce. Since we can specify options to the `signandSend` operation, we can override the nonce, either by manually incrementing it o querying it via `nextNonce`.
The `system.account` query will always contain the current state, i.e. it will reflect the nonce for the last known block. As such when sending multiple transactions in quick succession (see batching above), there may be transactions in the pool that has the same nonce that `signAndSend` would apply - this call doesn't do any magic, it simply reads the state for the nonce. Since we can specify options to the `signAndSend` operation, we can override the nonce, either by manually incrementing it or querying it via `rpc.system.accountNextIndex`.
```js
for (let i = 0; i < 10; i++) {
// retrieve the nextNonce, taking txs in the pool into account
@@ -90,7 +90,7 @@ Looking at the example in this repo, it also has `augment*`, `index.ts` and `typ
## Generating
Now that both the metadata nd types setup is completed, we just run the build command via `yarn build` and magically (assuming you didn't have the `augment*` and other generated files), these files will be added. When running this command, the console should display something like -
Now that both the metadata and types setup is completed, we just run the build command via `yarn build` and magically (assuming you didn't have the `augment*` and other generated files), these files will be added. When running this command, the console should display something like -
```
> yarn build
@@ -166,7 +166,7 @@ As mentioned earlier, here you will notice the `import { VoteStage }`, the gener
## TypeScript config
Now that we have files generated, it is time to make TypeScript aware of the types and add an explicit override into out `tsconfig.json`. After some changes, the paths in the config looks as follow (comments are in teh actual config file here) -
Now that we have files generated, it is time to make TypeScript aware of the types and add an explicit override into out `tsconfig.json`. After some changes, the paths in the config looks as follow (comments are in the actual config file here) -
@@ -20,6 +20,8 @@ All data transferred between the API and the Node is in a SCALE-encoded binary f
To fix this, you should look at the specific `api.tx.*` params and adjust the type definitions for those param types to match what is found on the node side. In some rare cases the cause could be extrinsic formatting related, to track these make an `api.tx.system.remark(data: Bytes)` call, if it fails, the API and node cannot agree on [an extrinsic format and adjustments are required](types.extend.md#impact-on-extrinsics).
If you are using a node-template based version of substrate and you changed the specName you need to add these typings(In addition to other custom types) `{"Address": "AccountId","LookupSource": "AccountId"}`. This is also the case when you use [polkadot-js/apps](https://github.com/polkadot-js/apps) to connect to your node. When the specName stays node-template the API is smart enough to add the custom typings.
## I would like to sign transactions offline
The API itself is independent on where the signature comes from and how it is injected. Additionally it implements a signer interface, that can be used for external signing - an example of this is the [polkadot-js/apps](https://github.com/polkadot-js/apps) support for signing via extensions and even the [polkadot-js/extension](https://github.com/polkadot-js/extension) support for tools such as the [Parity Signer](https://github.com/paritytech/parity-signer).
In all cases the API will handle reconnections automatically. This means that when you connect and the endpoint is not (yet) ready, the promise will not resolve immediately, but rather when connected. The same applies to when connection is lost, the API will manage re-connections.
In all cases the API will handle reconnecting automatically. This means that when you connect and the endpoint is not (yet) ready, the promise will not resolve immediately, but rather when connected. The same applies to when connection is lost, the API will manage re-connections.
In cases where the API does not support the chain being connected to, such as it using an unknown metadata version, the ready promise will fail to resolve and instead reject.
In previous sections we looked at the injection of types, as in use and defined in modules from the node. Another area that can be customized is RC definitions, and like with the types, the API provides the capability to add user-defined RPCs (in addition to the Polkadot/Substrate base) to allow use of these RPCs via the API.
In previous sections we looked at the injection of types, as in use and defined in modules from the node. Another area that can be customized is RPC definitions, and like with the types, the API provides the capability to add user-defined RPCs (in addition to the Polkadot/Substrate base) to allow use of these RPCs via the API.
## Custom definitions
@@ -25,9 +25,14 @@ const api = await ApiPromise.create({
}
],
type: 'Balance'
}
}
}
},
anotherMethod: { ... },
...
},
anotherModule: { ... },
...
},
...
});
```
@@ -37,7 +42,7 @@ Be aware that while defined, the method will only appear on the API if it is in
## Definition breakdown
While the above example should be self-explanatory, it is important to understand teh structure. The `rpc: { ... }` definitions are keyed first and foremost by the name of the module exposing the RPC. This means that when we have 2 modules `firstModule` & `testModule`, the first-level structure would follow the following pattern,
While the above example should be self-explanatory, it is important to understand the structure. The `rpc: { ... }` definitions are keyed first and foremost by the name of the module exposing the RPC. This means that when we have 2 modules `firstModule` & `testModule`, the first-level structure would follow the following pattern,
@@ -10,6 +10,7 @@ As a minimum, anything returned by the API, be it a `Vec<...>`, `Option<...>`, `
- `.eq(<other value>)` - checks for equality against the other value. In all cases, it will accept "like" values, i.e. in the case of a number you can pass a primitive (such as `1`), a hex value (such as `0x01`) or even an `Unit8Array`
- `toHex()` - returns a hex-base representation of the value, always prefixed by `0x`
- `toHuman()` - returns Human-parsable JSON structure with values formatted as per the settings
- `toJSON()` - returns a JSON-like representation of the value, this is generally used when calling `JSON.stringify(...)` on the value
- `toString()` - returns a string representation, in some cases this performs additional encoding, i.e. for `Address`, `AccountId` and `AccountIndex` it will encode to the ss58 address
- `.toU8a()` - returns a `Uint8Array` representation of the encoded value (generally exactly as passed to the node, where values are SCALE encoded)
@@ -41,6 +42,7 @@ const system = modules.find(m => m.name.eq('system'));
All numbers wrap and extend an instance of [bn.js](https://github.com/indutny/bn.js/). This means that in addition to the interfaces defined above, they have some additional methods -
- `.toNumber()` - a JS number (limited to 2^53 - 1). This does mean that for large values, e.g. `Balance` (a `u128` extension), this can cause overflows
- `.toBigInt()` - a JS `BigInt` object (on supported platforms)
- `.add(...)`, `.sub(...)`, ... - all the base methods available on the `BN` object
In cases where a `Compact` is returned, i.e. `Compact<Balance>`, the value is wrapped. This object should be `.unwrap()`-ed first to gain access to the underlying `Balance` object.
@@ -6,7 +6,7 @@ Therefore to cater for all types, a mapping in done on the [@polkadot/types libr
Additionally, the API contains some logic for chain type detection, for instance in the case of Substrate 1.x based chains, it will define `BlockNumber` & `Index` (nonce) as a `u64`, while for current-generation chains, these will be defined as `u32`. Some of the work in maintaining the API for Polkadot/Substrate is the addition of types as they appear and gets used in the Rust codebase.
There is a the [recommendation](install.md#betas) to use a `@polkadot/api@beta` should you wish to track the master branches of Polkadot or Substrate, since master changes for the addition of new types do not make it into a stable release immediately.
There is the [recommendation](install.md#betas) to use a `@polkadot/api@beta` should you wish to track the master branches of Polkadot or Substrate, since master changes for the addition of new types do not make it into a stable release immediately.
## Extension
@@ -87,7 +87,7 @@ Document: {
## User-defined enum
One form of types that appear regularly is enums, these can be defined as follow -
One form of types that appear regularly is enums, these can be defined as follows -
```js
...
@@ -212,4 +212,4 @@ Always look at customization and understand the impacts, replicating these chang
## Custom RPC
In addition to customizing modules and types on your node, you can also add custom RPC definitions. Like the type definitions in ths section, [these can be defined and passed to the API](rpc.custom.md) for decoration.
In addition to customizing your node's modules and types, you can also add custom RPC definitions. Like the type definitions in this section, [these can be defined and passed to the API](rpc.custom.md) for decoration.
In the previous section we looked at the TypeScript definitions that are available and is generated from both the chain and definitions. Here we will expand upon the use of the infrastructure created to define types as part of the `@polkadot/types` library and see how to use them to generate your own definitions and chain types.
In the previous section we looked at the TypeScript definitions that are available and are generated from both the chain and definitions. Here we will expand upon the use of the infrastructure created to define types as part of the `@polkadot/types` library and see how to use them to generate your own definitions and chain types.
## Definitions
@@ -17,7 +17,7 @@ In the root of your project (with the `@polkadot/typegen` package installed), yo
## Chain modules
In the same way as the type library provides defaults from a substrate-base chain, you can also, directly from chain from metadata, generate a complete `api.{consts,query}.*` definition for your specific chain. The command will create 2 files, `{consts, query}.types.ts` which you can either use to augment the TypeScript definitions, or replace those in `@polkadot/api/*` with your versions (copy, TypeScript replacement or browser/node aliasing).
In the same way as the type library provides defaults from a substrate-base chain, you can also, directly from the chain's metadata, generate a complete `api.{consts,query}.*` definition for your specific chain. The command will create 2 files, `{consts, query}.types.ts` which you can either use to augment the TypeScript definitions, or replace those in `@polkadot/api/*` with your versions (copy, TypeScript replacement or browser/node aliasing).
In the root of your project, you can run `yarn polkadot-types-from-chain --endpoint wss://<url> --output ./stuff` and it will create the required output. (Here you can specify an optional `--package @MeInc/stuff` to read definitions for the targeted output folder with the specified package name.)
@@ -27,4 +27,4 @@ The [TypeScript augmentation example](../examples/promise/90_typegen/) example p
## And that's a wrap
This brings us to the end of our overview and jump through the API. While the documentation is still very much and ever evolving item, we can encourage you to try out what you have learned with some [examples](../examples). As we [indicated right at the start of this journey](README.md#help-us-help-others), if there are areas for improvement, let us know.
This brings us to the end of our overview and jump through the API. While the documentation is still very much an ever evolving item, we can encourage you to try out what you have learned with some [examples](../examples). As we [indicated right at the start of this journey](README.md#help-us-help-others), if there are areas for improvement, let us know.
assert(!!def,`Attempted to access a contract message that does not exist: ${typeofnameOrIndex==='number'?`index ${nameOrIndex}`:nameOrIndex}`);
assert(!!def,`Attempted to access a contract message that does not exist: ${typeofnameOrIndex==='number'?`index ${nameOrIndex}`:(nameOrIndex||'unknown')}`);
// The available balance & vested has an interplay here
// "
// vesting is a guarantee that the account's balance will never go below a certain amount. so it functions in the opposite way, a bit like a lock that is monotonically decreasing rather than a liquid amount that is monotonically increasing.
// locks function as the same guarantee - that a balance will not be lower than a particular amount.
// because of this you can see that if there is a "vesting lock" that guarantees the balance cannot go below 200, and a "staking lock" that guarantees the balance cannot drop below 300, then we just have two guarantees of which the first is irrelevant.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.