reservoirprotocol / reservoir-kit

ReservoirKit is a react package that makes it easy to add buying NFTs into your dApp. It's intuitive, responsive and customizable.
reservoir-kit.vercel.app
MIT License
98 stars 46 forks source link

Support for multiple fee recipients #52

Closed elie222 closed 1 year ago

elie222 commented 2 years ago

The API supports splitting fees when listing: https://github.com/reservoirprotocol/indexer/issues/1540

And will soon support it for bids: https://github.com/reservoirprotocol/indexer/issues/1596

This package expects a string for these fields however. Not sure if the types will update once the API is updated. Happy to contribute a PR here too (I can imagine some other parts of this package will break once feeRecipient supports both string and string[]).

image
pedromcunha commented 2 years ago

Hi!

After doing a bit of digging I think this is an issue with the type generation from joi. We use this script to generate the types from the api:

"syncApi": "npx openapi-typescript https://api.reservoir.tools/swagger.json --output ./src/types/api.ts"

I opened up an issue in the openapi-typescript repo to further debug this issue. Are you using reservoir-kit-client or reservoir-kit-ui? If using the client you can just override the listToken parameters and ignore any typescript errors:

    getClient().actions
      .listToken({
        listings: [{
            ...
            //@ts-ignore
            fee: ["2"],
            //@ts-ignore
            feeRecipient: ["0x056F19d211b4ad5539b365956CcCFE2306f7385D"]
        }],
        signer,
        onProgress: (steps: Execute['steps']) => {
            ...
        },
      })

Also I should mention that splitting fees is only supported in some exchanges (seaport/zeroex-v4) and not supported in x2y2/looks-rare. When splitting fees for unsupported exchanges the transaction will fail.

pedromcunha commented 1 year ago

Upgraded some of the fee logic in #67 , also upgraded some of the endpoints there. You can globally set 1 fee/recipient combo. If you need more then you'll have to pass that in manually. Also still waiting on a response from the openapi-tyepscript folks on how we can handle the dynamic types better. Closing this issue for now.