Pull to refresh

Comments 18

FF 69.0.2 (64-bit) on Ubuntu 18.04.3 — ни одна ваша кнопка не делает ничего. Все примеры неотзывчивы. Ну, либо я что-то делаю не так.

FF 69.0.3 (64-битный), Windows 7
Аналогичное поведение, нет реакции на нажатие кнопок.
71.0b2 (64-битный), win10. Аналогично
Всё из-за того, что FF не работает с тегом
<dialog>
. Изменил примеры, но на суть статьи это не влияет.
У меня есть, но никакой разницы я не увидел
FF 69.0.1 / win7 64 pro
никакой разницы не почувствовал

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

Поэтому до того как загрузятся данные форма заблокирована. Суть в том, чтобы выполнить максимальное количество работы пока загружаются данные. Чтобы когда они загрузились — осталось выполнить минимум. Если отображать прелоадер, то потом его нужно удалять и заменять формой. Лучше всего показать форму, с прелоадером внутри. Но это уже детали выходящие за пределы темы материала.
Пример слишком плохой, чтобы быть хорошим. Классическое решение — отвлечь пользователя. Он не должен следить за тем, в каких полях есть текст, а в каких ещё не загрузился.
1. Нажимает кнопку.
2. Появляется плейсхолдер/лоадер/анимация/что-то яркое и выделяющееся/тип/краткая справка или доп. информация. И не забывает интуитивно понятный интерфейс, а то ещё подумает, что страница зависла и обновит её.
3. Когда все данные готовы, отображается форма. Причём контрастно с заглушкой, чтобы это было видно беглым взглядом.

Но сама идея, что следует использовать промисы. Это да… это одобряю.

Проблема с промисами в том, что их нельзя отметить. Создавая промисы заранее не всегда очевидно, будет-ли еще нужен результат в будущем. В промежутке может произойти ошибка, пользователь может передумать и т.п. Когда задача выглядит как процесс, т.е имеет зависимость от времени, удобнее использовать такие структуры как итераторы, Observable, streams и т.п.

Согласен, но результат промисов можно просто не использовать. Хотя, это зависит от архитектуры.
Что касается ошибки промиса, то его всегда можно поймать в «catch» и уже обработать. Показать сообщение об ошибке/сделать редирект/итд.

Что касаемо отмены промиса. То здесь работа не для промиса, а для самого реквеста. XMLHttpRequest/fetch позволяют вызвать cancel запроса. Промис, он служит для ожидания выполнения.

Замыкания в JS позволяют создавать "отменяемые промисы", "промисы с таймаутами" и т. п.

Попробуйте замерить время выполнения. Скажем с помощью console.time()

Есть много структур, для которых можно продумать осмысленное преобразование к промису. В конце концов промис это абстракция над значением (value).

Я стараюсь придерживать правила, что чем проще сделано, тем лучше.
Пустая выключенная форма потребует дополнительных стилей и логики. Если их написания можно избежать, то лучше так и сделать. То есть просто показать крутилку на месте формы.

Подобные оптимизации имеют право на жизнь, но применять их на практике стоит по необходимости, когда что-то начинает тормозить.
Простота — важна.
Но, суть в том, чтобы не тратить время и в процессе ожидания асинхронного ответа выполнить максимум работы. Выполнить все операции с DOM, добавить элементы где нужно, проставить классы если нужно, применить стили и т.д. Чтобы когда асинхронная операция закончится у вас уже всё было готово. Это не обязательно предложенная мною «выключенная форма».
Может быть добавить нечто подобное в конец статьи? Статья же заявлена как туториал новичкам.
Sign up to leave a comment.

Articles