Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
пользователь может ввести в строку набор цифр и букв, например, '5s68d.4r55e.6t5', а на сервер я должен отправить корректное для сохранения сумму в рублях — '568,455' (рублей)
Для тестового задания пойдет, а в жизни такой подход применять крайне опасно. Что если ваша 't', это опечатка, при попытке нажать '6'?
По этой причине старший товарищ дал указание написать функцию на событие keypress
А старший товарищ не дал линейкой по рукам и не предложил готовое решение, коих в интернете пачка?
jsfiddle, тесты — это раз
ужасный английский в readme — это два
ужасная организация кода — это три
PS собственно сам денежный формат с кучей фич влезает в 27 строчек кода(на 12 кейсов) + «обёрточная мишура» на 25 строк + сеттер/геттер позиции курсора(необходимо только для FF, возможно уже и пофикшено). Выложить код к сожалению не могу, но однозначно есть способ сделать это лучше.
PSS далеко ушли от собственно говоря реализации денежного формата. В идеале это две функции «на выход» — одна собственно которая превращает строку в денежный формат, другая — умеет превращать DOM-элементы в тип денежного формата.
ужасный английский в readme — это два
ужасная организация кода — это три
PS собственно сам денежный формат с кучей фич влезает в 27 строчек кода(на 12 кейсов) + «обёрточная мишура» на 25 строк + сеттер/геттер позиции курсора(необходимо только для FF, возможно уже и пофикшено). Выложить код к сожалению не могу, но однозначно есть способ сделать это лучше.
PSS далеко ушли от собственно говоря реализации денежного формата. В идеале это две функции «на выход» — одна собственно которая превращает строку в денежный формат, другая — умеет превращать DOM-элементы в тип денежного формата.
ужасная организация кода — это три
буду рад если подскажите как организовать код лучше
буду рад если подскажите как организовать код лучше
Дай человеку рыбу и он будет сыт один день…
Посмотрите что-ли курсы в интернете, попишите например на Vanilla JS framework(или на любой другой устоявшейся либе/фреймворке). Да хотя бы гляньте на код TODO app'a.
Просто бесполезно объяснять что не так с кодом. Это приходит со временем или вообще не приходит.
Посмотрите что-ли курсы в интернете, попишите например на Vanilla JS framework(или на любой другой устоявшейся либе/фреймворке). Да хотя бы гляньте на код TODO app'a.
Просто бесполезно объяснять что не так с кодом. Это приходит со временем или вообще не приходит.
А вставка из буфера обрабатывается?
<input type="number">
<input type='number' step='0.01'>
And everybody is happy.
Nah?
And everybody is happy.
Nah?
Как и обычно встроенные инпуты работают не идеально с минимальными возможностями исправить поведение. Понятно что нативные элементы работают _лучше_(в широком смысле этого слова, например в разных окружениях), но не всегда так как хотелось бы. Лично мне приходилось писать и textarea и select'ы и эмулировать таблицу div'ами просто потому что так — гибче. Ну и типичный пример — ужасно-некрасивый скролл внутри документа от которого дизайнеры плюются а пользователей коробит.
Вот если бы можно было «внутрь» нативных элементов залезать тогда да(на самом деле уже «можно» с помощью Webcomponents/Shadow root вот этого всего), но пока что — приходится извращаться.
Вот если бы можно было «внутрь» нативных элементов залезать тогда да(на самом деле уже «можно» с помощью Webcomponents/Shadow root вот этого всего), но пока что — приходится извращаться.
где в данном примере заканчивается сумма в рублях и начинаются копейки?
В данном примере нигде. Введенная строка не является валидной суммой и об этом должно быть сообщено пользователю.
Я может быть глупость спрошу, но зачем все эти переподвыпернверты? Выше написали поо input type number, а обо всем остальном надо оповестить пользователя. Если вы хотите чистить данные перед отправкой их на сервер, то мне кажется это глупо, ибо данные можно отправить и без инпутов.
Не знаю зачем оно нужно, но для полноты функционала нужно обрабатывать и то что из буфера вставляется.
По этой причине старший товарищ дал указание написать функцию на событие keypress.
…
Код взят со steckoverflow, но мой код мало чем отличался от примера выше.
…
Всё выглядело красиво — пользователь не видит вводимых чисел и курсор не перебрасывает в конец строки, но, как оказалось, радовались мы рано. Если смотреть на keycode клавиш на разных операционных системах (mac, linux, win), то они имеют некоторые различия, а если к этому прибавить то, что не у всех маков есть numPud и, следовательно, числа вводятся с зажатым шифтом и также цифры могут вводится с виртуальной клавиатуры. В итоге получается код во много раз больше, чем последний пример.
Разница есть. Ваш товарищ дал вам указание использовать keypress, а в примере keydown, в этом и есть разница
У keypress будет код финального символа, а у keydown будет выдан keyCode клавиши плюс флаги нажат ли shift, alt и т.д, раскладка игнорируется. Можно проверить в живую: https://learn.javascript.ru/keyboard-events
То есть если у нас keypress и нажать 1 мы получим keyCode=49, с зажатым шифтов получим уже keyCode=33
Если у нас keydown и нажать 1 (хоть с шифтом, хоть с чем угодно) мы всегда получим keyCode=49 на любой клавиатуре, на любой ОС, хоть на виртуальной клавиатуре планшета
Аналогично даже если текущая раскладка русская, нажимая точку получаем 'ю', но keyCode всё равно будет 190 (как и у просто точки), а не 1102 (код символа 'ю')
Зачем это всё? Уже много лет есть куча готовых и проверенных решений для jQuery.
Занимательная статья.
Занимательно в ней все. Особенно меня впечатлили steckoverflow и numPud…
… Представляете… целый пуд нумов в английском переполнении немецкого штекера.
Занимательно в ней все. Особенно меня впечатлили steckoverflow и numPud…
… Представляете… целый пуд нумов в английском переполнении немецкого штекера.
1,234.5
1234.501
1.234,50
1234,5
1234-50
а такие суммы одинаковы или нет? =)
В свое время решал подобную задачу на Java и это был основной вид сумм в документах от разных бухгалтерий, которые приходилось распознавать. Были и другие, менее популярные.
1234.501
1.234,50
1234,5
1234-50
а такие суммы одинаковы или нет? =)
В свое время решал подобную задачу на Java и это был основной вид сумм в документах от разных бухгалтерий, которые приходилось распознавать. Были и другие, менее популярные.
Получил я достаточно стандартное задание: фильтровать вводимые юзером символы в input
Задание то стандартное, но подошли вы к нему не с той стороны. Если просто потренироваться — возможно. А для реальных приложений так делать не стоит.
Какой смысл распознавать пользовательский бред? Особенно когда он не однозначен. Проще сообщить, что введенное выражение не соответствует. Дальше то все равно последует серверная валидация.
А если и нужны ограничения на этапе ввода, то проще type="number" или атрибут pattern.
простая функция фильтра инпута от букв, т.е. вводивые буквы не появляются в инпуте. Вешается на oninput
function(){
event.target.value = event.target.value.replace(/[^0-9\.]/g,'');
});
http://codepen.io/vasyatopor/pen/kkAmZW?editors=1010
Дальше сами модернизируйте
function(){
event.target.value = event.target.value.replace(/[^0-9\.]/g,'');
});
http://codepen.io/vasyatopor/pen/kkAmZW?editors=1010
Дальше сами модернизируйте
А если ввести 5e3 рублей?
Ведь это верная запись = 5000 рублей
Что прикажете делать с этим?
Ведь это верная запись = 5000 рублей
Что прикажете делать с этим?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фильтр символов вводимых в input