-
Notifications
You must be signed in to change notification settings - Fork 195
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
Use minSendable and maxSendable values from LNURLp response to guide user input #1697
Conversation
Or maybe show a message if the user type an amount less the minimum or more than maximum. Not only disable the confirm button. |
🚀 Thanks for the pull request! Here are the current build files for testing: Download and unzip the file for your browser. Refer to the readme for detailed install instructions. This build is brought to you by: Want to sponsor the next build? send some sats to ⚡️builds@getalby.com (don't forget to provide your name) Don't forget: keep earning sats! |
I think inside the amount field should have a text like: Send between x sats and y sats. |
Thanks @bitcoinuser for your comments!
I guess the "best solution" depends on what people use Alby for. What I like about the 100, 1K, 5K et 10K suggested values that are in place right now is that it makes perfect sense (at least to me) for tipping, Value4Value, etc. That's why I went for amounts that stayed quite close to this values, while taking the
I agree. I noticed that there already is a help text displayed when hovering on the input that does just that, although I think that it would be better to display it under the input field.
I think I prefer a prefilled amount (makes less clicks and helps decision, hence reducing transaction friction). Like for the help text on hover, I decided to let it like it was and focus on the |
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.
Thanks for your contribution! I just tested the PR and noticed that the algorithm for creating the sats buttons creates some odd distribution for different min / max combinations.
I've prepared a list of LNURLs that we can use for testing here:
https://github.com/getAlby/lightning-browser-extension/wiki/%F0%9F%A4%A0-Alby-in-the-wild
I think we should aim for the following behaviour:
- Minimum is never lower than
min
- Maximum is never higher than
max
- Have the steps between
min
&max
distributed evenly (but rounded to a number that depends on the size of the available range)
}; | ||
|
||
function SatButtons({ onClick, disabled }: Props) { | ||
function roundThousands(number: number) { | ||
return number < 1000 ? Math.round(number) : Math.floor(number / 1000) * 1000; |
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 think we need to round here but take into account whether this is the min / max value.
Let's say a service sets 1.4
as their minimum value, we would currently round (which would set the minimum to 1
) which will then fail because it is lower than the min
amount.
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.
Probably it would make sense to add some unit tests for this behavior as well.
cc @escapedcat
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.
Happy to help with unit-tests if wanted once this is fixed.
Hey @fanismichalakis , should we finish this up or do you want to? I assume you're busy and that's understandable. Happy to jump in here! |
Hey @escapedcat, sorry for all the delays! Last few weeks have been a bit challenging indeed, but I'm still willing to finish up if it's okay on your side. I'll have some time next week to work on this, and I have already thought of some ways to address the aforementioned issues. Thanks and sorry again for the delay! |
Alright, awesome. No worries. I just wanted to check in. Thanks for your reply! |
return integralFunction(rounded / Math.pow(10, tens)) * Math.pow(10, tens); | ||
} | ||
|
||
function amountsArray(min: number, max: number) { |
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.
Looking at this is leaving afraid and confused :P
Not sure how others feel. Is there a nice way to makes this easier to digest?
Hi @reneaaron was this fixed by #2152? If yes, I think this issue can be closed. |
@fanismichalakis I think with #2152 we've found a elegant (and less complex) solution to this kind of issue. Thanks for your work on this issue. Although this PR hasn't been merged, it brought up some important improvements! 🙌 @bitcoinuser Yep, thanks for the hint! |
Describe the changes you have made in this PR
Use the
minSendable
andmaxSendable
fields in the LNURLp response to display better suggestions in theSatButtons
component, and disable the "Confirm" button if the input amount is out of the [min, max] range.The values suggested by
SatsButton
still default to 100, 1K, 5K and 10K (current behavior) if theminSendable
andmaxSendable
are missing or if they are "standard" (eg min below 100 sats and max above 10k sats).Link this PR to an issue [optional]
Fixes #1569
Type of change
feat
: New feature (non-breaking change which adds functionality)Screenshots of the changes [optional]
How has this been tested?
Tested manually:
minSendable
andmaxSendable
values are "standard". For example: https://twitter.com/getAlby ;minSendable
andmaxSendable
values are a bit more exotic. For example: https://fanismichalakis.fr, where the LN Markets Lightning Address requires aminSendable
amount of 1000 sats ;SatButtons
component. For example:<SatButtons onClick={setValueSat} disabled={loadingConfirm} min={42000} max={44000} />
to assert that the same amount isn't suggested twice when the
minSendable
andmaxSendable
values are close to each other.I also ran test e2e and unit tests:
Checklist