-
Notifications
You must be signed in to change notification settings - Fork 31
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: support txv3 in estimateFee and estimateFeeBulk [SNAP] #262
Conversation
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 will highly recommend to change to new api structure if it is possible
Co-authored-by: Stanley Yuen <[email protected]>
|
|
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
This PR introduces changes related to
TRANSACTION_VERSION
in preparation for upcoming updates regarding txV3. The primary focus is to set a default value fortransactionVersion
and ensure consistency across various estimateFee and estimateFeeBulk. No changes in current functionality are introduced in this PR.Summary of Changes:
Import Changes:
TRANSACTION_VERSION
fromconstants
in several files.Code Changes:
estimateFee.ts
:TRANSACTION_VERSION
as the default value fortransactionVersion
if it is not provided inrequestParamsObj
.estimateFees.ts
:TRANSACTION_VERSION
as the default value fortransactionVersion
in theestimateFees
function.executeTxn.ts
:TRANSACTION_VERSION
directly to a function.upgradeAccContract.ts
:TRANSACTION_VERSION
as a parameter.constants.ts
:TRANSACTION_VERSION
and set it toconstants.TRANSACTION_VERSION.V2
.starknetUtils.ts
:TRANSACTION_VERSION
to provide default values in multiple functions.Type Changes:
transactionVersion
type to accept eitherTRANSACTION_VERSION.V2
orTRANSACTION_VERSION.V3
.Function Signature Changes:
transactionVersion
as an optional parameter with default values.Impact:
Functional Impact:
The changes do not alter current behavior. They set up default values and ensure consistent usage of
TRANSACTION_VERSION
across the codebase.Preparatory Work:
These changes lay the groundwork for handling different transaction versions in future updates.
Code Consistency:
Ensures that
TRANSACTION_VERSION
is consistently used as a single source of truth across the codebase.No changes to the transaction handling or fee estimation logic are introduced in this PR. This setup will facilitate easier integration of different transaction versions in future developments.