ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-21 12:15:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

xrpl.js 2.0 edits per review, more cleanup

Browse Source
This commit is contained in:
mDuo13
2021-10-20 12:43:56 -07:00
parent 12eff02bc6
commit 84d540a122
12 changed files with 79 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -58,7 +58,7 @@ By default, most methods in ripple-lib 1.x only returned results that were valid
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. 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 the latest _validated ledger_: When making API requests with xrpl.js 2.0 using `Client.request()`, 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:** **ripple-lib 1.x:**
@@ -81,7 +81,12 @@ console.log(trustlines.result)
## Transaction Submission ## Transaction Submission
In xrpl.js there are specific helper functions for signing and submitting transactions and waiting for the XRP Ledger blockchain to confirm those transactions' final outcomes. Use the `submitAndWait(tx_json, wallet)` method to sign a prepared transaction with the given wallet and submit it, like in this example: In xrpl.js there are specific helper functions for signing and submitting transactions and waiting for the XRP Ledger blockchain to confirm those transactions' final outcomes. Options
- Use `submitAndWait()` to submit a transaction and wait for its [final outcome](finality-of-results.html). If the transaction becomes validated, this resolves to a [tx method][] response; otherwise, it raises an exception.
- Use `submit()` to submit and return immediately. This resolves to a [submit method][] response, which shows the preliminary (non-final) result. This method only raises an exception if there was a problem sending the transaction to the XRP Ledger server.
For both methods, you can pass a signed transaction to the method directly, or you can sign the transaction right before submitting, by passing prepared transaction instructions and a [`Wallet` instance](#keys-and-wallets).
```js ```js
const tx_json = await client.autofill({ const tx_json = await client.autofill({
@@ -93,6 +98,7 @@ try {
const submit_result = await client.submitAndWait(tx_json, wallet) const submit_result = await client.submitAndWait(tx_json, wallet)
// submitAndWait() doesn't return until the transaction has a final result. // submitAndWait() doesn't return until the transaction has a final result.
// Raises XrplError if the transaction doesn't get confirmed by the network. // Raises XrplError if the transaction doesn't get confirmed by the network.
// Does not handle disaster recovery.
console.log("Transaction result:", submit_result) console.log("Transaction result:", submit_result)
} catch(err) { } catch(err) {
console.log("Error submitting transaction:", err) console.log("Error submitting transaction:", err)
@@ -217,6 +223,8 @@ client.request({
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, the notation `Client.method()` means that `method()` belongs to instances of the `Client` class. 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, the notation `Client.method()` means that `method()` belongs to instances of the `Client` class.
**Note: The following table has 3 columns. You may need to scroll horizontally to see all the information.**
| 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. | | `new ripple.RippleAPI({server: url})` | `new xrpl.Client(url)` | Use `xrpl.BroadcastClient([url1, url2, ..])` to connect to multiple servers. |
@@ -226,49 +234,49 @@ In ripple-lib 1.x all methods and properties were on instances of the `RippleAPI
| `computeBinaryTransactionHash()` | `xrpl.hashes.hashTx()` | | | `computeBinaryTransactionHash()` | `xrpl.hashes.hashTx()` | |
| `classicAddressToXAddress()` | `xrpl.classicAddressToXAddress()` | Now a static method on the module. | | `classicAddressToXAddress()` | `xrpl.classicAddressToXAddress()` | Now a static method on the module. |
| `xAddressToClassicAddress()` | `xrpl.xAddressToClassicAddress()` | Now a static method on the module. | | `xAddressToClassicAddress()` | `xrpl.xAddressToClassicAddress()` | Now a static method on the module. |
| `renameCounterpartyToIssuer(object)` | (Removed) | No longer needed because xrpl.js always uses `issuer` already. | | `renameCounterpartyToIssuer(object)` | (Removed - see Notes column) | No longer needed because xrpl.js always uses `issuer` already. |
| `formatBidsAndAsks()` | (Removed) | No longer needed after changes to `getOrderbook()`. | | `formatBidsAndAsks()` | (Removed - see Notes column) | No longer needed after changes to `getOrderbook()`. |
| `connect()` | `Client.connect()` | | | `connect()` | `Client.connect()` | |
| `disconnect()` | `Client.disconnect()` | | | `disconnect()` | `Client.disconnect()` | |
| `isConnected()` | `Client.isConnected()` | | | `isConnected()` | `Client.isConnected()` | |
| `getServerInfo()` | (Removed) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [server_info method][] instead. | | `getServerInfo()` | (Removed - see Notes column) | 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_). | | `getFee()` | (Removed - see Notes column) | 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()` | | | `getLedgerVersion()` | `Client.getLedgerIndex()` | |
| `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. | | `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. | | `getTransactions()` | (Removed - see Notes column) | 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). | | `getTrustlines()` | (Removed - see Notes column) | 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)` | | | `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][]. | | `getBalanceSheet()` | (Removed - see Notes column) | 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. | | `getPaths()` | (Removed - see Notes column) | 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. | | `getOrders()` | (Removed - see Notes column) | Use [`Client.request()`](https://js.xrpl.org/classes/Client.html#request) to call the [account_offers method][] instead. |
| `getOrderbook()` | `Client.getOrderbook()` | | | `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). | | `getSettings()` | (Removed - see Notes column) | 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). | | `getAccountInfo(address, options)` | (Removed - see Notes column) | 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). | | `getAccountObjects(address, options)` | (Removed - see Notes column) | 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). | | `getPaymentChannel()` | (Removed - see Notes column) | 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). | | `getLedger()` | (Removed - see Notes column) | 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. | | `parseAccountFlags()` | `xrpl.parseAccountRootFlags()` | Now a static method on the module. |
| `prepareTransaction()` | `Client.autofill()` | See [Transaction Submission](#transaction-submission) for details. | | `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. | | `preparePayment()` | (Removed - see Notes column) | 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. | | `prepareTrustline()` | (Removed - see Notes column) | 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. | | `prepareOrder()` | (Removed - see Notes column) | 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. | | `prepareOrderCancellation()` | (Removed - see Notes column) | 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. | | `prepareSettings()` | (Removed - see Notes column) | 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. | | `prepareEscrowCreation()` | (Removed - see Notes column) | 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. | | `prepareEscrowCancellation()` | (Removed - see Notes column) | 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. | | `prepareEscrowExecution()` | (Removed - see Notes column) | 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. | | `preparePaymentChannelCreate()` | (Removed - see Notes column) | 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. | | `preparePaymentChannelClaim()` | (Removed - see Notes column) | 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. | | `preparePaymentChannelFund()` | (Removed - see Notes column) | 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. | | `prepareCheckCreate()` | (Removed - see Notes column) | 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. | | `prepareCheckCancel()` | (Removed - see Notes column) | 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. | | `prepareCheckCash()` | (Removed - see Notes column) | 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. | | `prepareTicketCreate()` | (Removed - see Notes column) | 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. | | `sign()` | `Wallet.sign()` | See [Keys and Wallets](#keys-and-wallets) for details. |
| `combine()` | [`xrpl.multisign()`](https://js.xrpl.org/modules.html#multisign) | | | `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). | | `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. | | `generateXAddress()` | `xrpl.generateXAddress()` | Now a static method on the module. |
| `generateAddress()` | (Removed) | Use `generateXAddress()` instead. | | `generateAddress()` | (Removed - see Notes column) | Use `generateXAddress()` instead. |
| `isValidAddress()` | `xrpl.isValidAddress()` | Now a static method on the module. | | `isValidAddress()` | `xrpl.isValidAddress()` | Now a static method on the module. |
| `isValidSecret()` | `xrpl.isValidSecret()` | 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. | | `deriveKeypair()` | `xrpl.deriveKeypair()` | Now a static method on the module. |
@@ -281,7 +289,7 @@ In ripple-lib 1.x all methods and properties were on instances of the `RippleAPI
| `dropsToXrp()` | `xrpl.dropsToXrp()` | 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. | | `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. | | `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.Universal.FullyCanonicalSig` | (Removed - see Notes column) | No longer needed following the [RequireFullyCanonicalSig amendment][]. |
| `txFlags.Payment.NoRippleDirect` | `xrpl.PaymentFlags.tfNoDirectRipple` | | | `txFlags.Payment.NoRippleDirect` | `xrpl.PaymentFlags.tfNoDirectRipple` | |
| `txFlags.Payment.PartialPayment` | `xrpl.PaymentFlags.tfPartialPayment` | | | `txFlags.Payment.PartialPayment` | `xrpl.PaymentFlags.tfPartialPayment` | |
| `txFlags.Payment.LimitQuality` | `xrpl.PaymentFlags.tfLimitQuality` | | | `txFlags.Payment.LimitQuality` | `xrpl.PaymentFlags.tfLimitQuality` | |
@@ -290,8 +298,8 @@ In ripple-lib 1.x all methods and properties were on instances of the `RippleAPI
| `txFlags.OfferCreate.FillOrKill` | `xrpl.OfferCreateFlags.tfFillOrKill` | | | `txFlags.OfferCreate.FillOrKill` | `xrpl.OfferCreateFlags.tfFillOrKill` | |
| `txFlags.OfferCreate.Sell` | `xrpl.OfferCreateFlags.tfSell` | | | `txFlags.OfferCreate.Sell` | `xrpl.OfferCreateFlags.tfSell` | |
| `accountSetFlags` | `xrpl.AccountSetAsfFlags` | Now an Enum at the module level. | | `accountSetFlags` | `xrpl.AccountSetAsfFlags` | Now an Enum at the module level. |
| `schemaValidator` | (Removed) | Use TypeScript to validate most types. | | `schemaValidator` | (Removed - see Notes column) | 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. | | `schemaValidate()` | (Removed - see Notes column) | 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("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("error", callback)` | `Client.on("error", callback)` | |
| `.on("connected", callback)` | `Client.on("connected", callback)` | | | `.on("connected", callback)` | `Client.on("connected", callback)` | |

2
content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
View File

@@ -13,7 +13,7 @@ labels:
WebSocketは、クライアントとサーバーが1つの接続を確立し、その接続を経由して両方向にメッセージを送信するモデルに従います。この接続は、明示的に閉じる（または接続に障害が発生する）まで続きます。これは、要求ごとにクライアントが新しい接続を開いて閉じるHTTPベースのAPIモデル（JSON-RPCやRESTful APIなど）とは対照的です[¹](#footnote-1)<a id="from-footnote-1"></a>。 WebSocketは、クライアントとサーバーが1つの接続を確立し、その接続を経由して両方向にメッセージを送信するモデルに従います。この接続は、明示的に閉じる（または接続に障害が発生する）まで続きます。これは、要求ごとにクライアントが新しい接続を開いて閉じるHTTPベースのAPIモデル（JSON-RPCやRESTful APIなど）とは対照的です[¹](#footnote-1)<a id="from-footnote-1"></a>。
**ヒント:** このページの例はJavaScriptを使用しているため、Webブラウザーでネイティブに実行できます。JavaScriptで開発している場合は、[JavaScript向けRippleAPIライブラリ](https://js.xrpl.org/)も利用すると、一部の作業を簡素化できます。このチュートリアルでは、RippleAPIを使用できないその他のプログラミング言語にステップを適合できるよう、xrpl.jsを使用 _しない_ でトランザクションを監視する方法を説明します。 **ヒント:** このページの例はJavaScriptを使用しているため、Webブラウザーでネイティブに実行できます。JavaScriptで開発している場合は、[JavaScript向けxrpl.jsライブラリ](https://js.xrpl.org/)も利用すると、一部の作業を簡素化できます。このチュートリアルでは、xrpl.jsを使用できないその他のプログラミング言語にステップを適合できるよう、xrpl.jsを使用 _しない_ でトランザクションを監視する方法を説明します。
## 前提条件 ## 前提条件

2
content/tutorials/manage-account-settings/require-destination-tags.ja.md
View File

@@ -7,7 +7,7 @@ labels:
--- ---
# 宛先タグの要求 # 宛先タグの要求
`RequireDest`設定（RippleAPIの`requireDestinationTag`）は、送金先を識別する[宛先タグ](source-and-destination-tags.html)を顧客が付け忘れている場合にあなたのアドレスに[送金](payment-types.html)できないようにするためのものです。有効にすると、XRP Ledgerは宛先タグが付いていないあなたのアドレスへの送金を拒否します。 `RequireDest`設定は、送金先を識別する[宛先タグ](source-and-destination-tags.html)を顧客が付け忘れている場合にあなたのアドレスに[送金](payment-types.html)できないようにするためのものです。有効にすると、XRP Ledgerは宛先タグが付いていないあなたのアドレスへの送金を拒否します。
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、`RequireDest`フラグを有効にする[AccountSetトランザクション][]を送信する例です。 以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、`RequireDest`フラグを有効にする[AccountSetトランザクション][]を送信する例です。

4
content/tutorials/manage-account-settings/use-tickets.md
View File

@@ -22,7 +22,7 @@ _(Requires the [TicketBatch amendment][] :not_enabled:)_
<script type="application/javascript" src="assets/js/tutorials/use-tickets.js"></script> <script type="application/javascript" src="assets/js/tutorials/use-tickets.js"></script>
{% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually --> {% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually -->
This page provides JavaScript examples that use the ripple-lib (RippleAPI) library. The [RippleAPI Beginners Guide](get-started-with-rippleapi-for-javascript.html) describes how to get started using RippleAPI to access XRP Ledger data from JavaScript. This page provides JavaScript examples that use the [xrpl.js](https://js.xrpl.org/) library. See [Get Started Using JavaScript](get-started-using-javascript.html) for setup instructions.
Since JavaScript works in the web browser, you can read along and use the interactive steps without any setup. Since JavaScript works in the web browser, you can read along and use the interactive steps without any setup.
@@ -133,8 +133,6 @@ _JavaScript_
Most transactions are accepted into the next ledger version after they're submitted, which means it may take 4-7 seconds for a transaction's outcome to be final. If the XRP Ledger is busy or poor network connectivity delays a transaction from being relayed throughout the network, a transaction may take longer to be confirmed. (For information on how to set an expiration for transactions, see [Reliable Transaction Submission](reliable-transaction-submission.html).) Most transactions are accepted into the next ledger version after they're submitted, which means it may take 4-7 seconds for a transaction's outcome to be final. If the XRP Ledger is busy or poor network connectivity delays a transaction from being relayed throughout the network, a transaction may take longer to be confirmed. (For information on how to set an expiration for transactions, see [Reliable Transaction Submission](reliable-transaction-submission.html).)
You use the `ledger` event type in RippleAPI to trigger your code to run whenever there is a new validated ledger version. For example:
<!-- MULTICODE_BLOCK_START --> <!-- MULTICODE_BLOCK_START -->
_JavaScript_ _JavaScript_

1
content/tutorials/manage-the-rippled-server/configuration/configure-grpc.md
View File

@@ -49,7 +49,6 @@ To enable gRPC on your server, complete the following steps:
- [Software Ecosystem](software-ecosystem.html) - [Software Ecosystem](software-ecosystem.html)
- [Parallel Networks](parallel-networks.html) - [Parallel Networks](parallel-networks.html)
- **Tutorials:** - **Tutorials:**
- [Get Started with RippleAPI for JavaScript](get-started-with-rippleapi-for-javascript.html)
- [Reliable Transaction Submission](reliable-transaction-submission.html) - [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Manage the rippled Server](manage-the-rippled-server.html) - [Manage the rippled Server](manage-the-rippled-server.html)
- **References:** - **References:**

4
content/tutorials/manage-the-rippled-server/configuration/enable-public-signing.md
View File

@@ -44,8 +44,8 @@ To enable public signing, perform the following steps:
- [Cryptographic Keys](cryptographic-keys.html) - [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:** - **Tutorials:**
- [Set Up Secure Signing](set-up-secure-signing.html) - [Set Up Secure Signing](set-up-secure-signing.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html) - [Get Started Using HTTP / WebSocket APIs](get-started-using-http-websocket-apis.html)
- [Get Started with RippleAPI for JavaScript](get-started-with-rippleapi-for-javascript.html) - [Get Started Using JavaScript](get-started-using-javascript.html)
- **References:** - **References:**
- [sign method][] - [sign method][]
- [sign_for method][] - [sign_for method][]

20
content/tutorials/production-readiness/set-up-secure-signing.ja.md
View File

@@ -84,14 +84,30 @@ Rippleが公開したものでないクライアントライブラリを使用
最高レベルのセキュリティを実現するために、クライアントライブラリを安定した最新バージョンの状態に保ってください。 最高レベルのセキュリティを実現するために、クライアントライブラリを安定した最新バージョンの状態に保ってください。
### RippleAPIを使用したローカル署名の例 ### クライアントライブラリを使用したローカル署名の例
以下のサンプルコードは、RippleAPI for JavaScriptを使用してトランザクションの指示にローカルで署名する方法を示しています。 <!-- MULTICODE_BLOCK_START -->
*JavaScript*
```js ```js
{% include '_code-samples/secure-signing/js/signPayment.js' %} {% include '_code-samples/secure-signing/js/signPayment.js' %}
``` ```
*Python*
```py
{% include '_code-samples/secure-signing/py/sign-payment.py' %}
```
*Java*
```java
{% include '_code-samples/secure-signing/java/SignPayment.java' %}
```
<!-- MULTICODE_BLOCK_END -->
セキュリティを強化するために、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。 セキュリティを強化するために、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。

2
content/tutorials/production-readiness/set-up-secure-signing.md
View File

@@ -91,7 +91,7 @@ To optimize the security of your signing library:
Here are examples of how to sign transaction instructions locally using the following languages and libraries: Here are examples of how to sign transaction instructions locally using the following languages and libraries:
* **JavaScript** / **TypeScript** - [`ripple-lib`](https://github.com/XRPLF/xrpl.js) * **JavaScript** / **TypeScript** - [`xrpl.js`](https://github.com/XRPLF/xrpl.js)
* **Python** - [`xrpl-py`](https://github.com/XRPLF/xrpl-py) * **Python** - [`xrpl-py`](https://github.com/XRPLF/xrpl-py)

5
content/tutorials/use-specialized-payment-types/use-checks/cancel-a-check.ja.md
View File

@@ -22,9 +22,8 @@ _[Checks Amendment][]が必要です。_
- 現在レジャーに記録されているCheckオブジェクトのIDが必要です。 - 現在レジャーに記録されているCheckオブジェクトのIDが必要です。
- たとえばこのチュートリアルの例では、IDが`49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0`のCheckを取り消しますが、この手順を自身で実行する場合は異なるIDを使用する必要があります。 - たとえばこのチュートリアルの例では、IDが`49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0`のCheckを取り消しますが、この手順を自身で実行する場合は異なるIDを使用する必要があります。
- CheckCancelトランザクションを送信する資金供給のあるアカウントの**アドレス**と**シークレットキー**。Checkが有効期限切れでない限り、このアドレスは、Checkの送金元または受取人のいずれかでなければなりません。 - CheckCancelトランザクションを送信する資金供給のあるアカウントの**アドレス**と**シークレットキー**。Checkが有効期限切れでない限り、このアドレスは、Checkの送金元または受取人のいずれかでなければなりません。
- トランザクションに安全に署名できる手段（[RippleAPI][]や各自の[`rippled`サーバー](install-rippled.html)など）。 - トランザクションに[安全に署名できる手段](set-up-secure-signing.html)。
- `rippled`サーバーに接続できるクライアントライブラリ（[RippleAPI][]、HTTPライブラリ、またはWebSocketライブラリなど）。 - [クライアントライブラリ](client-libraries.html)またはHTTPライブラリ、WebSocketライブラリなど。
- 詳細は、[`rippled` APIの使用開始](get-started-using-http-websocket-apis.html)を参照してください。
## {{cancel_n.next()}}.CheckCancelトランザクションの準備 ## {{cancel_n.next()}}.CheckCancelトランザクションの準備

5
content/tutorials/use-specialized-payment-types/use-checks/send-a-check.md
View File

@@ -26,9 +26,8 @@ To send a Check with this tutorial, you need the following:
- The **address** and **secret key** of a funded account to send the Check from. - The **address** and **secret key** of a funded account to send the Check from.
- You can use the [XRP Ledger Test Net Faucet](xrp-test-net-faucet.html) to get a funded address and secret with 10,000 Test Net XRP. - You can use the [XRP Ledger Test Net Faucet](xrp-test-net-faucet.html) to get a funded address and secret with 10,000 Test Net XRP.
- The **address** of a funded account to receive the Check. - The **address** of a funded account to receive the Check.
- A secure way to sign transactions, such as [RippleAPI][] or your own [`rippled` server](install-rippled.html). - A [secure way to sign transactions](set-up-secure-signing.html).
- A client library that can connect to a `rippled` server, such as [RippleAPI][] or any HTTP or WebSocket library. - A [client library](client-libraries.html) or any HTTP or WebSocket library.
- For more information, see [Get Started with the `rippled` API](get-started-using-http-websocket-apis.html).
## {{send_n.next()}}. Prepare the CheckCreate transaction ## {{send_n.next()}}. Prepare the CheckCreate transaction

6
content/tutorials/use-tokens/issue-a-fungible-token.md
View File

@@ -19,9 +19,9 @@ Anyone can issue various types of tokens in the XRP Ledger, ranging from informa
- Each address needs enough XRP to satisfy the [reserve requirement](reserves.html) including the additional reserve for a trust line. - Each address needs enough XRP to satisfy the [reserve requirement](reserves.html) including the additional reserve for a trust line.
- You need a connection to the XRP Ledger network. As shown in this tutorial, you can use public servers for testing. - You need a connection to the XRP Ledger network. As shown in this tutorial, you can use public servers for testing.
- You should be familiar with the Getting Started instructions for your preferred client library. This page provides examples for the following: - You should be familiar with the Getting Started instructions for your preferred client library. This page provides examples for the following:
- ripple-lib for JavaScript [(Node.js)](get-started-with-rippleapi-for-javascript.html) or [in-browser](get-started.html) - **JavaScript** with the [xrpl.js library](https://github.com/XRPLF/xrpl.js/). See [Get Started Using JavaScript](get-started-using-javascript.html) for setup steps.
- [xrpl-py for Python](get-started-using-python.html) - **Python** with the [`xrpl-py` library](https://xrpl-py.readthedocs.io/). See [Get Started using Python](get-started-using-python.html) for setup steps.
- [xrpl4j for Java](get-started-using-java.html). - **Java** with the [xrpl4j library](https://github.com/XRPLF/xrpl4j). See [Get Started Using Java](get-started-using-java.html) for setup steps.
- You can also read along and use the interactive steps in your browser without any setup. - You can also read along and use the interactive steps in your browser without any setup.
<!-- Source for this specific tutorial's interactive bits: --> <!-- Source for this specific tutorial's interactive bits: -->

11
content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md
View File

@@ -463,7 +463,7 @@ To confirm that an address has Default Ripple enabled, look up the address using
## Disallow XRP ## Disallow XRP
The Disallow XRP setting (`disallowIncomingXRP` in RippleAPI) is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments, if your gateway does not trade XRP. The Disallow XRP flag is not strictly enforced, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the Disallow XRP flag by default. The Disallow XRP setting is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments, if your gateway does not trade XRP. The Disallow XRP flag is not strictly enforced, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the Disallow XRP flag by default.
An issuing gateway that does not trade XRP should enable the Disallow XRP flag on the gateway's issuing and operational addresses. A private exchange that trades in XRP should only enable the Disallow XRP flag on addresses that are not expected to receive XRP. An issuing gateway that does not trade XRP should enable the Disallow XRP flag on the gateway's issuing and operational addresses. A private exchange that trades in XRP should only enable the Disallow XRP flag on addresses that are not expected to receive XRP.
@@ -599,7 +599,7 @@ To robustly check for incoming payments, gateways should do the following:
* Check the result code of every incoming payment. Some payments go into the ledger to charge an anti-spam fee, even though they failed. Only transactions with the result code `tesSUCCESS` can change non-XRP balances. Only transactions from a validated ledger are final. * Check the result code of every incoming payment. Some payments go into the ledger to charge an anti-spam fee, even though they failed. Only transactions with the result code `tesSUCCESS` can change non-XRP balances. Only transactions from a validated ledger are final.
* [Look out for Partial Payments](https://ripple.com/files/GB-2014-06.pdf "Partial Payment Flag Gateway Bulletin"). Payments with the partial-payment flag enabled can be considered "successful" if any non-zero amount is delivered, even miniscule amounts. * [Look out for Partial Payments](https://ripple.com/files/GB-2014-06.pdf "Partial Payment Flag Gateway Bulletin"). Payments with the partial-payment flag enabled can be considered "successful" if any non-zero amount is delivered, even miniscule amounts.
* In `rippled`, check the transaction for a `meta.delivered_amount` field. If present, that field indicates how much money *actually* got delivered to the `Destination` address. * In `rippled`, check the transaction for a `meta.delivered_amount` field. If present, that field indicates how much money *actually* got delivered to the `Destination` address.
* In RippleAPI, you can search the `outcome.BalanceChanges` field to see how much the destination address received. In some cases, this can be divided into multiple parts on different trust lines. * In xrpl.js, you can use the [`xrpl.getBalanceChanges()` method](https://js.xrpl.org/modules.html#getBalanceChanges) to see how much each address received. In some cases, this can be divided into multiple parts on different trust lines.
* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero [transfer fee](#transfer-fees), then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's issued currencies. See [Transfer Fees](#transfer-fees) for more information. * Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero [transfer fee](#transfer-fees), then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's issued currencies. See [Transfer Fees](#transfer-fees) for more information.
To make things simpler for your customers, we recommend accepting payments to either operational addresses and issuing addresses. To make things simpler for your customers, we recommend accepting payments to either operational addresses and issuing addresses.
@@ -612,7 +612,7 @@ As an added precaution, we recommend comparing the balances of your issuing addr
## Transfer Fees ## Transfer Fees
The `TransferRate` setting (`transferRate` in RippleAPI) defines a fee to charge for transferring issued currencies from one XRP Ledger address to another. See [Transfer Fees](transfer-fees.html) for more information. The `TransferRate` setting defines a fee to charge for transferring issued currencies from one XRP Ledger address to another. See [Transfer Fees](transfer-fees.html) for more information.
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction for the issuing address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`, setting the `TransferRate` to charge a fee of 0.5%. The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction for the issuing address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`, setting the `TransferRate` to charge a fee of 0.5%.
@@ -665,8 +665,7 @@ Response:
All XRP Ledger addresses, including operational and standby addresses, are subject to the issuer's transfer fees when sending issued currency. If you set a nonzero transfer fee, then you must send extra (to pay the transfer fee) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment. All XRP Ledger addresses, including operational and standby addresses, are subject to the issuer's transfer fees when sending issued currency. If you set a nonzero transfer fee, then you must send extra (to pay the transfer fee) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment.
* In `rippled`'s APIs, you should set the [`SendMax` transaction parameter][Payment] higher than the destination `Amount` parameter. Set the [`SendMax` transaction parameter][Payment] higher than the destination `Amount` parameter by a percentage based on the `TransferRate` setting.
* In RippleAPI, you should set the `source.maxAmount` parameter higher than the `destination.amount` parameter; or, set the `source.amount` parameter higher than the `destination.minAmount` parameter.
**Note:** Transfer fees do not apply when sending issued currencies directly to the issuing address. The issuing address must always accept its issued currencies at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays. **Note:** Transfer fees do not apply when sending issued currencies directly to the issuing address. The issuing address must always accept its issued currencies at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays.
@@ -775,7 +774,7 @@ The goal of reliably submitting transactions is to achieve the following two pro
To submit transactions reliably, follow these guidelines: To submit transactions reliably, follow these guidelines:
* Persist details of the transaction before submitting it. * Persist details of the transaction before submitting it.
* Use the `LastLedgerSequence` parameter. (RippleAPI does this by default.) * Use the `LastLedgerSequence` parameter. (Many [client libraries](client-libraries.html) do this by default.)
* Resubmit a transaction if it has not appeared in a validated ledger whose [ledger index][] is less than or equal to the transaction's `LastLedgerSequence` parameter. * Resubmit a transaction if it has not appeared in a validated ledger whose [ledger index][] is less than or equal to the transaction's `LastLedgerSequence` parameter.
For more information, see [Reliable Transaction Submission](reliable-transaction-submission.html). For more information, see [Reliable Transaction Submission](reliable-transaction-submission.html).