Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

0xivanov
Copy link
Contributor

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.

Signed-off-by: Ivan Ivanov <ivanivanov.ii726@gmail.com>
@0xivanov 0xivanov self-assigned this Jan 27, 2025
Copy link

codecov bot commented Jan 27, 2025

Codecov Report

Attention: Patch coverage is 85.18519% with 4 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
sdk/token_reject_flow.go 84.61% 4 Missing ⚠️
Files with missing lines Coverage Δ
sdk/token_reject_transaction.go 85.48% <100.00%> (+0.11%) ⬆️
sdk/token_reject_flow.go 64.75% <84.61%> (+5.06%) ⬆️

... and 2 files with indirect coverage changes

Signed-off-by: Ivan Ivanov <ivanivanov.ii726@gmail.com>
@0xivanov 0xivanov marked this pull request as ready for review January 28, 2025 10:55
@0xivanov 0xivanov requested review from a team as code owners January 28, 2025 10:55
Comment on lines +8 to +11
ownerID *AccountID
tokenIDs []TokenID
nftIDs []NftID
freezeWithClient *Client
Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants