Comments 24
Вот бы Rutube прочитал статью и начал правильно email адреса с + обрабатывать и ошибки отображать, что в мобильном приложении, что на сайте.
На первый взгляд выглядит не так плохо, но я по-прежнему убеждён что если можно не маскировать (а это можно практически всегда), лучше этого не делать. Особенно с номерами телефонов, хотя к остальным полям тоже относится. Пара примеров из тестов данного проекта просто чтобы отговорить тех, кто считает что сейчас быстренько плагин маскирования, этот или другой, накинет и всё будет хорошо.
1) Вы можете не знать всех нюансов данных, которые вы запрашиваете.
Например, email. Или почтовый адрес. Или номер карты. В данном случае с картой всё выглядит хорошо: payment card number до 19 символов, autocomplete расставляет всё по своим местам. Но вот на попытку маскирования email я бы посмотрел.
2) Современные браузеры приучили нас не запоминать номера карточек или телефонов.
Эти данные хранятся в телефоне, как номера контактов, или в браузерах, как данные карт. И люди, не часто пользующиеся роумингом могут спокойно всю жизнь использовать номера с префиксом 8 вместо +7. И тут маскировщики при вставке номера с другим, но корректным префиксом начинают резко ломаться, отъедая последние цифры номера, к сожалению, данный не исключение.
3) Прочие мелкие досадные проблемы.
У кого-то, как у госуслуг, вставка некорректно начинает работать. Здесь попроще: в expiry date нельзя ввести нолик в месяц начать писать, хотя placeholder mm/yy.
В любом случае, спасибо за перечисление ингредиентов, освежить их в памяти всегда полезно!
Спасибо за подсвеченные моменты. К версии 1.0.0 обязательно поправим!
Как-то имел большой спор с товарищем (хороший очень опытный программист) на тему маскирования поля с телефоном.
Я говорил, что пусть вводят как хотят, в любом формате — в чем проблема убрать из строки все пробелы/дефисы/скобки/етц, оставить только цифры и так записать в базу? А он отстаивал вариант с маской — мол, помимо удобства программиста, так и пользователю тоже удобнее, потому что подсказывает формат данных и снимает вопрос "а что от меня хотят?"
Спорили долго, но каждый тогда остался при своем мнении.
Я тоже придерживаюсь вашей позиции. Подсказать формат можно в текстовом описании рядом с полем, обычный placeholder всё равно во время ввода уже будет не виден. Плюс, провести вариацию поля и показать галочкой рядом с полем что всё хорошо. В идеале, правилом, подтянутым с бэкенда, а то, бывает, разъезжаются между бэком и фронтом.
Ваше мнение сводится к привычке. Для примера мне удобнее вводить номер банковской карты там, где есть автоматическое разделение пробелом между цифрами аналогичной той схеме, что и на самой карточке. К хорошему привыкаешь быстро)
Пробел при разделении номера карты это хорошо и красиво, главное чтобы остальные сценарии не ломались, особенно autocomplet-а (да, к хорошему быстро привыкаешь и я хочу чтобы за один клик PAN/Expiry/CVV2/Name подставились, а не вводить что-то руками). Но помимо него есть 101 способ накосячить с другими типами полей.
Кстати, например, у Google при авторизации нет маскирования. Просто всегда видная подсказка: телефон или email.
В базе хранить цифры, пользователю показывать производные комфортные значения.
Какие цифры хранить, которые ввёл пользователь или отформатированные под определённый формат? Если с номером не нужно никак работать и достаточно только показать его, то конечно можно хранить как угодно. Только вот, если номер нужно использовать и номера могут быть разных стран, то начинаются проблемы. Нужно как-то валидировать, форматировать, быть удобным для пользователя, быть валидным для использования. Всё это должно поддерживать последние изменения, когда, например, добавляют новый код оператора… И тут действительно всё сложно
У нас в Тинькофф принято работать с форматом +XXXXXXXXXX, а выводить отформатированным. Разумеется 8 автозаменяется на +7 и при написании, и при вставке/дропе, и при автофилле. Как и все посторонние символы вроде пробелов и дефисов заменяются на заданный формат.
Красиво отформатированный ввод, если он сделан корректно, создаёт у пользователя ощущение опрятности интерфейса, помогает ему сверить значение (например разделение тысяч пробелом при форматировании суммы), не препятствует вводу и исправляет ошибки (например, если забыл переключить язык и набираешь точку/запятую/ю/б при вводе копеек). То, что это сложно сделать хорошо не повод отказываться от преимуществ, которые это даёт продукту. Наше дело, как фронтендеров, дать пользователю интерфейс, решающий его задачу настолько хорошо, насколько мы можем. Будем стараться!
На странице просто базовый международный пример, который не хотелось усложнять, так как 8/+7 чисто русская тема. Когда выпустим maskito 1.0 и начнём на него переходить, то обязательно всё это учтём :)
>8/+7 чисто русская тема
У других 0 вместо 8, а проблема та же. Те же британцы тоже не пишут +44, даже когда дают свои номера иностранцам пишут номер с внутренним кодом.
То, что это сложно сделать хорошо не повод отказываться от преимуществ, которые это даёт продукту
Это не так сложно сделать в контексте одной страны, но как вам уже и ответили - это сложно для международных проектов.
У нас в Тинькофф…
… ввожу код 999 в форму авторизации и вижу 500 ошибку с текстом «у нас проблема»
… ввожу номер с неверным кодом, пытаюсь исправить код: одна цифра заменяется, дальше курсор прыгает в конец
… ввожу 89011231212 получаю сообщение, что номер невалиден
Вот как раз для того, чтобы такого не было, а было одно централизованное хорошее решение с выделенными ответственными людьми и была создана библиотека, которая упоминается в конце статьи :) Кроме того, она будет в open source и, надеюсь, пригодится не только нам. Но сначала надо её доделать и внедрить.
Так для телефонов такая библиотека давно есть и Google я как-то больше доверяю в знании международных деталей google/libphonenumber: Google's common Java, C++ and JavaScript library for parsing, formatting, and validating international phone numbers. (для JS может быть лучше порт libphonenumber-js)
хороший опытный программист обычно склонен заблуждаться в удобстве того или иного контрола
С кодом страны и внутренним кодом больше всего проблем и возникает при таких масках. Лучше всего оставлять проверку на минимальную длину номера. Да и с почтой весело, когда многие маски ломаются, если в адресе почты есть +.
У меня возник запрос на подробности, как лучше держать в одном репозитории 3 npm-пакета.
Как удобнее организовать их взаимосвязи, тесты, демки, должны ли они тянуть друга как зависимости или пусть пользователь вручную разбирается — и так далее.
Многие заботы взял на себя Nx.
А про зависимости. Главный пакет не имеет зависимостей, а все прочие опциональные пакеты заявляют их через peerDependencies.
Это не последняя статья про Maskito, так что учту этот запрос в будущей статье.
У меня только один вопрос, почему нет документации на русском? И тут проблема не в том что я не могу читать на английском, просто интересно. Почему даже если решение разрабатывают русские разработчики то документацию всегда на английском... Неужели так сложно совместить 2 языка, особенно когда русский язык - родной?
Признаюсь, что создание документации и ее постоянная актуализация - уже нелегкая задача. А если еще нужна поддержка нескольких языков, то задача сильно усложняется.
Так как пользователи библиотеки - это разработчики, то делается допущение, что пользователи владеют английским хотя бы на уровне «умею читать техническую документацию».
Согласен, что любому нашему пользователю было бы удобнее читать документацию на своем родном языке. Но данное допущение позволяет нам сосредоточить сэкономленные время и силы на более приоритетные задачи по дальнейшему развитию библиотеки.
Вопрос узконаправленный, но может)
Добавьте поддержку координат) Десятичных и географических)
А то пришлось писать самому это всё)
Реализации какие-то есть, но там то долгота может быть больше 180 градусов ( а не может она быть больше 180 ) по гео координатам, то нет функции обрезать/не обрезать число после точки в десятичных)
В целом, будете "крутышками" )
Трудности маскирования текстового поля