-
Notifications
You must be signed in to change notification settings - Fork 13
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
fix: refining ext and test contract #35
Conversation
packages/ext/src/collection.rs
Outdated
@@ -13,20 +13,15 @@ pub struct Collection { | |||
} | |||
|
|||
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)] | |||
pub struct NonFungibleToken { | |||
pub struct Token { |
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.
As the original response was separated into two concrete types, I think it would be better to separate the client-side as well.
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. If they have common functions, these should be implemented as traits.
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.
The reason why I grouped them together in a structure called "Token" is because both FT and NFT types are returned to the client-side in query_tokens.
https:/line/link-modules/blob/20e848dbda3ce486059e40d7d63bbf6c4319f898/x/collection/client/internal/types/retriever.go#L152
If I have separated two concrete types, I cannot parse them and get an error.
The query_token is not returned as a Token, but as a Response type.
https:/line/cosmwasm/pull/35/files#diff-11044ca7e42123842acfa85d0bfef49ca79f44729704a9fc929e412d1ad9b104R161
Therefore, The key of Response type can be used to determine the concrete types (FT or NFT).
https:/line/cosmwasm/blob/develop/packages/ext/src/query.rs#L69-L70
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.
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.
If you want to use direct sum types in Rust, you can use an enum
to treat FT
and NFT
as common Token
types, as shown below.
pub struct FT{ ... }
impl FT { fn A(){ ... }, fn B(){ ... }, ... }
pub struct NFT{ ... }
impl NFT { fn A(){ ... }, fn C(){ ... }, ... }
pub enum Token {
Fungible(FT),
NonFungible(NFT),
}
impl Token { fn A(){ ... }, ... } // common behaviour between FT and NFT
let tokens = vec![Token::Fungible(FT{...}), Token::NonFungible(NFT{...})];
for token in tokens.iter() {
token.A();
match token {
Token::Fungible(ft) => { ft.B(); ... },
Token::NonFungible(nft) => { nft.C(); ... },
}
}
However, you probably need to make sure whether the serialized format of Token
will be in your intended.
proxy: HumanAddr, | ||
contract_id: String, |
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.
proxy: HumanAddr, | |
contract_id: String, | |
contract_id: String, | |
proxy: HumanAddr, |
minor suggestion
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.
fixed!
@@ -53,7 +54,6 @@ pub enum CollectionQuery { | |||
QueryTotalParam { | |||
contract_id: String, | |||
token_id: String, | |||
target: Target, | |||
}, | |||
QueryPermParam { |
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 this param is for QueryIsApproved
(https:/line/link-modules/blob/develop/x/collection/internal/querier/querier.go#L55), is it right?
But the naming is confused with QueryPerms
(https:/line/link-modules/blob/develop/x/collection/internal/querier/querier.go#L25).
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 this param is for
QueryIsApproved
Confused with QueryApprovedParam
?
But the naming is confused with
QueryPerms
QueryXxxx
sounds like a query, and ParamXxxx
sounds like a parameter.
In this case, replacing QueryXxxxParam
-> QueryXxxx
or replacing QueryXxxxParam
-> ParamXxxx
are better. I prefer the former. (... But it should be another issue
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.
There are two types of permission,
- account permission (mint, burn ...)
- proxy permission (approver)
In the chain, the first case is being named perm
and the second case is being named approve
.
However, this code line is used for proxy permission but named perm
But this comment is not related to changes in the PR.
We can discuss it on another issue.
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.
QueryPermParam
is a parameter to query account permission.
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.
rename QueryXxxxParam to XxxxParam
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 this patch is overkill for refactoring.
This PR changes the interfaces (messages), adding some features, and fixing some bugs.
I want to know what is your intention for this patch in more detail by reading commit messages. It is hard to review this PR with these information for me...
…ry_total, query_mint and query_burn in token module
…ry_mint and query_burn in collection module
sorry, I've split the commit. PTAL. |
packages/ext/src/collection.rs
Outdated
@@ -13,20 +13,15 @@ pub struct Collection { | |||
} | |||
|
|||
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)] | |||
pub struct NonFungibleToken { | |||
pub struct Token { |
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. If they have common functions, these should be implemented as traits.
@@ -84,15 +85,38 @@ impl<'a, Q: Querier> LinkTokenQuerier<'a, Q> { | |||
Ok(res) | |||
} | |||
|
|||
pub fn query_supply(&self, contract_id: String, target: Target) -> StdResult<Uint128> { | |||
pub fn query_supply(&self, contract_id: String) -> StdResult<Uint128> { |
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.
refactor: remove target param from query_supply and split it into que…
It looks like a changing of spec. Isn't it?
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.
yes
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.
OK, then, I think this commit message should not say "refactor:".
@@ -53,7 +54,6 @@ pub enum CollectionQuery { | |||
QueryTotalParam { | |||
contract_id: String, | |||
token_id: String, | |||
target: Target, | |||
}, | |||
QueryPermParam { |
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 this param is for
QueryIsApproved
Confused with QueryApprovedParam
?
But the naming is confused with
QueryPerms
QueryXxxx
sounds like a query, and ParamXxxx
sounds like a parameter.
In this case, replacing QueryXxxxParam
-> QueryXxxx
or replacing QueryXxxxParam
-> ParamXxxx
are better. I prefer the former. (... But it should be another issue
packages/ext/src/collection.rs
Outdated
meta, | ||
owner: HumanAddr::from(owner), | ||
}), | ||
_ => panic!("unexpected token type"), |
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 function should not panic, because the returning type is Result
.
Instead, it should return Err(foo)
.
PTAL |
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.
Great! But, I think we need some unit tests for serializing/deserializing defined in packages/ext/src/collection.rs
. Especially, it is needed for a list of FT/NFT.
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!
PTAL @whylee259 |
#[derive(Serialize, Clone, Debug, PartialEq, JsonSchema)] | ||
#[serde(untagged)] | ||
pub enum Token { | ||
FT(FungibleToken), | ||
NFT(NonFungibleToken), | ||
} | ||
|
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 wonder why this uses a manually implemented deserializer rather than use derive
as follows.
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(untagged)]
pub enum Token {
FT(FungibleToken),
NFT(NonFungibleToken),
}
Additionally, using Adjacently tag
, seems to be able to reduce the depth of response struct.
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(tag = "type", content = "value")]
pub enum Token {
#[serde(rename = "collection/FT")]
FT(FungibleToken),
#[serde(rename = "collection/NFT")]
NFT(NonFungibleToken),
}
let res = serde_json::from_str::<Vec<Token>>(json);
but we can discuss reducing depth on another issue.
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.
Let's do this at #50.
If only one curiosity I commented on is resolved, |
* feat: add query approved function for collection module * fix: fix LinkQueryWrapper type * fix: rename query_approved to query_is_approved * fix: bug fix query_is_approved return value * refactor: unify NFT and FT types into one * refactor: change the arguments of modify function * refactor: rename GetNft to GetNftCount * chore: add snake_case * refactor: remove target param from query_supply and split it into query_total, query_mint and query_burn in token module * refactor: remove target param from query_supply and split it into query_mint and query_burn in collection module * fix: update schema json * fix: separate token into FT and NFT and implement deserialize * fix: swap the order of parameters * fix: rename query param * fix: fix lint error * fix: change return error with match statement * chore: add unit test for deserialize * fix: fix ci error
Description
Correction of cosmwasm due to the effect of refactoring the encoder in the token, collection module in the PR of https:/line/link-modules/pull/60
Motivation and context
How has this been tested?
Checklist: