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

Improve API consistency #85

Merged
merged 30 commits into from
Aug 29, 2023
Merged

Improve API consistency #85

merged 30 commits into from
Aug 29, 2023

Conversation

IAvecilla
Copy link
Contributor

@IAvecilla IAvecilla commented Jul 12, 2023

closes #83

@IAvecilla IAvecilla marked this pull request as ready for review July 18, 2023 17:34
@IAvecilla IAvecilla self-assigned this Jul 21, 2023
Copy link
Collaborator

@mationorato mationorato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jpcenteno jpcenteno self-requested a review August 28, 2023 16:14
Copy link
Contributor

@jpcenteno jpcenteno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could rename the XyzRequest structs to XyzBuilders to be more obvious to new SDK users.

Overall, it looks good to me. I think that all my comments can be discussed and addressed in the future.

@@ -229,3 +235,98 @@ impl Default for Eip712TransactionRequest {
}
}
}

impl TryFrom<WithdrawRequest> for Eip712TransactionRequest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since a WithdrawRequest is a subset of Eip712TransactionRequests, shouldn't we implement a TryInto in that module? (following the principle that Eip712TransactionRequest shouldn't know about its children structures.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TryFrom function already implements the functionality of TryInto, but the reverse isn't necessarily true. By implementing TryFrom or From, you automatically gain the corresponding TryInto or Into trait respectively. This behavior is outlined in the Rust documentation on this trait.

}
}

impl From<TransferRequest> for Eip712TransactionRequest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as my comment for WithdrawRequests

}
}

impl TryFrom<DeployRequest> for Eip712TransactionRequest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as my comment for WithdrawRequests

polling_time_in_seconds: Option<Duration>,
timeout_in_seconds: Option<Duration>,
) -> Result<TransactionReceipt, ProviderError> {
let polling_time_in_seconds = polling_time_in_seconds.unwrap_or(Duration::from_secs(2));
let mut timer = tokio::time::interval(polling_time_in_seconds);
let start = Instant::now();

let transaction_receipt =
self.get_transaction_receipt(tx_hash)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could use TryInto and replace the tx_hash with a generic parameter in order to avoid double calls to get_transaction_receipt in the scenario where we already have a TransactionReceipt at hand.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that I understand the suggestion, you mean that the hash should implements the Try_into to a TransactionReceipt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we testing examples in the CI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we are not at the moment

src/zks_wallet/wallet.rs Show resolved Hide resolved
@codecov-commenter
Copy link

Codecov Report

Merging #85 (238066b) into main (39f010b) will decrease coverage by 9.90%.
Report is 3 commits behind head on main.
The diff coverage is 86.26%.

@@            Coverage Diff             @@
##             main      #85      +/-   ##
==========================================
- Coverage   83.02%   73.13%   -9.90%     
==========================================
  Files          13       16       +3     
  Lines        3170     2021    -1149     
==========================================
- Hits         2632     1478    -1154     
- Misses        538      543       +5     
Files Changed Coverage Δ
src/zks_utils.rs 31.03% <0.00%> (ø)
src/zks_wallet/errors.rs 0.00% <0.00%> (ø)
src/zks_wallet/requests/deposit_request.rs 50.00% <0.00%> (ø)
src/zks_wallet/requests/withdraw_request.rs 75.00% <75.00%> (ø)
src/zks_wallet/requests/call_request.rs 78.57% <78.57%> (ø)
src/zks_wallet/requests/deploy_request.rs 81.81% <81.81%> (ø)
src/eip712/transaction_request.rs 85.29% <84.50%> (-4.53%) ⬇️
src/zks_wallet/requests/transfer_request.rs 84.61% <84.61%> (ø)
src/zks_provider/mod.rs 81.01% <94.44%> (-10.07%) ⬇️
src/zks_wallet/wallet.rs 71.67% <95.00%> (-13.59%) ⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@mationorato mationorato merged commit e0ef89e into main Aug 29, 2023
4 checks passed
@mationorato mationorato deleted the improve_api branch August 29, 2023 12:54
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.

Make API consistent
4 participants