Support overlapping presale and public sale windows

[neatonk]

Background

Thanks so much for adding support for allowlist/presale features to this repo. We are relying on this feature in the mint UI of the songcamp CC0lab website.

• Site: https://cc0lab/songcamp.band/mixtape
• Code: https://github.com/songcamp/cc0lab

I've copied the code to our repo and made changes needed to support overlapping presale/pub sale windows. Other changes have been made to support custom markup, but that's out-of-scope for this discussion.

The following issues were addressed:

• The MintButton component does not support overlapping presale/public sale windows and will not appear in the event that both are active. This case is not covered by the boolean expressions which wrap the two button markup cases:
  • https://github.com/public-assembly/zora-drops-utils/blob/3ce14339dbb4ffaa51f7c097e8019290506d5729/packages/zora-drops-utils/src/components/drop-components/MintButton.tsx#L136
  • https://github.com/public-assembly/zora-drops-utils/blob/3ce14339dbb4ffaa51f7c097e8019290506d5729/packages/zora-drops-utils/src/components/drop-components/MintButton.tsx#L164
• The totalPurchasePrice always reflects the publicSalePrice and does not change to reflect the presale price. (That said, it seemed to work when I was testing with a different contract on goerli where the presale was active, but the public sale was not. Not sure if my memory is accurate on this point though)
  • https://github.com/public-assembly/zora-drops-utils/blob/3ce14339dbb4ffaa51f7c097e8019290506d5729/packages/zora-drops-utils/src/context/DropsContractProvider.tsx#L68

Proposal

Rather than making a proper PR for this I felt it better to discuss what would likely be a better solution.

• When both presale and public sale options are available, they should both be presented to the user—by default—so that the user can choose, as is done on the create.zora.co.
• To support existing use cases, an option should be provided, to always prefer presale or public sale when both are available.

In our case, the presale option is always preferable, so there is no need to show the public sale option when the connected wallet is on the allowlist.

cc/ @0xTranqui @dblodorn

[0xTranqui]

Thanks for so much detail on this! @dblodorn has been maintaining + moving this repo forward so will defer to him mostly, but have some thoughts about the public/presale options to provide -- which is that I agree with u completely that only showing presale when both are available to the given user (ex: if they are logged in, and they are on presale list, they only see that) makes total sense to me. Perhaps lets just provide an override in the component itself that would let a dev allow both if that was needed for some reason, without them having to fork the package

[dblodorn]

Hey @neatonk thanks so much for the insight and sharing the updates you made in your codebase. Yeah I had been thinking in terms of either or. So this is really helpful.

I have a big pr to merge into main and will implement your work along with some other features i've been thinking on.

One of which is a conditional rendering wrapper to displaying elements based on sale state. This use case surfaced in a project where messaging and some ui not related directly to sales functionality needed to change based on sale state.

Thank you ser. Will ping you on the pr when it's ready!