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
Jenn found a bug in #2174 where the FTE field won't let you put in a decimal point. What happens is that the onChange event formats the entry into a number, which strips off leading zeros and trailing decimal points. (fun fact, if you really want a number like 0.6 you can start with 106, make it into 10.6, and remove the leading 1 ... not the best user experience). So when I investigated I realized that the existing FTE field in the State Cost Categories doesn't have that problem because it formats FTE's as a string. But that means that you can put in bad characters like letters and it won't complain.
DollarField has a pretty neat solution for this where it separates out a changeHandler to allow each character as you type it and blurHandler that does the final conversion into a string. To fix this issue, move (or copy) that functionality to NumberField (move as much as possible so as not to have duplicate code, but keep separate whatever DollarField needs to handle it's own unique formatting requirements)
This task is done when...
NumberField allows numbers with decimals to be entered
The text was updated successfully, but these errors were encountered:
Jenn found a bug in #2174 where the FTE field won't let you put in a decimal point. What happens is that the onChange event formats the entry into a number, which strips off leading zeros and trailing decimal points. (fun fact, if you really want a number like 0.6 you can start with 106, make it into 10.6, and remove the leading 1 ... not the best user experience). So when I investigated I realized that the existing FTE field in the State Cost Categories doesn't have that problem because it formats FTE's as a string. But that means that you can put in bad characters like letters and it won't complain.
DollarField has a pretty neat solution for this where it separates out a changeHandler to allow each character as you type it and blurHandler that does the final conversion into a string. To fix this issue, move (or copy) that functionality to NumberField (move as much as possible so as not to have duplicate code, but keep separate whatever DollarField needs to handle it's own unique formatting requirements)
This task is done when...
The text was updated successfully, but these errors were encountered: