retail-ui
retail-ui copied to clipboard
skbkontur
[CurrencyInput] Давать возможность вводить значения больше чем для типа Number IF-1033
Для контролов CurrencyInput, CurrencyLabel и FxInput с type="currency" необходимо добавить возможность вводить большие числа У нас сейчас есть формы, где целая часть может быть 19 знаков или 17 знаков целая и 2 дробная
Сценарий:
- https://tech.skbkontur.ru/react-ui/#/Components/CurrencyInput
- не вводится значение больше 999 999 999 999 999 (если нет дробной части)
Можно попробовать реализовать вариант CurrencyInput в виде дженерика с типом number по умолчанию. Ограничить тип дженерика двумя типами number | string. И вероятнее всего придется потрогать хелперы функции работающие со значением
Хей, всем привет. Допустим я хочу зарешать это ишью. Есть понимание как это делать? Имею ввиду, в какую сторону менять публичное апи контрола. Коммент от Димы выше как-то не дал мне понимания. Ибо, как я понимаю, надо не сломать текущее поведение (ну когда в value/onChange работают с number), и как-то дать возможность принимать другой тип (строку?). Короче, маинтейнеры, хелп.
В варианте Димы публичное апи вообще не меняется, кроме появления возможности явно передать тип в дженерик. Но в общем случае он сможет выводиться сам из value.
Таким образом, кажется возможным просто дополнительно разрешить передавать строки, как описал Дима, наладить их обработку внутри с сохранением типов на выходе, и снять для строк ограничение на количество символов.
Можно попробовать.
Отмечу на всякий случай: дженерик аргументы в рантайм не попадают.
Давай разберём случаи:
- я передал number = 0, пользователь набирает 20 символов и мне после 15-го в onChange выпадёт строка?
- я передал undefined, сразу строка в onChange упадёт или после 15-го символа
- я переда строку = 0, пользователь вводит "1", мне сразу строка?
- я передал строку, пользователь всё стёр до состояния undefined, как дальше быть? Вот он, после того как стёр снова набирает символы, мне number полетит в onChange или строка?
Ок, теперь понял. Проблема-то глубже.
Кажется, что даже если придумать новый проп для этого, то будут проблемы с типизацией.
В качестве другого решения на обсуждение, можно было бы вытащить из CurrencyInput базовый контрол, который полноценно работает со строками, положить его в internal или на парковку. А поверх сделать обертку со старыми типами и ограничениями.
Я не хочу вмешиваться в вашу "стратегию развития публичного апи", если у вас есть такая. Могу предложить вариант такой: передавать доп. проп, который управляет преобразованием типов. Ещё была история с дейтпикером аналогичная: там боролся тип Date то ли со строкой, то ли со структурой из трех полей. Может поступить так же как и там сделали.
В общем что я хочу: вы решите как вам кажется правильно, и отпиши сюда, а я уже двинусь в этом направлении.
Если удастся обойтись пропом и сохранить совместимость, то это будет норм. Но в том, как я это себе представляю, есть проблема типизации. Может быть я не так понимаю решение.
Посмотрю как там было с дейтпикером.
Моя мысль такая: CurrencyInput делаем дженериковым, добавляем проп, из него выводится аргумент дженерика.
С дейтпикером там вышло не очень, от него отпочковался DatePickerOld.
А твой вариант звучит неплохо.
Короче. Спросите Диму Рыбака (@CrazyRyDmi), У нас есть починеный контрол, живет уже довольно давно. Может он согласиться его к вам передвинуть.