Лучший подход для проверки ввода пользователя? - PullRequest
1 голос
/ 29 апреля 2019

Короче говоря, я хотел бы получить значимые ошибки проверки из firebase / firestore при выполнении транзакции в приложении, при изменении псевдонима пользователя.

Я изо всех сил пытаюсь найти хороший подход.Позвольте мне объяснить на этом простом примере:

TextInput "псевдоним" для страницы профиля пользователя в React Native.Пользователь может изменить значение «псевдоним» и нажать «Сохранить».Если в строке псевдонима что-то не так, пользователю показываются значимые ошибки / обратная связь, например: слишком короткое / длинное имя.Ник содержит плохие слова.Псевдоним уже используется.

Я уже сделал это с помощью облачных функций и вызова https из приложения при нажатии кнопки Сохранить.Это позволяет мне показывать пользователю любые ошибки проверки ввода, так как это правильный запрос к серверу, где я могу выдать ошибку, которая может быть показана непосредственно пользователю.Но это кажется ... неуклюжим?

Проверка на сервере самого псевдонима проверяет длину> 4 && length <20, а также проверку уникальности имени пользователя, плюс некоторые проверки на плохие слова.Уникальность достигается благодаря наличию коллекции Firestore с уже используемыми никами. </p>

Неужели нет более простого способа сделать это?Является ли описанный выше лучший подход?

Было бы легко, если бы я как-то мог выбросить ошибку в правилах firestore и перехватить ее на стороне клиента, а затем показать ее пользователю - тогда я мог бы провести всю свою проверку срегулярные выражения и т.д. только в правилах пожарного магазина.Но все, что я видел, это разрешать и запрещать - это основано исключительно на доступе, поэтому в результате пользователь получает разрешение «отказано», если я пытаюсь выполнить какую-либо проверку.Поэтому я должен выполнить правила в firestore (для безопасности) и написать проверку на стороне клиента, чтобы показать значимые ошибки пользователю (т.е. клиент не отправляет данные, если они не действительны).Без проверки на стороне клиента он просто выдавал бы ошибки «отказано в разрешении» при попытке непосредственного обновления с помощью firebase.firestore.doc ('users / blahblah'). Update ({nickname: new_value}).

Это, конечно, выполнимо, но не так гибко, как просто проверка сервера и выдача сообщений об ошибках - экономит много времени на ввод текста - и не требует обновления приложения, если позже мне нужно добавить больше правил проверки - можно просто сделать этона сервере.

Я просто чувствую, что было бы более элегантно выполнить простую транзакцию в приложении с помощью функций firebase.firestore и иметь возможность ловить ошибки.

У меня такое чувство, что явозможно, что-то упустил, но я провел два дня, обыскивая Google, читая все документы по firebase + firestore и по документам реагировать-native-firebase + примеры.Поэтому я надеюсь, что кто-то здесь находился в подобной ситуации с несколькими минутами, чтобы сэкономить немного мудрости:)

Ура!

Ответы [ 2 ]

1 голос
/ 10 мая 2019

Итак, вы хотите реализовать логику приложения внутри базы данных.Это совершенно нормально.Ваша модель (Entity) имеет правила проверки, определенные на стороне клиента (интерфейс пользователя) и на стороне сервера (приложение сервера).

Чтобы централизовать проверку так, как вы хотите, вам нужно переместить всеправила внутри функций базы данных и / или триггеров.Это то, что я никогда не буду рекомендовать, потому что вы создадите очень важную часть своего приложения на уровне базы данных.После этого шага вам все равно придется делегировать все ошибки на серверный прикладной уровень и обратно пользователю, потому что вам нужно правильно авторизовать пользователя.

Итак, чтобы ответить на вопрос - ДА .Это лучший способ проверки - внутри СЛОЙ ПРИЛОЖЕНИЯ .Оставьте базу данных в покое, это просто хранилище.И ДА, вы можете дублировать некоторые правила там, но в наши дни это просто хорошая практика.

Если, с другой стороны, вы прочитаете несколько книг о дизайне баз данных и о том, как там все работает, вы будетенайдите строгие рекомендации по реализации очень ограничительных правил для объектов, вставленных / обновленных для конкретной модели.

Так что после всего этого чтения вы получите проверку в:

  1. Интерфейс пользователя
  2. Прикладной уровень
  3. Уровень базы данных

Нет простого способа централизовать проверку без потери некоторой гибкости.

0 голосов
/ 10 мая 2019

В таких случаях для разработки удобных для пользователя интерфейсов сообщения об ошибках должны быть надлежащим образом оформлены значимым сообщением путем сопоставления их с кодами состояния HTTP:

200 - valid input
422 - input should meet certain criteria

В вашем случае можно использовать отправку запроса HTTPна сервер (при каждом нажатии пользователя, когда символы> 4), удерживая кнопку SAVE отключенной до последнего успеха службы.

Облачный HTTP-вызов должен отвечать со статусом 200 только при соблюдении следующих критериев:

  • длина ввода> 4 && длина <20 </li>
  • проверка на уникальность имени пользователя
  • проверка на плохие слова

В противном случае неуспешные коды должны возвращатьсяс сервера (который может быть использован для сопоставления с удобным для пользователя сообщением, которое будет показано пользователю).Отображение HTTP-кодов может быть выполнено на стороне клиента или на стороне сервера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...