-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return offer result in makeOffer #122
Comments
@samsiegart this seems easy enough to fix. I was wondering if there is reason, we don't want to pass along the whole |
We could, it's just not what I had in mind when I wrote the function. I was intending it to abstract away parsing the update with |
@samsiegart I tried a simple example via a patch here: It seems that |
See offerWatcher.js#L192. If you pass a copyrecord it will show as |
Oh sorry, I meant to link this: |
@samsiegart Looking at offerWatcher.js#L192, I don't see a way to return anything that is not a primitive type from |
You can, it will just show up in the status as Otherwise, note the If you don't use the continuing invitation pattern, the offer result won't be saved, so it can be overwritten in future status updates for the same wallet. So, anything important should use that pattern. I'm not sure the use case for needing to read a non-saved offer result. It would just provide transient feedback in the UI, but I'd imagine the result should be inferable based on the offer status and the behavior of the contract. |
What is the Problem Being Solved?
The
makeOffer
function inwalletConnection.ts
doesn't share the offer result, it only reports error, accepted, or refunded. Apps might want to access the offer result after making an offer, and right now they'd have to manually watch updates in vstorage to see them.Description of the Design
Add a case for
update.status.result !== undefined
in watchUpdates, it could do something like:One consideration to figure out is when to stop watching for updates. Does every offer return a result or an error? Is a result guaranteed to be returned before or after
numWantsSatisfied
?Test Plan
Probably testing by linking the package locally with dapp-offer-up would be the most straighforward.
The text was updated successfully, but these errors were encountered: