BonBonSlick
@BonBonSlick
Junior Web Developer Trainee

Блокировать всю форму или экран при отправке формы?

В размышлениях, блокировать все или только форму которую отправил пользователь.
Пример, на тек момент юзер нажимает отправить форму, кнопка и все инпуты disabled.
В кнопке крутим спиннер что идет отправка.

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

Другой вариант, блокировать всю форму и инпуты, кнопки + вместо спиннера в кнопке, делать модальное окно на весь экран и блокировать любой ввод даннх и переход куда либо. Тогда пользователь, вынужден будет ожидать ответа с сервера об удачной регистрации, это может занимать от 5 сек до 15 в моем случае. Но даже если не брать в расчет время оиждания в моем случае, что более user friendly?
  • Вопрос задан
  • 26 просмотров
Решения вопроса 1
BonBonSlick
@BonBonSlick Автор вопроса
Junior Web Developer Trainee
Путем трайла вывел следующее
1 - все формы PATCH / PUT / POST должны блокировать весь экран на всех страницах. Что очень важно в SPA, юзеру может взбрести в голову перейти на другую страницу в другой вкладке. Поетому в моем случае Vue + Vuex создаем state: { isScreenLocked: false } и считывать
2 - исключение мелкие запросы такие как LIKE / SUBSCRIBE / ADD TO FAVORITE и проч можно оставить без блокировки, а всего лишь тогглить кнопку на спиннер.
3 - все GET запросы НЕ блокируют экран, просто обычно гет запросы используются для подгрузки данных при переходе на страницу и страница грузится кусочками. Там мы отображаем дефолтные превью макеты, что будет подгружено или просто спиннер. И еще геты используют для поиска данных, тут уже надо смотреть на сколько тяжелый запрос что может перейти в 4
4 - при очень тяжелыхх запросов GET блокировать екран, почему? Потмоу что юзер открыл 10 вкладок и запустил хеви запросы. По сему на клиенте такие проверки как (1 - блокировка екрана, 2 - проверка идет ли уже загрузка запроса) помагают снизить нагрузку на серв, на которому так же лолжны обязательно стоять рейт лимиты, к примеру 10 запросов в 10 секунд это более чем достаточно, учитывая что рендеринг занимает минимум 2 сек, ниже 1 сек не видел, даже гугл 2.7 рендерит результаты поиска.

Почему именно так? Да потому что нельзя все время блокировать как и нельзя не блокировать. Золотая середина в том что иногда надо, а иногда нет.
Мой пример с которым столкнулся, вот тот же Login / Register, это 2 страницы, но на них по 4 формы условно.
И если хоть одна форма в процессе отправки или обработки, необходимо лочить все другие формы что создает дохрена кода. Более того, если юзер все же перейдет на другую страницу то и там надо лочить формы.
Зачем лочить формы на одной странице? Банально, юзер не может одновременно залогинится используя все соц сети, логин и пароль одновременно. Тоже самое с регестрацией.
Для чего лочить формы на других страницах? А что если юзер нажал вход и пошел регестрироваться? Вот переключил страницу или она у него была открыта? Возникают баги, единственный вариант пофиксить которые чистить весь кеш сайта, лок сторедж и куки.
А посему, решение таково:
1 - добавить в рутовом шаблоне модальное окно которое подключено к единственному состоянию на все приложение ModalLockScreen, обязательно должно быть одно состояние
2 - добавить само состоание lockScreenModal: {isShown: false} и екшен для тоггла
3 - програмно в удобном месте тогглить состояние ModalLockScreen состояние, в том же рутовом шаблоне идет проверка computed для isShown лок скрина. Проблемы могут возникнуть когда у нас еще будут модальные окна которые конфликтуют с isShown, решения 2, переименовать isShown или использовать что то в духе
get isConflictedModalShown(): boolean {
        return store.getters[`${this.namespace}/isShown`];
    }

TS динамический компутед в компоненте который перезаписывает кофликтующие имена екшенов. Но у него огромный недостаток, это импорт всего хранилища, store в компоненте и вызов на прямую.
Другой вариант, переопределить имя в самом store -> action модуля.
Аналогичный подход и для native JS без TS с динамическими модулями.

Если модальное окно не нравится, SPA как никак, можно использовать middware он же guard при переходе на стринцы проверять заблокирован ли екран, и делать так же как с страницей 404, перенавлять.
В рутовом шаблоне тоже стоит добавить проверку, потому что guard отрабатывает единожды до того как компонент будет created. Если ранее окно было открыто и состояние изменилось, guard это пропустит и юзер сможет трогать формочки. Для чего гуард тогда? Небольшая оптимизация, компоненты, формы бывают тяжелые гуард предотвратит их создание и рендеринг.
Ах да, и еще, в случае с редиректом надо помнить ту страницу где форму сабмитили, что бы по завршению лок скрина редиректить обратно, посему модальное окно поверх всего, оптимальный вариант.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы