Производительность приложений на Bubble. Заметки. Часть 15. Ускоряем workflow.
Данная серия статей — это мои заметки по книге The Ultimate Guide to Bubble Performance. Тут изложено только то, что фиксировал я, т.к. посчитал это важным.
Порядок, в котором выполняются шаги в workflow, влияет на воспринимаемую пользователем производительность.
Возьмём, к примеру, регистрацию пользователя:
На 5 шаге мы изменим custom state, и только после этого пользователь увидит следующий экран. До этого момента пользователь будет ждать, пока Bubble зарегистрирует пользователя и создаст несколько типов данных.
Вот если бы мы поставили этот шаг на первое место, то тогда пользователь наблюдал моментальную смену экранов после нажатия кнопки и это бы добавило очки в видимую производительность.
Триггеры
Некоторые операции можно убрать с кнопок и запускать по триггеру. Это позволит сделать приложение в глазах пользователя быстрее.
Например, в ситуации с регистрацией пользователя мы можем убрать все шаги и оставить только тот, который устанавливает custom state для смены экрана на следующий.
А вот все остальные шаги мы можем закинуть в wf, который запускается по условию (Do when condition is true).
Подобный подход позволит сделать воспринимаемую производительность быстрее.
Оптимизация wf
Смысл в том, чтобы взять тяжёлые wf и размазать их таким образом, чтобы они стали короче или вовсе незаметными для пользователя.
Разбиение wf на несколько
Возьмём, к примеру, процесс регистрации пользователя — мы могли бы дать пользователю заполнить одну длинную форму регистрации и в конце внести все данные в БД. Это бы определенно притормозило приложение и заставило пользователя подождать обработки данных.
Но мы поступим иначе. Разбьём форму регистрации на несколько экранов, и пока пользователь вносит данные на очередном экране, мы запускаем на фоне wf, который обрабатывает данные с предыдущего экрана.
Важно. Такой подход чреват возможностью лишних данных. Скажем, пользователь не выполнил все шаги, а инфа по предыдущим уже сохранилась в БД.
Условия и поиск до востребования
Суть в том, что проверяем условия и выполняем поиск, которые встречаются в wf, до момента, когда они понадобятся.
Проверка condition и search заранее позволит сократить время выполнениея wf, т.к. он уже будет работать с известными данными.
Например, нужно сделать проверку на наличие пользователя с email, который введен в input. Если такой юзер есть, то нового пользователя мы регать не можем.
Чтобы ускорить процесс, мы создадим группу, в которой Bubble будет делать поиск сразу же после ввода информации в input.
Пользователь не заметит этого, т.к. полосы загрузки не будет, и он будет отвлечен на ввод пароля.
Bubble выполнит поиск и вернёт число в группу.
Теперь на этапе регистрации мы будем выполнять проверку на число, хранящееся в группе.
Сообщения об ошибке
Подход, описанный выше, можно прокачать и использовать для сообщений об ошибках.
Теперь перед регистрацией мы проверяем пустая ли группа с текстом. Если пустая - регистрируем пользователя.
Если она не пустая, то показываем alert с текстом из группы.
Подобные подходы позволяют минимизировать сложные проверки в wf. А это, в свою очередь, повышает воспринимаемую производительность.
→ Подписывайтесь на мой канал в Телеграме Иван Некодит.