ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 23:25:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

xrpl.js 2.0: address feedback, fix many TODOs

Browse Source
This commit is contained in:
mDuo13
2021-10-19 18:55:06 -07:00
parent e70926c758
commit 7cff4596cc
16 changed files with 154 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
content/_code-samples/issue-a-token/js/issue-a-token.js
View File

@@ -6,9 +6,6 @@
if (typeof module !== "undefined") {
// gotta use var here because const/let are block-scoped to the if statement.
var xrpl = require('xrpl')
} else {
// TODO: remove when webpack is fixed
var xrpl = ripple;
}
// Connect ---------------------------------------------------------------------
@@ -54,8 +51,8 @@ async function main() {
"Domain": "6578616D706C652E636F6D", // "example.com"
"SetFlag": 2 // enable Require Auth so we can't use trust lines that users
// make to the hot address, even by accident.
//"Flags": (api.txFlags.AccountSet.DisallowXRP |
// api.txFlags.AccountSet.RequireDestTag)
//"Flags": (api.AccountSetAsfFlags.asfDisallowXRP |
// api.AccountSetAsfFlags.asfRequireDestTag)
}
const hst_prepared = await api.autofill(hot_settings_tx)

2
content/_snippets/checkcash-prereqs.md
View File

@@ -3,7 +3,7 @@ The prerequisites for cashing a check are the same whether you are cashing it fo
- You need the ID of a Check object currently in the ledger.
- For example, the ID of one Check in these examples is `838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334`, although you must use a different ID to go through these steps yourself.
- The **address** and **secret key** of the Check's stated recipient. The address must match the `Destination` address in the Check object.
- If the Check is for an issued currency, you (the recipient) must have a trust line to the issuer. Your limit on that trust line must be enough higher than the balance to add the amount you would receive.
- If the Check is for an issued currency, you (the recipient) must have a trust line to the issuer. Your limit on that trust line must be high enough to hold your previous balance plus the amount you would receive.
- For more information on trust lines and limits, see [Issued Currencies](issued-currencies.html) and [Trust Lines and Issuing](trust-lines-and-issuing.html).
- A [secure way to sign transactions](set-up-secure-signing.html).
- A [client library](client-libraries.html) that can connect to the XRP Ledger, or [any HTTP or WebSocket client](get-started-using-http-websocket-apis.html).

2
content/concepts/issued-currencies/rippling.md
View File

@@ -75,7 +75,7 @@ For more information, see [Default Ripple in 'Becoming an XRP Ledger Gateway'](b
The No Ripple flag can only be enabled on a trust line if the address has a positive or zero balance on that trust line. This is so that the feature cannot be abused to default on the obligation the trust line balance represents. (Of course, you can still default by abandoning the address.)
To enable the No Ripple flag, send a [TrustSet transaction][] with the `tfSetNoRipple` flag. You can disable No Ripple (enable rippling) with the `tfClearNoRipple` flag instead.
To enable the No Ripple flag, send a [TrustSet transaction][] with the `tfSetNoRipple` flag. You can disable the No Ripple flag (that is, allow rippling) with the `tfClearNoRipple` flag instead.
### Looking Up No Ripple Status

2
content/concepts/payment-system-basics/transaction-basics/transaction-cost.md
View File

@@ -124,7 +124,7 @@ The `Fee` field is one of the things that can be [auto-filled](transaction-commo
- To prevent a transaction from getting stuck in a state of being neither definitively confirmed or rejected, be sure to provide a `LastLedgerSequence` parameter so it eventually expires. Alternatively, you can try to [cancel a stuck transaction](about-canceling-a-transaction.html) by reusing the same `Sequence` number. See [reliable transaction submission](reliable-transaction-submission.html) for best practices.
- You have to be careful that the automatically provided value isn't too high. You don't want to burn a large fee to send a small transaction.
- If you are using `rippled`, you can also use the `fee_mult_max` and `fee_div_max` parameters of the [sign method][] to set a limit to the load scaling you are willing to sign.
- Some client libraries (like xrpl.js and xrpl-py) have configurable maximum `Fee` values, and raise an error instead of signing a transaction whose `Fee` value is higher than the maximum.
- Some client libraries (like [xrpl.js](https://js.xrpl.org/) and [xrpl-py](xrpl-py.readthedocs.io/)) have configurable maximum `Fee` values, and raise an error instead of signing a transaction whose `Fee` value is higher than the maximum.
- You cannot auto-fill from an offline machine nor when [multi-signing](multi-signing.html).

10
content/references/rippled-api/api-conventions/response-formatting.md
View File

@@ -5,16 +5,16 @@ blurb: Standard response format, with examples, for the WebSocket, JSON-RPC, and
---
# Response Formatting
Responses from the `rippled` APIs is formatted slightly differently based on whether the method is called with the WebSocket, JSON-RPC, or Commandline interfaces. The Commandline and JSON-RPC interfaces use the same format because the Commandline interface calls JSON-RPC.
Responses are formatted slightly differently based on whether the method is called with the WebSocket, JSON-RPC, or Commandline interfaces. The Commandline and JSON-RPC interfaces use the same format because the Commandline interface calls JSON-RPC.
The fields of a successful response include:
| `Field` | Type | Description |
|:----------------|:---------|:------------------------------------------------|
| `id` | (Varies) | (WebSocket only) ID provided in the request that prompted this response |
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. |
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. |
| `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. |
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](client-libraries.html) omit this field on success. |
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](client-libraries.html) omit this field on success. |
| `type` | String | (WebSocket only) The value `response` indicates a direct response to an API request. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. |
| `result` | Object | The result of the query; contents vary depending on the command. |
| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.html) threshold where the server will disconnect this client. <!-- STYLE_OVERRIDE: will --> |
| `warnings` | Array | _(May be omitted)_ If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). [New in: rippled 1.5.0][] |
@@ -180,6 +180,8 @@ It is generally safe to ignore this warning.
## See Also
- [Request Formatting](request-formatting.html)
- [Error Formatting](error-formatting.html) for unsuccessful API responses.
- **Concepts:**
- [The `rippled` Server](the-rippled-server.html)
- [Introduction to Consensus](intro-to-consensus.html)

181
content/references/xrpljs2-migration-guide.md
View File

@@ -49,13 +49,14 @@ const xrpl = require("xrpl");
})();
```
## Validated Results
By default, most methods in ripple-lib 1.x only returned results that were validated by the [consensus process](consensus.html) and final. The xrpl.js equivalents of many methods use the [`Client.request()` method](https://js.xrpl.org/classes/Client.html#request) to call the WebSocket API, where the XRP Ledger server's default settings often use the current (pending) ledger to serve data.
By default, most methods in ripple-lib 1.x only returned results that were validated by the [consensus process](consensus.html) and therefore final. The xrpl.js equivalents of many methods use the [`Client.request()` method](https://js.xrpl.org/classes/Client.html#request) to call the WebSocket API, where the XRP Ledger server's default settings often use the current (pending) ledger to serve data which is not final.
Sometimes you want to use the current open ledger to get data because it has the pending results of many transactions that are likely to succeed, such as when looking up the state of the [decentralized exchange](decentralized-exchange.html). In other cases, you want to use a validated ledger, which only incorporates the results of transactions that are finalized.
Sometimes you want to use the current open ledger because it has the pending results of many transactions that are likely to succeed, such as when looking up the state of the [decentralized exchange](decentralized-exchange.html). In other cases, you want to use a validated ledger, which only incorporates the results of transactions that are finalized.
When making API requests with xrpl.js 2.0 using the , you should explicitly [specify what ledger to use](basic-data-types.html#specifying-ledgers). For example, to look up trust lines using a _validated ledger_:
When making API requests with xrpl.js 2.0 using the , you should explicitly [specify what ledger to use](basic-data-types.html#specifying-ledgers). For example, to look up trust lines using the latest _validated ledger_:
**ripple-lib 1.x:**
@@ -129,6 +130,48 @@ const prepared = await client.autofill({
```
## Keys and Wallets
xrpl.js 2.0 introduces a new [`Wallet` class](https://js.xrpl.org/classes/Wallet.html) for managing [cryptographic keys](cryptographic-keys.html) and signing transactions. This replaces functions that took seed or secret values in ripple-lib 1.x, and handles various address encoding and generation tasks as well.
**ripple-lib 1.x:**
```js
api = new RippleAPI()
const seed = 's████████████████████████████';
const keypair = api.deriveKeypair(seed)
const address = api.deriveAddress(keypair.publicKey)
const tx_json = {
"Account": address,
"TransactionType":"Payment",
"Destination":"rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
"Amount":"13000000",
"Flags":2147483648,
"LastLedgerSequence":7835923,
"Fee":"13",
"Sequence":2
}
const signed = api.sign(JSON.stringify(tx_json), seed)
```
**xrpl.js 2.0:**
```js
const wallet = new xrpl.Wallet.fromSeed('s████████████████████████████')
const tx_json = {
"Account": wallet.address,
"TransactionType":"Payment",
"Destination":"rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
"Amount":"13000000",
"Flags":2147483648,
"LastLedgerSequence":7835923,
"Fee":"13",
"Sequence":2
}
const signed = wallet.sign(tx_json)
```
## Events and Subscriptions
In 1.x, you could subscribe to ledger events and API errors using the `.on()` method of the `RippleAPI` class; or you could subscribe to specific WebSocket message types using `.connection.on()`. These have been merged into the [`Client.on()` method](https://js.xrpl.org/classes/Client.html#on). Additionally, the client library no longer automatically subscribes to ledger close events when connecting to an XRP Ledger server, so **you must explicitly subscribe to the ledger stream** to get ledger close events in addition to adding a handler.
@@ -170,79 +213,87 @@ client.request({
## Reference of Equivalents
In ripple-lib 1.x all methods and properties were on instances of the `RippleAPI` class. In xrpl.js 2.x, some methods are static methods of the library and some methods belong to specific classes.
In ripple-lib 1.x all methods and properties were on instances of the `RippleAPI` class. In xrpl.js 2.x, some methods are static methods of the library and some methods belong to specific classes. In the following table, `Client.` means that the method is an
| RippleAPI instance method / property | xrpl.js method / property| Notes |
| RippleAPI instance method / property | xrpl.js method / property | Notes |
|-------------------|----------------|---|
| `new ripple.RippleAPI({server: url})` | `new xrpl.Client(url)` | Use `xrpl.BroadcastClient([url1, url2, ..])` to connect to multiple servers. |
| `request(command, options)` | `Client.request(options)` | <ul><li>The `command` field moved into the `options` object for consistency with the WebSocket API.</li><li>In 1.x the return value of this method (when the Promise resolves) was only the `result` object. Now it returns the whole [WebSocket response format](response-formatting.html); to get the equivalent value, read the `result` field of the return value. |
| `hasNextPage(response)` | `Client.hasNextPage(response)` | See also: `Client.requestNextPage()` and `Client.requestAll()` |
| `requestNextPage(command, options, response)` | `Client.requestNextPage(response)` | |
| `computeBinaryTransactionHash(tx_blob)` | `xrpl.hashes.hashTx(tx_blob)` | |
| `hasNextPage()` | `Client.hasNextPage()` | See also: `Client.requestNextPage()` and `Client.requestAll()` |
| `requestNextPage()` | `Client.requestNextPage()` | |
| `computeBinaryTransactionHash()` | `xrpl.hashes.hashTx()` | |
| `classicAddressToXAddress()` | `xrpl.classicAddressToXAddress()` | Now a static method on the module. |
| `xAddressToClassicAddress()` | `xrpl.xAddressToClassicAddress()` | Now a static method on the module. |
| `renameCounterpartyToIssuer(object)` | (None) | No longer needed because xrpl.js always uses `issuer` already. |
| `formatBidsAndAsks(base, counter)` | (None) | No longer needed after changes to `getOrderbook()`. |
| `renameCounterpartyToIssuer(object)` | (Removed) | No longer needed because xrpl.js always uses `issuer` already. |
| `formatBidsAndAsks()` | (Removed) | No longer needed after changes to `getOrderbook()`. |
| `connect()` | `Client.connect()` | |
| `disconnect()` | `Client.disconnect()` | |
| `isConnected()` | `Client.isConnected()` | |
| `getServerInfo()` | `Client.request({command: "server_info"})` | Request/response match the [server_info method][] exactly. |
| `getFee()` | `Client.getFee()` | Returns a value in decimal XRP; if use this when constructing transactions be sure to convert to integer _drops of XRP_ instead. |
| `getServerInfo()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [server_info method][] instead. |
| `getFee()` | (Removed) | Use `Client.autofill()` to provide a sensible [transaction cost][] automatically, or use `Client.request({"command": "fee"})` to look up information about the current transaction cost (in _drops of XRP_). |
| `getLedgerVersion()` | `Client.getLedgerIndex()` | |
| `getTransaction(hash)` | `Client.request({command: "tx", transaction: hash})` | Request/response match the [tx method][] exactly. **Warning:** Unlike `getTransaction()`, the `tx` method can return [results that are not validated and final](#validated-results). Be sure to look for `"validated": true` in the response object before taking action in response to a transaction. |
| `getTransactions(address, options)` | `Client.request({"command": "account_tx", ..})` | Request/response match the [account_tx method][] exactly. |
| `getTrustlines(address, options)` | `Client.request({"command": "account_lines", "ledger_index": "validated", ...})` | Request/response match the [account_lines method][] exactly. **Warning:** Unlike `getTrustlines()`, `account_lines` can return [results that are not validated and final](#validated-results). |
| `getBalances(address, options)` | `Client.getBalances(address, options)` | |
| `getBalanceSheet(address, options)` | (None) | Removed. Use `.getBalances()` instead. |
| `getPaths(options)` | `Client.request({"command": "ripple_path_find", ...})` | Request/response match the [ripple_path_find method][] exactly. |
| `getOrders(address, options)` | `Client.request({"command": "account_offers", "account": address, ...})` | Request/response match the [account_offers method][] exactly. |
| `getOrderbook(address, orderbook, options)` | `Client.getOrderbook(takerPays, takerGets, options)` | |
| `getSettings(address, options)` | `Client.request({"command": "account_info", "account": address, "ledger_index": "validated", ...})` | Use ***TODO: parseAccountRootFlags mention*** on the `Flags` field. **Warning:** Unlike `getTrustlines()`, `account_lines` can return [results that are not validated and final](#validated-results). |
| `getAccountInfo(address, options)` | | |
| `getAccountObjects(address, options)` | | |
| `getPaymentChannel(id)` | | |
| `getLedger(options)` | | |
| `parseAccountFlags(number)` | ***TBD parseAccountRootFlags*** | |
| `prepareTransaction(transaction, instructions)` | `Client.autofill(tx_json)` | ***TODO: maybe demonstrate how to mimic `maxLedgerVersionOffset`?*** |
| `preparePayment(address, payment, instructions)` | `Client.autofill(tx_json)` | Construct a [Payment transaction][] instead. |
| `prepareTrustline(address, trustline, instructions)` | `Client.autofill(tx_json)` | Construct a [TrustSet transaction][] instead. |
| `prepareOrder(address, order, instructions)` | `Client.autofill(tx_json)` | Construct an [OfferCreate transaction][] instead. |
| `prepareOrderCancellation(address, orderCancellation, instructions)` | `Client.autofill(tx_json)` | Construct an [OfferCancel transaction][] instead. |
| `prepareSettings(address, settings, instructions)` | `Client.autofill(tx_json)` | For most settings, construct an [AccountSet transaction][] instead. To rotate change a regular key, construct a [RegularKeySet transaction][]. To add or update multi-signing settings, construct a [SignerListSet transaction][] instead. |
| `prepareEscrowCreation(address, escrowCreation, instructions)` | `Client.autofill(tx_json)` | Construct an [EscrowCreate transaction][] instead. |
| `prepareEscrowCancellation(address, escrowCancellation, instructions)` | `Client.autofill(tx_json)` | Construct an [EscrowCancel transaction][] instead. |
| `prepareEscrowExecution(address, escrowExecution, instructions)` | `Client.autofill(tx_json)` | Construct an [EscrowFinish transaction][] instead. |
| `preparePaymentChannelCreate(address, paymentChannelCreate, instructions)` | `Client.autofill(tx_json)` | Construct a [PaymentChannelCreate transaction][] instead. |
| `preparePaymentChannelClaim(address, paymentChannelClaim, instructions)` | `Client.autofill(tx_json)` | Construct a [PaymentChannelClaim transaction][] instead. |
| `preparePaymentChannelFund(address, paymentChannelFund, instructions)` | `Client.autofill(tx_json)` | Construct a [PaymentChannelFund transaction][] instead. |
| `prepareCheckCreate(address, checkCreate, instructions)` | `Client.autofill(tx_json)` | Construct a [CheckCreate transaction][] instead. |
| `prepareCheckCancel(address, checkCancel, instructions)` | `Client.autofill(tx_json)` | Construct a [CheckCancel transaction][] instead. |
| `prepareCheckCash(address, checkCash, instructions)` | `Client.autofill(tx_json)` | Construct a [CheckCash transaction][] instead. |
| `prepareTicketCreate(address, ticketCount, instructions)` | `Client.autofill(tx_json)` | Construct a [TicketCreate transaction][] instead. |
| `sign(txJSON_string, secret, options)` | `Wallet.sign(tx_json)` | ***TODO: link summary of Wallet class.*** |
| `combine(signedTransactions)` | [`xrpl.multisign(signedTransactions)`](https://js.xrpl.org/modules.html#multisign) | |
| `submit(tx_blob)` | `Client.submit(tx_blob)` | Reliable transaction submission is now also available; for details, see [Transaction Submission](#transaction-submission). |
| `generateXAddress(options)` | `xrpl.generateXAddress(options)` | Now a static method on the module. |
| `generateAddress(options)` | (Removed) | Use `generateXAddress(options)` instead. |
| `isValidAddress(address)` | `xrpl.isValidAddress(address)` | Now a static method on the module. |
| `isValidSecret(secret)` | `xrpl.isValidSecret(secret)` | Now a static method on the module. |
| `deriveKeypair()`
| `deriveAddress()`
| `generateFaucetWallet()`
| `signPaymentChannelClaim()`
| `verifyPaymentChannelClaim()`
| `computeLedgerHash()`
| `xrpToDrops()`
| `dropsToXrp()`
| `iso8601ToRippleTime(timestamp)` | `ISOTimeToRippleTime(timestamp)` | Now a static method at the `xrpl` module level. | `rippleTimeToISO8601()`
| `txFlags`
| `accountSetFlags`
| `schemaValidator`
| `schemaValidate()`
| `.on("ledger", callback)` | `Client.on("ledgerClosed", callback)` | **Caution:** Must also subscribe to the ledger stream. For examples and details, see [Events and Subscriptions](#vents-and-subscriptions). |
| `getTransaction()` | `Client.request()` | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [tx method][] instead. **Warning:** Unlike `getTransaction()`, the `tx` method can return [results that are not validated and final](#validated-results). Be sure to look for `"validated": true` in the response object before taking action in response to a transaction. |
| `getTransactions()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [account_tx method][] instead. |
| `getTrustlines()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call [account_lines method][] instead. **Warning:** Unlike `getTrustlines()`, `account_lines` can return [results that are not validated and final](#validated-results). |
| `getBalances()` | `Client.getBalances(address, options)` | |
| `getBalanceSheet()` | (Removed) | Use `Client.getBalances()` instead, or use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [gateway_balances method][]. |
| `getPaths()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call [ripple_path_find method][] instead. |
| `getOrders()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [account_offers method][] instead. |
| `getOrderbook()` | `Client.getOrderbook()` | |
| `getSettings()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [account_info method][] instead. Use `xrpl.parseAccountRootFlags()` on the `Flags` field to get the boolean values of individual flag settings. **Warning:** Unlike `getSettings()`, `account_info` can return [results that are not validated and final](#validated-results). |
| `getAccountInfo(address, options)` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [account_info method][] instead. **Warning:** Unlike `getAccountInfo()`, `account_info` can return [results that are not validated and final](#validated-results). |
| `getAccountObjects(address, options)` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [account_info method][] instead. **Warning:** Unlike `getAccountObjects()`, `account_objects` can return [results that are not validated and final](#validated-results). |
| `getPaymentChannel()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [ledger_entry method](ledger_entry.html#get-paychannel-object) instead. **Warning:** Unlike `getPaymentChannel()`, `ledger_entry` can return [results that are not validated and final](#validated-results). |
| `getLedger()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [ledger method][] exactly. **Warning:** Unlike `getLedger()`, `ledger` can return [ledgers that are not validated and final](#validated-results). |
| `parseAccountFlags()` | `xrpl.parseAccountRootFlags()` | Now a static method on the module. |
| `prepareTransaction()` | `Client.autofill()` | See [Transaction Submission](#transaction-submission) for details. |
| `preparePayment()` | (Removed) | Construct a [Payment transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareTrustline()` | (Removed) | Construct a [TrustSet transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareOrder()` | (Removed) | Construct an [OfferCreate transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareOrderCancellation()` | (Removed) | Construct an [OfferCancel transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareSettings()` | (Removed) | For most settings, construct an [AccountSet transaction][] instead. To rotate change a regular key, construct a [SetRegularKey transaction][]. To add or update multi-signing settings, construct a [SignerListSet transaction][] instead. In all three cases, use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) to prepare the transaction. |
| `prepareEscrowCreation()` | (Removed) | Construct an [EscrowCreate transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareEscrowCancellation()` | (Removed) | Construct an [EscrowCancel transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareEscrowExecution()` | (Removed) | Construct an [EscrowFinish transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `preparePaymentChannelCreate()` | (Removed) | Construct a [PaymentChannelCreate transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `preparePaymentChannelClaim()` | (Removed) | Construct a [PaymentChannelClaim transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `preparePaymentChannelFund()` | (Removed) | Construct a [PaymentChannelFund transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareCheckCreate()` | (Removed) | Construct a [CheckCreate transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareCheckCancel()` | (Removed) | Construct a [CheckCancel transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareCheckCash()` | (Removed) | Construct a [CheckCash transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `prepareTicketCreate()` | (Removed) | Construct a [TicketCreate transaction][] and use [`Client.autofill()`](https://js.xrpl.org/classes/Client.html#autofill) instead. |
| `sign()` | `Wallet.sign()` | See [Keys and Wallets](#keys-and-wallets) for details. |
| `combine()` | [`xrpl.multisign()`](https://js.xrpl.org/modules.html#multisign) | |
| `submit()` | `Client.submit()` | Reliable transaction submission is now also available; for details, see [Transaction Submission](#transaction-submission). |
| `generateXAddress()` | `xrpl.generateXAddress()` | Now a static method on the module. |
| `generateAddress()` | (Removed) | Use `generateXAddress()` instead. |
| `isValidAddress()` | `xrpl.isValidAddress()` | Now a static method on the module. |
| `isValidSecret()` | `xrpl.isValidSecret()` | Now a static method on the module. |
| `deriveKeypair()` | `xrpl.deriveKeypair()` | Now a static method on the module. |
| `deriveAddress()` | `xrpl.deriveAddress()` | Now a static method on the module. |
| `generateFaucetWallet()` | `Client.fundWallet()` | The `on_testnet` boolean has been removed; the library automatically picks the Devnet or Testnet faucet as appropriate for the network you're connected to. You can optionally provide a [`Wallet` instance](https://js.xrpl.org/classes/Wallet.html) to have the faucet fund/refill the associated address; otherwise, the method creates a new Wallet instance. The return value now resolves to an object in the form `{wallet: <object: Wallet instance>, balance: <str: drops of XRP>}` |
| `signPaymentChannelClaim()` | `xrpl.signPaymentChannelClaim()` | Now a static method on the module. |
| `verifyPaymentChannelClaim()` | `xrpl.verifyPaymentChannelClaim()` | Now a static method on the module. |
| `computeLedgerHash()` | `xrpl.hashes.hashLedger()` | |
| `xrpToDrops()` | `xrpl.xrpToDrops()` | Now a static method on the module. |
| `dropsToXrp()` | `xrpl.dropsToXrp()` | Now a static method on the module. |
| `iso8601ToRippleTime()` | `xrpl.ISOTimeToRippleTime()` | Now a static method on the module. |
| `rippleTimeToISO8601()` | `xrpl.rippleTimeToISOTime()` | Now a static method on the module. You can also use the new method [`rippleTimeToUnixTime()`](https://js.xrpl.org/modules.html#rippleTimeToUnixTime) to get a UNIX-style timestamp in milliseconds since the UNIX epoch of 1970-01-01 00:00:00 UTC. |
| `txFlags.Universal.FullyCanonicalSig` | (Removed) | No longer needed following the [RequireFullyCanonicalSig amendment][]. |
| `txFlags.Payment.NoRippleDirect` | `xrpl.PaymentFlags.tfNoDirectRipple` | |
| `txFlags.Payment.PartialPayment` | `xrpl.PaymentFlags.tfPartialPayment` | |
| `txFlags.Payment.LimitQuality` | `xrpl.PaymentFlags.tfLimitQuality` | |
| `txFlags.OfferCreate.Passive` | `xrpl.OfferCreateFlags.tfPassive` | |
| `txFlags.OfferCreate.ImmediateOrCancel` | `xrpl.OfferCreateFlags.tfImmediateOrCancel` | |
| `txFlags.OfferCreate.FillOrKill` | `xrpl.OfferCreateFlags.tfFillOrKill` | |
| `txFlags.OfferCreate.Sell` | `xrpl.OfferCreateFlags.tfSell` | |
| `accountSetFlags` | `xrpl.AccountSetAsfFlags` | Now an Enum at the module level. |
| `schemaValidator` | (Removed) | Use TypeScript to validate most types. |
| `schemaValidate()` | (Removed) | Use TypeScript to validate most types. You can also call `xrpl.validate(transaction)` to validate transaction objects. |
| `.on("ledger", callback)` | `Client.on("ledgerClosed", callback)` | **Caution:** Must also subscribe to the ledger stream. For examples and details, see [Events and Subscriptions](#events-and-subscriptions). |
| `.on("error", callback)` | `Client.on("error", callback)` | |
| `.on("connected", callback)`
| `.on("disconnected", callback)`
| `.on("connected", callback)` | `Client.on("connected", callback)` | |
| `.on("disconnected", callback)` | `Client.on("connected", callback)` | |
<!--{# common link defs #}-->

4
content/tutorials/get-started/get-started-using-java.md
View File

@@ -21,7 +21,7 @@ This tutorial walks you through the basics of building a very simple XRP Ledger-
This tutorial is intended for beginners and should take no longer than 30 minutes to complete.
## Learning goals
## Learning Goals
In this tutorial, you'll learn:
@@ -73,7 +73,7 @@ To install with Maven, add the following to your project's `pom.xml` file and th
Check out the [xrpl4j sample project](https://github.com/XRPLF/xrpl4j-sample) for a full Maven project containing the code from this tutorial.
## Start building
## Start Building
{% set n = cycler(* range(1,99)) %}
When you're working with the XRP Ledger, there are a few things you'll need to manage, whether you're adding XRP into your [wallet](wallets.html), integrating with the [decentralized exchange](decentralized-exchange.html), or [issuing tokens](issued-currencies.html). This tutorial walks you through basic patterns common to getting started with all of these use cases and provides sample code for implementing them.

10
content/tutorials/get-started/get-started-using-javascript.md
View File

@@ -17,7 +17,7 @@ This tutorial guides you through the basics of building an XRP Ledger-connected
The scripts and config files used in this guide are [available in this website's GitHub Repository]({{target.github_forkurl}}/tree/{{target.github_branch}}/content/_code-samples/get-started/js/).
## Learning goals
## Learning Goals
In this tutorial, you'll learn:
@@ -42,13 +42,13 @@ npm install xrpl
```
## Start building
## Start Building
When you're working with the XRP Ledger, there are a few things you'll need to manage, whether you're adding XRP into your [wallet](wallets.html), integrating with the [decentralized exchange](decentralized-exchange.html), or [issuing tokens](issued-currencies.html). This tutorial walks you through basic patterns common to getting started with all of these use cases and provides sample code for implementing them.
Here are some steps you use in many XRP Ledger projects:
1. [Import the library](#1-import-the-library)
1. [Import the library.](#1-import-the-library)
1. [Connect to the XRP Ledger.](#2-connect-to-the-xrp-ledger)
1. [Generate a wallet.](#3-generate-wallet)
1. [Query the XRP Ledger.](#4-query-the-xrp-ledger)
@@ -95,9 +95,9 @@ To make queries and submit transactions, you need to establish a connection to t
{{ include_code("_code-samples/get-started/js/base.js", language="js") }}
#### Connect to the production XRP Ledger
#### Connect to the XRP Ledger Mainnet
The sample code in the previous section shows you how to connect to the Testnet, which is one of the available [parallel networks](parallel-networks.html). When you're ready to integrate with the production XRP Ledger, you'll need to connect to the Mainnet. You can do that in two ways:
The sample code in the previous section shows you how to connect to the Testnet, which is one of the available [parallel networks](parallel-networks.html). When you're ready to move to production, you'll need to connect to the XRP Ledger Mainnet. You can do that in two ways:
* By [installing the core server](install-rippled.html) (`rippled`) and running a node yourself. The core server connects to the Mainnet by default, but you can [change the configuration to use Testnet or Devnet](connect-your-rippled-to-the-xrp-test-net.html). [There are good reasons to run your own core server](the-rippled-server.html#reasons-to-run-your-own-server). If you run your own server, you can connect to it like so:

4
content/tutorials/get-started/get-started-using-python.md
View File

@@ -18,7 +18,7 @@ This tutorial walks you through the basics of building a very simple XRP Ledger-
This tutorial is intended for beginners and should take no longer than 30 minutes to complete.
## Learning goals
## Learning Goals
In this tutorial, you'll learn:
@@ -42,7 +42,7 @@ The [`xrpl-py` library](https://github.com/XRPLF/xrpl-py) is available on [PyPI]
pip3 install xrpl-py
```
## Start building
## Start Building
{% set n = cycler(* range(1,99)) %}
When you're working with the XRP Ledger, there are a few things you'll need to manage, whether you're adding XRP into your [wallet](wallets.html), integrating with the [decentralized exchange](decentralized-exchange.html), or [issuing tokens](issued-currencies.html). This tutorial walks you through basic patterns common to getting started with all of these use cases and provides sample code for implementing them.

14
content/tutorials/get-started/get-started.md
View File

@@ -27,12 +27,12 @@ async function main() {
let response = await api.request({
"command": "ledger",
"ledger_index": "validated"
"ledger_index": "validated",
"transactions": true
});
console.log(response);
}
main()
main();
```
```js
@@ -42,12 +42,12 @@ async function main() {
let response = await api.request({
"command": "ledger",
"ledger_index": "validated"
"ledger_index": "validated",
"transactions": true
});
console.log(response);
}
main()
main();
```
```js
@@ -68,7 +68,7 @@ async function main() {
});
console.log(response2);
}
main()
main();
```
```js
@@ -78,12 +78,12 @@ async function main() {
let response = await api.request({
"command": "ledger",
"ledger_index": "validated"
"ledger_index": "validated",
"transactions": true
});
console.log('Total XRP: '+xrpl.dropsToXrp(response.result.ledger.total_coins));
}
main()
main();
```
<!-- JS_EDITOR_END -->

2
content/tutorials/production-readiness/reliable-transaction-submission.md
View File

@@ -36,7 +36,7 @@ If a power or network outage occurs, applications face more challenges finding t
### Transaction Timeline
When you submit a transaction to the XRP Ledger, regardless of whether used [HTTP API](rippled-api.html), a [client library](client-libraries.html), or some other app, process of applying the transaction to the ledger is the same. That process goes like this:
When you submit a transaction to the XRP Ledger, regardless of whether you used [HTTP API](rippled-api.html), a [client library](client-libraries.html), or some other app, process of applying the transaction to the ledger is the same. That process goes like this:
1. An account owner creates and signs a transaction.
2. The owner submits the transaction to the network as a candidate transaction.

2
content/tutorials/use-tokens/freeze-a-trust-line.md
View File

@@ -167,7 +167,7 @@ Example Response:
### {{n.next()}}. (Optional) Send TrustSet Transaction to End the Freeze
If you decide that the trust line no longer needs to be frozen (for example, you investigated and decided that the suspicious activity was benign), you can end the individual freeze in much the same way that you froze the trust line in the first place. To end an individual freeze, send a [TrustSet transaction][] with the [`tfClearFreeze` flag enabled](trustset.html#trustset-flags). The other fields of the transaction should be the same as when you froze the trust line:
If you decide that the trust line no longer needs to be frozen (for example, you investigated and decided that the suspicious activity was benign), you can end the individual freeze in almost the same way that you froze the trust line in the first place. To end an individual freeze, send a [TrustSet transaction][] with the [`tfClearFreeze` flag enabled](trustset.html#trustset-flags). The other fields of the transaction should be the same as when you froze the trust line:
| Field | Value | Description |
|--------------------------|--------|-------------|