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

[ENG-3594] feature: Send Max STX #767

Closed
wants to merge 80 commits into from
Closed

Conversation

jordankzf
Copy link
Contributor

@jordankzf jordankzf commented Jan 23, 2024

🔘 PR Type

What kind of change does this PR introduce?
image
image
image
image
image
image

Notes:

  1. Success screen restyle not part of this PR.
  2. Confirmation screen restyle not part of this PR.
  3. Estimated fees seem weird.
  • Bugfix
  • Enhancement
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no API changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

📜 Background

Provide a brief explanation of why this pull request is needed. Include the problem you are solving or the functionality you are adding. Reference any related issues.

Issue Link: #[issue_number]
Context Link (if applicable):

🔄 Changes

Enumerate the changes made in this pull request, detailing what has been modified, added, or removed. Include technical details and implications if necessary.

Impact:

  • Explain the broader impact of these changes.
  • How it improves performance, fixes bugs, adds functionality, etc.

🖼 Screenshot / 📹 Video

Include screenshots or a video demonstrating the changes. This is especially helpful for UI changes.

✅ Review checklist

Please ensure the following are true before merging:

  • Code Style is consistent with the project guidelines.
  • Code is readable and well-commented.
  • No unnecessary or debugging code has been added.
  • Security considerations have been taken into account.
  • The change has been manually tested and works as expected.
  • Breaking changes and their impacts have been considered and documented.
  • Code does not introduce new technical debt or issues.

@jordankzf jordankzf marked this pull request as draft January 23, 2024 04:12
@jordankzf jordankzf changed the base branch from develop to victor/eng-3548-ext-send-btc-integrate-tx-consolidation-logic-tx January 28, 2024 05:55
Base automatically changed from victor/eng-3548-ext-send-btc-integrate-tx-consolidation-logic-tx to develop February 15, 2024 09:55
@teebszet
Copy link
Member

teebszet commented Feb 26, 2024

image

wrong font on the amount input fiat rate here, and the up-down-arrows icon looks too small compared to the figma. also check the padding around the fiat rate?


const colors: Record<FeedbackVariant, string> = {
info: Theme.colors.white_200,
danger: Theme.colors.danger_light,
plain: Theme.colors.white_200,
Copy link
Member

Choose a reason for hiding this comment

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

this should be 'explicative' to match zeroheight naming, and white_400
image

figma:
image


const colors: Record<FeedbackVariant, string> = {
info: Theme.colors.white_200,
danger: Theme.colors.danger_light,
plain: Theme.colors.white_200,
plainIndented: Theme.colors.white_200,
Copy link
Member

@teebszet teebszet Feb 26, 2024

Choose a reason for hiding this comment

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

nit: maybe this should be a indentedNoIcon?: boolean prop?
so that any of the variants can replace the icon with an indent

Copy link
Member

@teebszet teebszet Feb 26, 2024

Choose a reason for hiding this comment

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

alternatively, you could use

noIcon?: boolean

and add a margin-left where you're using it for bns names, because we don't want to bloat the ui-library with random exceptions that may not be used much in other places

@@ -6,10 +6,13 @@ type ButtonVariant = 'primary' | 'secondary' | 'tertiary' | 'danger';

const StyledButton = styled.button`
width: 100%;
min-height: 42.5px;
Copy link
Member

Choose a reason for hiding this comment

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

question: is this something that is needed for all buttons and their variations? in zeroheight it's height: 44px.

if it's only for an edge case usage, consider applying this min-height where you need it rather than enforcing it here

new BigNumber(stxBtcRate),
new BigNumber(btcFiatRate),
)
.toNumber()
Copy link
Member

@teebszet teebszet Feb 26, 2024

Choose a reason for hiding this comment

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

nit: is toNumber() necessary here?

fiatUnit={fiatCurrency}
getFeeForFeeRate={getFeeForFeeRate}
feeRates={fees}
feeRateLimits={{ min: 0.000001, max: feeMultipliers?.thresholdHighStacksFee }}
Copy link
Member

Choose a reason for hiding this comment

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

is this min/max logic stated somewhere in requirements?

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, it's not documented. It's the same logic used for the current send stx implementation.

Comment on lines 159 to 170
const [low, medium, high] = await estimateTransaction(
unsignedTx.payload,
undefined,
selectedNetwork,
);
setFees({
low: Number(microstacksToStx(new BigNumber(low.fee)).toFixed(2)),
medium: Number(microstacksToStx(new BigNumber(medium.fee)).toFixed(2)),
high: Number(microstacksToStx(new BigNumber(high.fee)).toFixed(2)),
});
if (!fee)
setFeeRate(Number(microstacksToStx(new BigNumber(medium.fee)).toFixed(2)).toString());
Copy link
Member

Choose a reason for hiding this comment

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

need to clarify with the requirements on what this logic should be. it looks to me that the notion requirements point to this section: https://www.notion.so/xverseapp/Speed-up-Stacks-transaction-Improve-fee-estimation-4455d27f8bdc4ebfbd94a16d7f18fe12?pvs=4#9509f0afd87d40eba297b357aa28763c

but there's no capping logic being applied here

@teebszet
Copy link
Member

teebszet commented Feb 26, 2024

@jordankzf I think the main points here are:

  1. need to clarify and fix what the stx fee estimates should be (low, med, high)

  2. need to fix the minor UI issues

  3. need to think more carefully about how you're extending/duplicating the btc send max components, especially around the ui-components/selectFeeRate, as @victorkirov commented on. currently, the code to extend selectFeeRate for send stx feels a bit clunky

I think in order to keep this feature moving, let's focus on 1. and 2. to be ready for testing, and 3. can be a follow up task to include refactoring how best to share code between the various send flows, (including btc, stx, and other fungible token protocols)

Copy link

github-actions bot commented Mar 1, 2024

@teebszet teebszet closed this Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants