You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an invalid string value for offer number, the one that has leading or trailing whitespaces ( " 501234567" or "501234567 " ), is pasted inside the input field which has binded [value] property of the <bal-input> form still considers this string as invalid, as it should because it's invalid to regex matching, but it is properly piped, giving the user right output in the input field (for mentioned examples it is "50/1.234.567"). This gives the user the wrong sense that the data provided are correct, though they are not.
As I've investigated a bit, the problem comes down to using parseInt inside balOfferNumber because this will parse to number regardless of whitespaces. Maybe we should reconsider including the check for the length of the string before doing anything else in this function?
The text was updated successfully, but these errors were encountered:
Hi @predrag-arsic
Is this issue still relevant?
Could you elaborate a little about the actual and desired behaviour?
As far as I understood from your description a number with leading/trailing whitespaces is formatted correctly. Which sounds pretty good to me, as I think a user should be allowed to enter whitespaces there.
When an invalid string value for offer number, the one that has leading or trailing whitespaces ( " 501234567" or "501234567 " ), is pasted inside the input field which has binded [value] property of the
<bal-input>
form still considers this string as invalid, as it should because it's invalid to regex matching, but it is properly piped, giving the user right output in the input field (for mentioned examples it is "50/1.234.567"). This gives the user the wrong sense that the data provided are correct, though they are not.As I've investigated a bit, the problem comes down to using parseInt inside
balOfferNumber
because this will parse to number regardless of whitespaces. Maybe we should reconsider including the check for the length of the string before doing anything else in this function?The text was updated successfully, but these errors were encountered: