Adds a way for ics721 to use different cw721 contracts without a need for codebase changes.
We would still need to use 2 ics721 contracts, 1 that uses "cw721-base" feature and one that uses "sg721-base" feature, but the difference is that the code of core ics721 doesn't change.
So development on ics721 can continue as usual, an any ics721 that uses different cw721 can easily pull update from core ics721, and the only change that would be needed is to change the features of the registry.
Benefits:
No changes to core ics721 are needed in case of updates
very easy to add new implementation not only for cw721 contracts but also for service like ics721
Drawbacks:
Can't use in a workspace with 2 different features, features are additive, meaning the first contract will enable feature X, the second contract will have feature X without explicitly adding it.
This only true for optimizing workspaces, as a workaround its possible to optimize each contract separately.
If you do update from core ics721, you will need to modify the feature of the registry dependency,
Some stuff to do:
[ ] Verify tests are still working for both types (cw721 and sg721)
[ ] Update readme to better explain usage
[ ] Do a step by step mini guide on how to implement new cw721 contracts into the registry
shanev
commented
1 year ago
Adds a way for ics721 to use different cw721 contracts without a need for codebase changes.
We would still need to use 2 ics721 contracts, 1 that uses "cw721-base" feature and one that uses "sg721-base" feature, but the difference is that the code of core ics721 doesn't change.
So development on ics721 can continue as usual, an any ics721 that uses different cw721 can easily pull update from core ics721, and the only change that would be needed is to change the features of the registry.
Benefits:
Drawbacks:
Some stuff to do: