Add support for Checks

[intelliot]

• See Checks (RIPD-1487) rippled#2245

[scottschurr]

Thanks for getting to this so quickly, @intelliot. I'm, of course, reading this as a TypeScript illiterate. But it all looks reasonable to me.

I'm wondering if ripple-lib has support for finding account objects, like Offers. If it does, you might consider adding support for finding the checks that are associated with an account. There are two kinds of checks that can be associated with an account: those written by the account, and checks that are the destination of the account. Folks may want to know about either.

What I've seen here looks good to me. 👍

[scottschurr]

"...amount or for as much..."?

[intelliot]

and

:)

[scottschurr]

Nice description.

[scottschurr]

I'll mention is passing that a "sourceTag" is also an allowed field. But that's allowed in any transaction, so you may be handling that elsewhere.

[scottschurr]

👍

[wilsonianb]

I'm wondering if ripple-lib has support for finding account object

There's getPaymentChannel, but that's by id as opposed to something like rippled's account_objects

[FredKSchott]

I'm wondering if ripple-lib has support for finding account object

There's getPaymentChannel, but that's by id as opposed to something like rippled's account_objects

Today you can call api.connection.request({}) to make rippled requests like {command: 'account_objects', ...} directly, although it's kind of hidden. Work is being done to expose this more clearly via a new api.request() method.

[scottschurr]

Tests are good. I don't read javascript well enough to have a useful opinion here. But I do like having tests. 😄 👍

[FredKSchott]

Looks good! Added a few comments

[FredKSchott]

We're moving towards typing the output of these parsing functions so that they're easier to consume (also a great place to document the formatted type).

So instead of returning a type Object you would return a type FormattedCheckCreate, something like this:

export type FormattedCheckCreate = {
  // account that can cash the check.
  destination: string,
  // amount the check is allowed to debit the sender, including transfer fees on non-XRP currencies.
  sendMax: Amount,
  // (Optional) identifies the reason for the check, or a hosted recipient.
  destinationTag?: string,
  // (Optional) time in seconds since the Ripple Epoch.
  expiration?: string, 
  // (Optional) 256-bit hash representing a specific reason or identifier.
  invoiceID?: string
}

function parseCheckCreate(tx: any): FormattedCheckCreate {
  // ...
}

Can you do this for the other two new parsers?

[FredKSchott]

Object actually doesn't mean an arbitrary object like it did in Glow, it's closer to an empty object than an arbitrary one. Change to any or object (lower-case) to represent any arbitrary object, and then you should be able to remove the : any you had to add to the txJSON below.

[FredKSchott]

We tend to do data validation as the first thing in the function. It's a good general rule so that you don't have to worry about what logic is safe to do pre-validation vs. post-validation (ex: if someone later had to add something to the txJSON definition above).

[intelliot]

@FredKSchott Thank you! Have a second look?

[intelliot]

@shekenahglory @wilsonianb Would love if you guys could review as well.

[FredKSchott]

lgtm!