-
Notifications
You must be signed in to change notification settings - Fork 68
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
feat: TokenRejectFlow
refactor
#1235
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Ivan Ivanov <ivanivanov.ii726@gmail.com>
Codecov ReportAttention: Patch coverage is
|
Signed-off-by: Ivan Ivanov <ivanivanov.ii726@gmail.com>
ownerID *AccountID | ||
tokenIDs []TokenID | ||
nftIDs []NftID | ||
freezeWithClient *Client |
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.
My initial idea was using ownerIds
, tokenIds
only on the transactions themselves. The freeze would also be done on the separate transactions. So the client won't be passed to the TokenRejectFlow
. The only thing we need to use in the Flow would be a PrivateKey if sign is needed on that level.
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.
Yeah I faced some problems with keeping the API the same in JS using that method. I will check if it can work in Go.
} | ||
tokenDissociateTxn := NewTokenDissociateTransaction() | ||
|
||
func (tx *TokenRejectFlow) fillTokenDissociate() error { |
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 same will be valid for the fillTransactions. As they could also be removed I think.
Description
Currently, the
TokenRejectFlow
class and similar transaction flows are overly reliant on class hierarchies that treat flows as if they are transactions themselves. This design complicates the implementation and maintenance of transaction flows.This PR does not change the API, but only adds getters to allow modification to the individual transactions.