Example using chronik to retrieve the genesis details of the eToken and its current stats (e.g. mount minted, burned)
Details
Details
- Reviewers
bytesofman - Group Reviewers
Restricted Project - Commits
- rABC263ae88127b0: [Apps][Examples] Get eToken Info
npm test
npm run getTokenDetails <token id>
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
TIL chronik does this...I've been using chronik.tx(tokenId)
Is there a difference in the response?
chronik.token() specifically returns the slp metadata, saving you the hassle of traversing 5-6 levels into the large tx() JSON response, whereas in chronik.tx() you have to go digging into the JSON response. The token() call also returns minting and burning statistics on the token, which you would otherwise have to manually derive based on various data from the tx() call.
| apps/examples/scripts/getTokenDetails.js | ||
|---|---|---|
| 11 ↗ | (On Diff #41145) | another benefit of using "type /** and then push enter" approach is it always gives standard output, don't need to manually create the standard |
| 23 ↗ | (On Diff #41145) | since this is a library for devs to mess around in, we should have it default to an ABC hosted chronik instance not great UX to always add a chronik URL at the command line in addition to a token ID |
| apps/examples/scripts/getTokenDetails.js | ||
|---|---|---|
| 31 ↗ | (On Diff #41155) | this URL will be used in many scripts, so it should be kept in its own file e.g. export it from config.js at the top level -- this is what alias-server and ecash-herald do |
Comment Actions
We'll be using this in many scripts, so it should be kept in its own file. e.g. create a config.js and export this here
As discussed
Comment Actions
As discussed
in case a future reviewer sees these, "as discussed" ref --> target user here is someone learning about developing on ecash. We don't really need them to learn about node and module.exports and config files. Keeping everything they need in one file -- which may be the extent of a user's need -- is best practice in this case