Skip to content
This repository has been archived by the owner on Jul 9, 2021. It is now read-only.

Return filledAmount from fillOrderAsync #72

Merged
merged 8 commits into from
Jun 22, 2017
Merged

Conversation

LogvinovLeon
Copy link
Contributor

This PR:

  • Returns filledAmunt from fillOrderAsync and updates tests

@coveralls
Copy link

Coverage Status

Coverage increased (+0.03%) to 95.325% when pulling 42c61ec on fill-order-amuont into 656d745 on master.

@@ -144,10 +145,11 @@ export class ExchangeWrapper extends ContractWrapper {
* execution the tokens cannot be transferred.
* @param takerAddress The user Ethereum address who would like to fill this order.
* Must be available via the supplied Web3.Provider passed to 0x.js.
* @return The amount of the order (in taker tokens baseUnits) that was filled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The amount of the order that was filled (in taker token baseUnits).

@@ -339,6 +339,24 @@ describe('ExchangeWrapper', () => {
expect(await zeroEx.token.getBalanceAsync(takerTokenAddress, takerAddress))
.to.be.bignumber.equal(fillableAmount.minus(partialFillAmount));
});
it('should return filled amount', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is more complex then this description. A simple should return filled amount test would be:

const signedOrder = await fillScenarios.createFillableSignedOrderAsync(
                        makerTokenAddress, takerTokenAddress, makerAddress, takerAddress, fillableAmount,
                    );
const partialFillAmount = new BigNumber(3);
const filledAmount = await zeroEx.exchange.fillOrderAsync(
    signedOrder, partialFillAmount, shouldCheckTransfer, takerAddress);
expect(filledAmount).to.be.bignumber.equal(partialFillAmount);

I would add that test and then rename this one to: should return the partially filled amount if the fill amount specified is greater then the amount available

@coveralls
Copy link

Coverage Status

Coverage increased (+0.04%) to 95.337% when pulling d088dcd on fill-order-amuont into 656d745 on master.

Copy link
Member

@abandeali1 abandeali1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the sake of consistency, let's make cancelOrderAsync and fillOrdersUpToAsync also return their filledAmount.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 95.286% when pulling b28b0fa on fill-order-amuont into 656d745 on master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.05%) to 95.349% when pulling b28b0fa on fill-order-amuont into 656d745 on master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.07%) to 95.366% when pulling bd9fa3d on fill-order-amuont into 656d745 on master.

@fabioberger
Copy link
Contributor

Agreed with @abandeali1. Actually all the batch methods should return the amount filled too.

@abandeali1
Copy link
Member

It's harder for the batch methods to return a single amount because it's not mandatory to use orders with the same takerToken (this is intentional and is also the reason they don't return a value on-chain). It could be nice to return a map of tokenAddress => filledAmount, but I don't think it's completely necessary.

@fabioberger
Copy link
Contributor

Let's work on returning something useful for batch methods in a subsequent PR.

Copy link
Contributor

@fabioberger fabioberger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the merge conflicts w/ master and then feel free to merge.

@LogvinovLeon LogvinovLeon merged commit c52d675 into master Jun 22, 2017
@LogvinovLeon LogvinovLeon deleted the fill-order-amuont branch June 27, 2017 18:05
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants