-
Notifications
You must be signed in to change notification settings - Fork 352
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
Update erc721 docs #763
Update erc721 docs #763
Conversation
* Change the spelling of "StarkNet" to "Starknet" (OpenZeppelin#557) * fix: link (OpenZeppelin#545) * change StarkNet to Starknet --------- Co-authored-by: Eric Nordelo <eric.nordelo39@gmail.com> * add Cargo and Makefile * add deps in cairo_project, create lib * add presets * add base lib * add tests * remove old cairo lib and interface * remove unused import * fix vars * change external funcs to snake case * remove unused import * add tests for externals * add bool assertions * remove preset mods * add IERC20 trait * clean up test * remove assertion * simplify max_u256 * clarify error msg * clean up python project. ready for rust/cairo1 * add erc165 + tests * kickstart account module * re-structure project * re-structure project * re-structure project * update makefile * re-structure project * update to felt252, add use ContractAddress * formatting * remove colons from storage, remove _mint from initializer * add constructor test * add comments * fix format * check error msg in tests * set max_u256 as func * update cairo * update cargo * revert doc commit * remove __init__ * refix link --------- Co-authored-by: kongtaoxing <69096526+kongtaoxing@users.noreply.github.com> Co-authored-by: Eric Nordelo <eric.nordelo39@gmail.com> Co-authored-by: Martín Triay <martriay@gmail.com>
* update cairo * fix path * add security mod * add initializable * add tests * Update src/openzeppelin/security/initializable.cairo Co-authored-by: Martín Triay <martriay@gmail.com> * remove underscore * add internal macros --------- Co-authored-by: Martín Triay <martriay@gmail.com>
…ppelin#598) * use zeroable for address * cleanup import
* fix path * add security mod * add pausable * add mock * add tests * add security mod * update cargo * update cairo * Apply suggestions from code review Co-authored-by: Martín Triay <martriay@gmail.com> * remove underscore from _paused * remove unused imports * add test assertion for is_paused * move mocks inside tests crate * remove underscore * add blank line --------- Co-authored-by: Martín Triay <martriay@gmail.com>
This reverts commit e86bcd2.
* Apply suggestions from code review Co-authored-by: Andrew Fleming <fleming-andrew@protonmail.com> Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com> * apply review suggestions * remove unused import * add internal macro * add deregister --------- Co-authored-by: Andrew Fleming <fleming-andrew@protonmail.com> Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com>
* add utils and constants * simplify role val * add context comments for interface ids
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs to be updated to use components, but other than that it looks good!
trait IERC721ABI { | ||
// IERC721 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now that we have components and presets, I wonder if we should begin with this chunk of interface. It's kindof big and with lots of information (non standard, camel support). maybe i'd focus in the component. what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that it is kind of big with a lot going on. I'm not sure what you're suggesting though. Do you mean removing the Interface
section entirely? Or removing the individual interface subsections and just keep the ERC721ABI
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure i understood the second option, did you mean IERC721
? i was suggesting to remove the interface section, although it may require a bit more of thought. My impression is that it's not that important now we have components because it's not a single module with all of it anymore, now you can select the impls.
If anything, it is closer to the preset, which is no yet documented and probably not the main focus of the section either. The focus should be the component and design/implementation details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure i understood the second option, did you mean IERC721?
Yeah, that section, IERC721Metadata
, and ISRC5
. I removed those section already since I left that response
i was suggesting to remove the interface section, although it may require a bit more of thought. My impression is that it's not that important now we have components because it's not a single module with all of it anymore, now you can select the impls.
If anything, it is closer to the preset, which is no yet documented and probably not the main focus of the section either. The focus should be the component and design/implementation details.
Agreed^
Maybe it'd make sense to follow a structure like this in the doc:
ERC721Component
Implementations
ERC721Impl
ERC721MetadataImpl
...
ERC721 compatibility
Usage
...
We can either head the impl
s with the interface snippet or just provide a link to the interface in the API...or just remove the Interface
/Implementations
section entirely, idk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now we have this inconsistent structures:
Upgrades
- explainer
- usage
Account
- interface
Access
- usage
- interface
ERC20 and ERC721
- interface
- compatibility
- usage
Security
- usage
Introspection
- interface
- usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have
- explainer
- usage
- compatibility
and leave interface for API, of have it between explainer and usage. Either way we can merge this and fix it all together later in #829.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good Andrew! Left a couple of small comments but I think it looks ready.
docs/modules/ROOT/pages/erc721.adoc
Outdated
component!(path: SRC5Component, storage: src5, event: SRC5Event); | ||
component!(path: ERC721Component, storage: erc721, event: ERC721Event); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should swap the order (this applies to the impls below as well). This is compliant with the account preset too.
docs/modules/ROOT/pages/erc721.adoc
Outdated
component!(path: SRC5Component, storage: src5, event: SRC5Event); | ||
component!(path: ERC721ReceiverComponent, storage: erc721_receiver, event: ERC721ReceiverEvent); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment regarding swapping
Co-authored-by: Eric Nordelo <eric.nordelo39@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
trait IERC721ABI { | ||
// IERC721 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure i understood the second option, did you mean IERC721
? i was suggesting to remove the interface section, although it may require a bit more of thought. My impression is that it's not that important now we have components because it's not a single module with all of it anymore, now you can select the impls.
If anything, it is closer to the preset, which is no yet documented and probably not the main focus of the section either. The focus should be the component and design/implementation details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Martín Triay <martriay@gmail.com>
Weird. Yeah, I copied the .toml you posted and I'm also using Scarb 2.3.1 and it compiles on my end. I don't have the syntax highlighting though. Maybe try just pasting the code in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works now, I had to delete my Scarb.lock
.
Supersedes #699 and fixes #563.