feat: pay ui

[samsiegart]

fixes Agoric/documentation#1001
fixes #46

The UI is almost a copy-paste of the swap UI with the "Want" removed and a different makeOffer call.

Changed the postal service contract to be able to add issuers from invitation args, so swapping tickets works (#46)

Also removed an unused vbank query and added contract/,tx.json to gitignore.

Screenshot

[samsiegart]

Adding @dckc as a reviewer for the contract bits

[dckc]

contract change for issuers looks good except that issuerNumber shouldn't be static mutable state.

[dckc]

Did you consider making the issuers arg optional?

[samsiegart]

The UI is always just going to send the issuers anyway so it doesn't seem worth the complexity. We'd have to query and check which issuers are already added first, I'm not sure if they're published anywhere either.

[dckc]

move this inside start(), please. No static mutable state.

[samsiegart]

I considered making it durable, but saw that this was what the swap contract does already ,so I figured it's not critical to preserve the issuer numbers. Is no static mutable state a hard rule? I can update it in both contracts if needed.

[dckc]

I can update it in both contracts if needed.

Please do.

Is no static mutable state a hard rule?

It's part of OCap Discipline that isn't (yet?) enforced by our platform.

SES lockdown docs say:

SES introduces the lockdown() function. Calling lockdown() alters the surrounding execution environment, or realm, such that no two programs running in the same realm can observe or affect each other until they have been introduced, and even then can only interact through their own exposed interfaces.

But that's not quite true: SES doesn't (yet?) get rid of module-level static mutable state such as

let callCount = 0;

export const complementaryColor = _ => {
  callCount += 1;
  return 'green';
}

export const colorCallCount = () => callCount;

So one program could do

import { complementaryColor } from './fun-stuff.js';

console.log(complementaryColor('blue');

and another could do

import { colorCallCount } from './fun-stuff.js`;

console.log('there have been', colorCallCount(), 'calls to complementaryColor');

cc @kriskowal @erights

[dckc]

Nothing in the postal service contract is durable, so that would be above end beyond the call of duty here.

[samsiegart]

Ah I see what you mean, move it into the function scope but don't necessarily make it durable. Done.

[dckc]

import from ertp?

[samsiegart]

Done. I did a deep import because of a comment in the swap contract about minimizing bundle size.

[dckc]

This regression is a little surprising. But I guess I don't mind too much.

[Jovonni]

lgtm 🚀

thought: since we have docs for our templates, should we consider including descriptions where we use @param etc, then we can just generate the docs for our templates. I know we use it for type reasons primarily.

[samsiegart]

thought: since we have docs for our templates, should we consider including descriptions where we use @param etc, then we can just generate the docs for our templates. I know we use it for type reasons primarily.

This is a good option to have, but I don't have a vision of which docs we'd want to generate for this specifically. It's more useful for component libraries, but we can't import parts of dapp-agoric-basics in another project.