* Don't log full error
In `txwrapper` we can't always know if a payload is a signing payload or a signed tx so we first try one and then the other. When the former fails users get a scary-looking error. If upstream logs the error there's little we can do about it lest we [monkey patch `console.error`](https://github.com/paritytech/txwrapper-core/pull/22/files#diff-ea2d1c5845dd0e2fb9814e98a3464c2c63a43922983391e98fe9c20c328e979cR55) which is nasty af.
Hence this PR that removes the log here so that downstream can choose what to do with the error message.
* Add UnsafeOptions to let callers decide if they want errors logged or not
* Update packages/api-contract/src/util.ts
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Update packages/rpc-core/src/index.ts
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Update packages/rpc-core/src/index.ts
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* Update packages/types/src/create/createType.ts
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
Co-authored-by: Jaco Greeff <jacogr@gmail.com>
* use queryStorageAt for multi storage queries
* fix lint
* e2e tests
* skip lints for api.spec.ts
* remove e2e test from PR
* do not decorate multi() if can not supported
* empty line
* update
Co-authored-by: Ian He <ian.he@centrality.ai>
* WIP on bounties derive.
* wip
* Some basic tests for derive bounties
* Simplify bounties derive and mocks
* Get bounties and descriptions
* Allow for empty bounties. Refactor tests.
* Move tests to test directory
* Attempt to remove duplication
* Sort imports
* Reorganize tests
* Change returned type
* Bump metadata (w/ AssetBalance, AssetDetails)
* Bluperint for new-style with salt as default
* Use TBalance
* Easier overrides
* Balance
* Build types
* Use logger in error/warning messages
* Update packages/types/src/codec/BTreeSet.ts
* Update expectation
* Some additional type tests
* resgirty.hash returns H256
* Additional override test
* Cleanup with meta registry
* Update packages/api-contract/src/MetaRegistry.ts
* Allow for Str type
* No .only
* Cleanups
* Registry references
* Cleanups, real registry
* Ordering
* Future-proof
* ContractRegistry always has own registry instance
* Hacky Bytes notation
* Revert Bytes (for now, keep it simple)
* Apply suggestions from code review
* Expand on found error
* Updated ABI definitions & parsing
* Run type generation
* Definitions (should be ok-ish)
* Cleanup names
* Allow aliasses on structs (JSON parsing)
* Cleanup json mapping passing
* s/types/lookup/
* Parsing as per current output
* InkSelector
* MtRegistryIndex
* String lookup tests
* Remove serd ovverride comments (it works as-is)
* inkRegistry tests
* Extract primitive types
* s/ty/id/
* Start of parsing into types (actually to be TypeDef)
* Parsing
* stringify struct fields
* Small cleanups
* Add type index to project lookup
* Prefix with index
* Fix interface generation
* Latest contract metadata (#2118)
* Add new (provisional) incrementer contract metadata
* Update and regenerate type definitions
* WIP: generate new format scale-info types
* WIP: implementing variants
* Implement variants
* Fix up type resolution
* Fix registry spec tests
* Fix lints and some tests
* Fix inkTypes tests
* Fix some lints
* Make imports same line like original
* Comment out (temporarily) sanitize import to make CI pass
* Sanitize
* Remove indices
* Remove index
* Adjust ContractAbi interface (empty rpc)
* linting
* Pull in Andrew's changes
* Cleanups
* Some more cleanups
* Update with v3 contracts
* Adjust with actual types
* Regenerate
* Update ABI parsing (#2695)
* Adjust ABI code
* Cleanup
* Merge non-code
* Type naming
* Simplify Base
* Rename 1
* rename 2
* Rename 3
* Simplify
* Add index to AbiMessage
* Pass actual message or index for call
* Rename param
* Simplify
* Expose call & exec
* s/call/read/
* Cleanup asserts
* AccountId as per spec
* displayName is path
* Update definitions
* Flatten ABIType into TypeDef
* Rewrite
* Fix tests
* Updates
Co-authored-by: Andrew Jones <ascjones@gmail.com>
* 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.
@@ -13,7 +13,7 @@ If you are an existing user, please be sure to track the [CHANGELOG](CHANGELOG.m
## tutorials
Looking for tutorials to get started? Look at [examples](https://polkadot.js.org/api/examples/promise/) for guides on how to use the API to make queries and submit transactions.
Looking for tutorials to get started? Look at [examples](https://polkadot.js.org/docs/api/examples/promise/) for guides on how to use the API to make queries and submit transactions.
## overview
@@ -27,21 +27,4 @@ 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
## development
Contributions are welcome!
To start off, this repo (along with others in the [@polkadot](https://github.com/polkadot-js/) family) uses yarn workspaces to organise the code. As such, after cloning, its dependencies _should_ be installed via `yarn`, not via npm; the latter will result in broken dependencies.
To get started -
1. Clone the repo locally, via `git clone https://github.com/polkadot-js/api <optional local path>`
2. Ensure that you have a recent version of Node.js, for development purposes [Node 10](https://nodejs.org/en/) is recommended.
3. Ensure that you have a recent version of Yarn, for development purposes [Yarn >=1.10.1](https://yarnpkg.com/docs/install) is required.
4. Install the dependencies by running `yarn`
5. Build the everything via `yarn run build`
6. You can also launch the API Docs, via `yarn vuepress dev docs`
7. Access the docs via [http://localhost:8080](http://localhost:8080)
# Docker compose file to run Polkadot-JS API e2e test files on supported versions of Polkadot and Substrate
#
# Setup:
# Builds 5 containers with different supported versions of Substrate and Polkadot.
# Runs Polkadot-JS API Tests
#
# Before you can run this script, you need to install Docker and 'Docker Compose' on your machine.
# Please follow the steps described here (including the prerequisites): https://docs.docker.com/compose/install/
#
# Usage:
# 1. BUILD: Run `docker-compose pull && docker-compose up -d` to pull the latest docker imaged and run docker-compose in detached mode. This will run the substrate and polkadot containers in the background.
# 2. INFO: Run `docker ps` to get a list of Docker containers running in the background including their mapped ports on localhost
# 3. TEST: Run `docker-compose logs -f js-api-tests` to run the API tests and print the logs
# 4. QUIT: Run `docker-compose down` to stop and remove all running containers.
#
# Provided Endpoints for localhost:
# - Substrate Master: ws://127.0.0.1:9945/
# - Substrate 1.0: ws://127.0.0.1:9946/
# - Substrate 2.0: ws://127.0.0.1:9947/
# - Polkadot Master: ws://127.0.0.1:9948/
# - Polkadot Alexander: ws://127.0.0.1:9949/
#
# Find more Docker images of Substrate https://hub.docker.com/r/parity/substrate/tags
# Find more Docker images of Polkadot https://hub.docker.com/r/parity/polkadot/tags
The API provides application developers the ability to query a node and interact with the Polkadot or Substrate chains using Javascript. Here you will find documentation and examples to get you started.
::: tip Getting started & Examples
[Jump right in](/start/) and get an overview on using the API in your projects, from installation all the way through to making it do magic. Have things working and want tips? The [cookbook](/cookbook/) provides some tips and tricks. Getting started and want some full examples? [The ApiPromise examples](/examples/promise/) provide some basic examples.
:::
## The Polkadot Project
You can read more about the Polkadot Network at [https://polkadot.network/](https://polkadot.network/) and more about the polkadot-js projects at [https://polkadot.js.org](https://polkadot.js.org)
This documentation is generated from [https://github.com/polkadot-js/api](https://github.com/polkadot-js/api)
## Contributing
Contribution to the Polkadot JS API are more than welcome. You can [report issues](https://github.com/polkadot-js/api/issues/new) and [log feature requests](https://github.com/polkadot-js/api/issues/new).
The cookbook hosts small code snippets in a question-answer format. It does not walk you through the whole setup, like the [basic examples](../examples/), but rather aims to answer some questions around specific uses. It also does not replace the [getting started FAQ](../start/FAQ.md), rather this is focussed explicitly on code samples, instead of general trouble-shooting for common mishaps.
These questions are added as they do come up and the hope is that the snippets here is will be useful to others, instead of just the original person who asked on a specific use-case. As of today, it is only making a start and not fully comprehensive yet - check back early, check back often.
## Sections
The following cookbook sections are available -
- [Blocks](blocks.md) - Snippets around working with blocks and headers
- [Storage](storage.md) - Snippets for working with storage
- [Transactions](tx.md) - Snippets for working with transactions
... more to come.
## Contribute
And as always, if you have an addition to make, or a question to ask any [any PRs](https://github.com/polkadot-js/api/tree/master/docs) or [issues](https://github.com/polkadot-js/api/issues) are appreciated. The initial content was generate from exactly such questions, either in Riot chat or as submitted as issues.
The building blocks for each blockchain. As such there are a number of examples for working with blocks and headers, that could be useful.
## How do I retrieve the header/extrinsic hash from blocks?
A block hash refers to the hash over the header, the extrinsic hash refers to the hash of the encoded extrinsic. Since all objects returned by the API implements the `.hash => Hash` getter, we can simply use this to view the actual hash.
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)
Here you will find snippets for working with storage.
## How do I check for storage existence?
In the metadata, for each storage item a fallback is provided. This means that when an entry does not exist, the fallback (which is the default value for the type) will be provided. This means, that querying for a non-existent key (unless an option), will yield a value -
In the second case, the non-existent prefs returns the default/fallback value for the storage item. So in this case we don't know if the value is set to 0 or unset. Existence can be checked by using the storage size, which would be zero if nothing is stored.
## How do I use .entries()/.keys() on double maps?
As [explained elsewhere](../start/api.query.other.md#map-keys-entries) each map-type storage entry exposes the entries/keys helpers to retrieve the whole list. In the case of double maps, with the addition of a single argument, you can retrieve either all entries or a subset based on the first map key.
In both these cases, entries/keys operate the same way, `.entries()` retrieving `(StorageKey, Codec)[]` and `.keys()` retrieving `StorageKey[]`
```js
// Retrieves the entries for all slashes, in all eras (no arg)
A blockchain is no fun if you are not submitting transactions. Or at least if somebody is not submitting any. Here you will find some snippets for dealing with some common issues.
## How do I estimate the transaction fees?
In addition to the `signAndSend` helper on transactions, `.paymentInfo` (with the exact same parameters) are also exposed. Using the same sender, it applies a dummy signature to the transaction and then gets the fee estimation via RPC.
```js
// estimate the fees as RuntimeDispatchInfo, using the signer (either
// address or locked/unlocked keypair) (When overrides are applied, e.g
// nonce, the format would be `paymentInfo(sender, { nonce })`)
constinfo=awaitapi.tx.balances
.transfer(recipient,123)
.paymentInfo(sender);
// log relevant info, partialFee is Balance, estimated for current
console.log(`
class=${class.toString()},
weight=${weight.toString()},
partialFee=${partialFee.toHuman()}
`);
```
## How do I get the decoded enum for an ExtrinsicFailed event?
Assuming you are sending a tx via `.signAndSend`, the callback yields information around the tx pool status as well as any events when `isInBlock` or `isFinalized`. If an extrinsic fails via `system.ExtrinsicFailed` event, you can retrieve the error, if defined as an enum on a module.
```js
api.tx.balances
.transfer(recipient,123)
.signAndSend(sender,({status,events})=>{
if(status.isInBlock||status.isFinalized){
events
// find/filter for failed events
.filter(({section,method})=>
section==='system'&&
method==='ExtrinsicFailed'
)
// we know that data for system.ExtrinsicFailed is
// (DispatchError, DispatchInfo)
.forEach(({data:[error,info]})=>{
if(error.isModule){
// for module errors, we have the section indexed, lookup
For most runtime modules, transactions need to be signed and validation for this happens node-side. There are however modules that accepts unsigned extrinsics, an example would be the Polkadot/Kusama token claims (which is here used as an example).
```js
// construct the transaction, exactly as per normal
// send it without calling sign, pass callback with status/events
tx.send(({status})=>{
if(status.isInBlock){
console.log(`included in ${status.asInBlock}`);
}
});
```
The signing is indicated by the first byte in the transaction, so in this case we have called `.send` on it (no `.sign` or `.signAndSend`), so it will be sent using the unsigned state, without signature attached.
## How can I batch transactions?
Polkadot/Substrate provides a `utility.batch` method that can be used to send a number of transactions at once. These are then executed from a single sender (single nonce specified) in sequence. This is very useful in a number of cases, for instance if you wish to create a payout for a validator for multiple eras, you can use this method. Likewise, you can send a number of transfers at once. Or even batch different types of transactions.
```js
// construct a list of transactions we want to batch
consttxs=[
api.tx.balances.transfer(addrBob,12345),
api.tx.balances.transfer(addrEve,12345),
api.tx.staking.unbond(12345)
];
// construct the batch and send the transactions
api.tx.utility
.batch(txs)
.signAndSend(sender,({status})=>{
if(status.isInBlock){
console.log(`included in ${status.asInBlock}`);
}
});
```
## 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 or querying it via `rpc.system.accountNextIndex`.
```js
for(leti=0;i<10;i++){
// retrieve sender's next index/nonce, taking txs in the pool into account
In addition to querying the latest storage, you can make storage queries at a specific blockhash. Be aware that the node applies a pruning strategy and typically only keeps the last 256 blocks, unless run in archive mode.
This transactions shows you how to add a nonce and a valid length of blocks a transaction is valid for.
This is important because as an account drops below the exsistential limit (0.1 dots) it gets pruned from the state tree. If it is added back its nonce starts at 0 again and is now vulnerable to replay attacks.
Performs a chain upgrade using the `sudo` module. This may brick your chain, so use it as an educational sample. (use `substrate purge-chain --dev` to remove DB and recover).
This is a sample TypeScript project [with full source & config on GithHub](https://github.com/polkadot-js/api/tree/master/docs/examples/promise/90_typegen), that uses `@polkadot/typegen` to generate type definitions that can be used to decorate the `@polkadot/api`. It uses both types defined for the specific chain as well as the chain metadata to generate TypeScript interfaces. This means that interfaces such as `api.query.*`, `api.tx.*` and `api.consts.*` will be decorated based on chain-specific information, instead of an un-augmented catch-all definition.
**NOTE** This is built using the updates in the `1.4.0` api track and as such it uses the latest (at the time of writing) `@polkadot/api 1.4.0`. If you want to play on your own, it is also suggested that you use the `1.4+` series since some generation types have moved around internally, making it easier to augment.
## Packages
For the packages we need from the `@polkadot/*` we have added `@polkadot/api` (we want to do API stuff) and `@polkadot/typegen` (to generate the actual interfaces). So our scripts and dependencies inside `package.json` contain the following -
We will delve into the setup and running the scripts and what they do in a short bit, but as of now just notice that we are running the scripts via `ts-node`. Since we supply our definitions as `*.ts` files, this is important otherwise they will not be parsable. `build` will just run both the types and meta generators (in that order, so metadata can use the types) and we have a `lint` that can just check that everything is as it is meant to be.
## Metadata setup
The idea here is to use the actual chain metadata to generate the actual api augmented endpoints. The metadata we are adding here (in addition to the user types), is from the Edgeware Berlin testnet. So this is a real-world example of configuring the API for a specific substrate chain. For the metadata retrieval, we just ran a simple curl command to get it from the node -
And then add the full JSONPC output as received to the `edgeware.json` file as specified by the generation command. A trimmed version would look like -
The generator can also use a `wss://` as an `--endpoint` param as part of the generation, but in most cases you would want a static metadata to work from in development, hence we are actually adding it here.
## Types setup
The types are defined in the `src/interfaces` folder. While this repo contains a number of generated files in there as well, you basically only need to manually add the following -
-`src/interfaces/definitions.ts` - this just exports all the sub-folder definitions in one go
-`src/interfaces/<module>/definitions.ts` - type definitions for a specific module
This structure fully matches what is available in the `@polkadot/type/interfaces` folder, so the structure is setup based on the convention used in the `@polkadot/types` library. The generating scripts will expect something matching this since the same underlying code is actually used inside `@polkadot/types` as well. The top-level `interfaces/` folder can be name anything, however the internal content structure need to match what is defined above.
For the top-level the definition file has the following contents -
As explained above, it really is just a re-export of the definitions, so they are all easily accessible to the outside, i.e. we will use this import inside our own code to use the definitions in API initialization. The generation scripts will load this file to determine which types it needs to import. By the `@polkadot/types` convention, match the export names with the folders (preferably your runtime module names), the generation scripts will use these names to find the correct folders to output the generated `types.ts` to.
For each of the folders, `signaling`, `treasuryRewards` and `voting` another `definitions.ts` file is contained within. Looking at the one from `signaling`, it contains this -
```js
exportdefault{
types:{
ProposalRecord:{
index:'u32',
author:'AccountId',
stage:'VoteStage',
transition_time:'u32',
title:'Text',
contents:'Text',
vote_id:'u64'
},
ProposalContents:'Vec<u8>',
ProposalTitle:'Vec<u8>'
}
}
```
Just the type definitions (the structure of which you should be familiar with), nested inside a `types: {...}` container. This allows us future extension points, i.e. there is some work to expose the custom RPC types alongside, so that would become another key on a per-module basis.
In the above, you will note that the `ProposalRecord` references a type for `voting`, i.e. `VoteStage`. The type generation and resolution will determine where the type comes from, and provide the required imports on generation.
Looking at the example in this repo, it also has `augment*`, `index.ts` and `types.ts` files in the interfaces folder. These are all generated, and will be re-generated when the generator is run - so all edits to these files will be lost. The only requirement for user-edits are the `definitions.ts` files.
## 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 if we check the actual output against the source via `yarn lint`, we would see that valid output has been generated -
```
> yarn lint
$ tsc --noEmit --pretty
✨ Done in 2.28s.
```
## Peering at the output
We are ready to use all these generated types this after some TS config. If you take a look at the generated `src/signaling/types.ts`, you would see generated TS interfaces, such as -
As mentioned earlier, here you will notice the `import { VoteStage }`, the generator has determined that `voting` exports that interface and has added the required imports.
## 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) -
Effectively what we do above is tell the TypeScript compiler to not use the built-in API augmentation, but rather to replace it with our version. This means that all types from these are injected not by the substrate-latest-master version, but rather with what we have defined above.
## Usage
For simple usage, we have added the `src/index.ts` file that show how the metadata and types actually decorate the API. In addition, we also have setup instructions included here.
```js
// We need to import the augmented definitions "somewhere" in our project, however since we have
// it in tsconfig as an override and the api/types has imports, it is not strictly required here.
// Because of the tsconfig override, we could import from '@polkadot/{api, types}/augment'
Here you will find a list of examples that takes you through the basics of connecting to a local node, retrieving data from the Node and chain and execute transactions on the chain. It uses the [[ApiPromise]] interface.
## Prerequisites
For the following examples, you need a local node. It is usually convenient testing with:
```
substrate --dev
```
## Running the examples
From each folder, run `yarn` to install the required dependencies and then run `yarn start` to execute the example against the running node.
Those accounts are easy to add if you don't have/see them. The seed of Alice's account is `//Alice` (via `keyring.addUri(...)`, dev seed implied) and the seed of Bob is... well you guess...
This sample shows how to create a transaction to make a transfer from one an account to another.
<<< @/docs/examples/rx/06_make_transfer/index.js
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.