A JavaScript/TypeScript API for interacting with the XRP Ledger in Node.js and the browser
Bot releases are visible (Hide)
Published by intelliot almost 5 years ago
_send
(thanks @nickewansmith)
_send
promise passed to _whenReady
in case there is rejection before async handlers are added (#1092)Published by intelliot almost 5 years ago
es6
(#1071)
getAccountObjects
doc fixbignumber.js
ripple-keypairs
ws
webpack
flowPublished by intelliot almost 5 years ago
-instance.Account is not of a type(s) string,instance.Account does not conform to the "address" format
+instance.Account is not of a type(s) string,instance.Account is not exactly one from <xAddress>,<classicAddress>
Published by intelliot about 5 years ago
Published by intelliot about 5 years ago
Published by intelliot about 5 years ago
rippleTimeToISO8601()
methodWhen using this release with rippled, we recommend using rippled version 1.3.1 or later.
Published by intelliot about 5 years ago
There are no changes in the browser version with this release. The npm package for Node.js should be slightly smaller.
When using this release with rippled, we recommend using rippled version 1.3.1.
Published by intelliot about 5 years ago
getServerInfo
(#1012)Before:
{
// ...
"load": {
"jobTypes": {
"0": {"jobType": "untrustedValidation", "perSecond": 10},
"1": {"jobType": "ledgerData", "peakTime": 2, "perSecond": 2},
"2": {"inProgress": 1, "jobType": "clientCommand", "perSecond": 1},
"3": {"jobType": "transaction", "perSecond": 1},
// ...
},
"threads": 6
},
// ...
}
After:
{
// ...
"load": {
"jobTypes": [
{
"jobType": "untrustedValidation",
"perSecond": 8
},
{
"avgTime": 2,
"jobType": "ledgerData",
"peakTime": 72,
"perSecond": 2
},
{
"inProgress": 1,
"jobType": "clientCommand",
"perSecond": 1
},
{
"jobType": "transaction",
"perSecond": 1
},
// ...
],
"threads": 6
},
// ...
}
APIOptions
by extending ConnectionOptions
(#1018, fixes #1017)setCanonicalFlag
method from src/transaction/utils
Since this release fixes a bug that could cause transactions to be serialized incorrectly during the signing process, it has also been simultaneously released as version 1.2.5 (patch release).
When using this release with rippled, we recommend using rippled version 1.3.1.
Published by intelliot about 5 years ago
getServerInfo
(#1012)Before:
{
// ...
"load": {
"jobTypes": {
"0": {"jobType": "untrustedValidation", "perSecond": 10},
"1": {"jobType": "ledgerData", "peakTime": 2, "perSecond": 2},
"2": {"inProgress": 1, "jobType": "clientCommand", "perSecond": 1},
"3": {"jobType": "transaction", "perSecond": 1},
// ...
},
"threads": 6
},
// ...
}
After:
{
// ...
"load": {
"jobTypes": [
{
"jobType": "untrustedValidation",
"perSecond": 8
},
{
"avgTime": 2,
"jobType": "ledgerData",
"peakTime": 72,
"perSecond": 2
},
{
"inProgress": 1,
"jobType": "clientCommand",
"perSecond": 1
},
{
"jobType": "transaction",
"perSecond": 1
},
// ...
],
"threads": 6
},
// ...
}
APIOptions
by extending ConnectionOptions
(#1018, fixes #1017)setCanonicalFlag
method from src/transaction/utils
Published by intelliot over 5 years ago
Published by intelliot over 5 years ago
Below are recent changes that were also included in ripple-lib 1.2.2:
prepareTransaction
from overwriting Fee
and/or LastLedgerSequence
(#997)deliveredAmount
as optional field for type Outcome
(#996)Published by mDuo13 over 5 years ago
Minor changes:
Published by intelliot over 5 years ago
ripple-binary-codec
to 0.2.1 to support tecKILLED
Published by intelliot over 5 years ago
This release:
prepare*
methods.message
field of RippledError
s.Sequence
to be set in the transaction JSON provided toprepareTransaction
.For details, continue reading:
prepare*
methods reject the Promise on errorThe prepare*
methods now always reject the Promise when an error occurs, instead of throwing.
Previously, the methods would synchronously throw on validation errors, despite being asynchronous methods that return Promises.
In other words, to handle errors in the past, you would need to use a try/catch block:
// OBSOLETE - no need for try/catch anymore
try {
api.preparePayment(address, payment, instructions).then(prepared => {
res.send(prepared.txJSON);
}).catch(error => {
// Handle asynchronous error
});
} catch (error) {
// Handle synchronous error
}
Now, you can rely on the Promise's catch
handler, which is called with the error when the Promise is rejected:
api.preparePayment(address, payment, instructions).then(prepared => {
res.send(prepared.txJSON);
}).catch(error => {
// Handle error
});
This applies to:
RippledError
message
Previously, RippledErrors
(errors from rippled) used rippled's error
field as the message
.
Now, the error_message
field is used as the message
.
This helps to surface the specific cause of an error.
For example, before:
[RippledError(invalidParams, { error: 'invalidParams',
error_code: 31,
error_message: 'Missing field \'account\'.',
id: 3,
request: { command: 'account_info', id: 3 },
status: 'error',
type: 'response' })]
After:
[RippledError(Missing field 'account'., { error: 'invalidParams',
error_code: 31,
error_message: 'Missing field \'account\'.',
id: 3,
request: { command: 'account_info', id: 3 },
status: 'error',
type: 'response' })]
In this case, you can see at a glance that account
is the missing field.
The error
field is still available in errorObject.data.error
.
When error_message
is not set (as with e.g. error 'entryNotFound'), the error
field is used as the message
.
prepareTransaction
does not overwrite the Sequence
fieldThe prepareTransaction
method now allows Sequence
to be set in the Transaction JSON object, instead of overwriting it with the account's expected sequence based on the state of the ledger.
Previously, you had to use the sequence
field in the instructions
object to manually set a transaction's sequence number.
As this is the first release of ripple-lib following the release of rippled 1.2.1, we would like to highlight the following API improvements:
The delivered_amount
field has been added to the ledger
method, and to transaction subscriptions.
api.getLedger({includeTransactions: true, includeAllData: true, ledgerVersion: 17718771}).then(...)
You can also call ledger
directly:
request('ledger', {...}).then(...)
You have access to these improvements when you use a rippled server running version 1.2.1 or later. At the time of writing, we recommend using rippled version 1.2.2 or later.
Published by intelliot almost 6 years ago
submit
response (#978)
getLedger
option for ledger hash (#980)
ledgerHash
option to get a specific ledger by hashPublished by intelliot almost 6 years ago
getOrderbook
offer sorting (#970)
getOrderbook
hasrippled
APIs:
formatBidsAndAsks
: Takes offers and returns a formatted order book objectrenameCounterpartyToIssuer
: Takes an object and renames the counterparty
issuer
generateAddress
(#968)When using ripple-lib
with rippled
, we recommend using rippled
version 1.1.1 or
later.
Published by intelliot almost 6 years ago
FormattedTransactionType
, the Outcome
's balanceChanges
property hadWhen using this library online with rippled, we recommend using rippled version 1.1.1 or later.
Published by intelliot about 6 years ago
object
(#936)Published by intelliot about 6 years ago
isValidAddress(address: string) : boolean
: Checks if the specified string contains a valid address.isValidSecret(secret: string): boolean
: Checks if the specified string contains a valid secret.deriveKeypair(seed: string): {privateKey: string, publicKey: string}
: Derive a public and private key from a seed.deriveAddress(publicKey: string): string
: Derive an XRP Ledger address from a public key.const address = api.deriveAddress(api.deriveKeypair(secret).publicKey)
Published by intelliot about 6 years ago
We are pleased to announce the release of ripple-lib
version 1.0.0.
This version features a range of changes and improvements that make the library
more capable and flexible. It includes new methods for accessing rippled APIs,
including subscriptions.
When using this version with rippled
for online functionality, we recommend
using rippled
version 1.0.1 or later.
Here is a summary of the changes since ripple-lib
version 0.22.0, which was
the last non-beta version.
request()
, hasNextPage()
, and requestNextPage()
for accessing rippled
prepareTransaction()
for preparing raw txJSON
.xrpToDrops()
and dropsToXrp()
getTransaction
responses can include a new channelChanges
property thatValidationError
to begetPaths
now filters paths correctly and works correctly when theThe following changes were introduced in 1.0.0.
getTransaction()
and getTransactions()
specification.destination.amount
field has been removed from the parsed transaction response.outcome.deliveredAmount
.Amount
from the original transaction:
getTransaction
's includeRawTransaction
option, orgetTransactions
's includeRawTransactions
option, orrequest
. For example, call the API methods tx
, account_tx
, etc.getLedger()
response object
rawTransactions
field has been removed (for consistency with getTransaction()
and getTransactions()
).transaction
, use the new rawTransaction
JSON string.metaData
field has been renamed to meta
for consistency with rippled's tx
method.ledger_index
has been added to each raw transaction.