-
Notifications
You must be signed in to change notification settings - Fork 1
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
Fix input field bugs #166
Fix input field bugs #166
Conversation
✅ Deploy Preview for pendulum-pay ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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. This works almost perfectly.
Edge cases:
- e.g., text is
123.45
and I mark the part "3.4" and press "." I expect it to be replaced by 12.5, but nothing happens - the input field allows to paste anything nonsensical (text, numbers with two ".", etc) – in this case the calculation of
debouncedAmountBigDecimal
has an unhandled exception as it expects that the input form is always a valid number (we could wrap this into a try catch)
It is fine the way it is, already a big improvement. Therefore, I approve.
If it does not make too much effort, the above two points could possibly be addresses by not preventing default in handleOnKeyPress
(remove this handler altogether) and just normalizing all text in handleOnInput
(i.e., filter out everything outside [0-9.]
and then remove any additional .
after the first one and then remove extraneous decimals).
src/pages/swap/index.tsx
Outdated
@@ -128,7 +128,7 @@ export const SwapPage = () => { | |||
} else { | |||
form.setValue('toAmount', ''); | |||
} | |||
}, [form, tokenOutData.data, toToken]); | |||
}, [form, tokenOutData.data, toToken, inputAmountIsStable]); |
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.
Usually it is considered bad practice to add variables to the dependency list that don't occur inside the function. Why is this necessary here?
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.
True! the issue is the following scenario:
- Let's say in the field we have
12
and we add.
at the end. I noticed that this won't execute this effect, therefore not settingsetIsQuoteSubmitted(false);
which leads to the quote being disabled.
Now I don't understand why this is the case, since the form state changes and should trigger this, but it didn't. Therefore I decided to add inputAmountIsStable
which will always go from false
to true
after a change in input.
Do you think we can make an exception? or shall we explore why form
doesn't get updated?
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 ended up removing the use of isQuoteSubmitted
here. I think the loading property of tokenOutData
should be enough to mark toAmount
as disabled. WDYT? This also solves the bug I mentioned above.
Only this modification was needed.
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 it makes sense that the effect was not executed. setIsQuoteSubmitted
was always set to true
whenever the input field changed. But when the input field changes in a way that the output amount calculated through Nabla does not change (as is the case when just adding a .
), then the effect will not be triggered to reset setIsQuoteSubmitted
to false and the output field stays disabled.
I think it is exactly right to only use the loading
property of tokenOutData
as this correctly reflects that the output amount is currently being determined. So nicely done.
target.value.slice(0, firstDotOccurence + 1) + target.value.slice(firstDotOccurence + 1).replace('.', ''); | ||
} | ||
|
||
if (exceedsMaxDecimals(target.value, maxDecimals)) { | ||
target.value = target.value.slice(0, -1); |
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.
Here we should not just remove one final digit but all extraneous digits at once (otherwise this whole function will be called repeatedly and each time only one extra digit will be removed until no more digits can be removed and target.dispatchEvent
will not be called anymore).
target.value = target.value.slice(0, -1); | |
target.value = target.value.slice(0, firstDotOccurence + 1 + maxDecimals); |
Should work because firstDotOccurence
is defined whenever exceedsMaxDecimals
is true
.
target.value = target.value.replace(/,/g, '.').replace(/[^0-9.]/g, ''); | ||
|
||
// Handle case where user tries to add a second decimal point, we keep the leftmost one. | ||
let firstDotOccurence = target.value.search(/[.]/); |
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.
Let's change to const
(linter complains).
let firstDotOccurence = target.value.search(/[.]/); | |
const firstDotOccurence = target.value.search(/[.]/); |
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.
@TorstenStueber Thanks for noticing these edge cases for NumericInput. I think they definitely need to be added to NumericInput.test.tsx
in Portal. I think we should make the changes in Portal as well. I have created a PR that fixes these errors and creates test cases here: pendulum-chain/portal#561. Can we just copy this into Vortex?
While unfortunate, I agree with @Sharqiewicz that it would be better first to fix the NumericInput field in the portal and then copy it over. The implementation used in the prototype originates from the portal but must be a version added prior to some improvements added to the portal input in the meantime. The input sanitization is overall easier to read in the NumericInput component of the portal IMO. |
@Sharqiewicz @ebma I'm okay to wait for the portal changes and then modify this. I think it still may be a bit different given how the consumers of the form in Vortex handle the value. For instance, this part was not my first choice, yet it was important, otherwise the form would receive the uncleaned string (which lead to the empty string error when deleting fully the amount, for instance). |
@TorstenStueber I will wait to address your last comments until we have consensus on the previous comment. |
We merged the equivalent changes to the portal in pendulum-chain/portal#561. @gianfra-t please copy 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.
Can you please also fix the following bug (which has been introduced before): https://github.com/pendulum-chain/vortex/pull/166/files#diff-777e0c2221f5feeef076c359496045ddd95d6d376a0fc1395b330f8a9b64a5bbR91
Here we also need to check whether tokenOutData.stableAmountInUnits
is the empty string. Otherwise the Big
constructor throws an error. If it is the empty string, then we can treat inputAmountIsStable
as false
.
Yes, I copied the portal fix but it is not ready yet. As you say it requires a few extra checks to work properly here. |
@TorstenStueber now it should be good. I added the handling of empty string, only |
@@ -1,4 +1,5 @@ | |||
import { useEffect, useMemo, useRef, useState } from 'preact/hooks'; | |||
import { Fragment } from 'preact'; |
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.
This is not used.
@gianfra-t Thanks for the changes. Can you please still implement this? #166 (review) |
@TorstenStueber I (re)added the empty string condition here, is it the same issue? Nevertheless I added the condition you were referring here. |
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.
Great. Thanks!
Hey @Sharqiewicz, we copied (most) of the sanitizing implementation from the portal as you suggested. Thanks! |
…et-dump-always-creating-new-sheet
Fixes #164.
Additionally, it fixes: