Всем привет,
Сегодня я собираюсь оценить два типа рендеринга, которые мы можем использовать, когда дело доходит до связи с нашим внутренним сервером, внесения в него обновлений и отображения обновленных данных на нашем веб-сайте.
Как вы, возможно, уже знаете, два типа, о которых я говорю, — это оптимистичный и пессимистичный рендеринг. Не вводите их имена в заблуждение и не думайте, что оптимистичный рендеринг — это путь, потому что ваш жизненный девиз — «всегда оптимист!». Оба они полностью действительны, служат своей конкретной цели и должны выбираться в зависимости от варианта использования, который вы пытаетесь решить.
Итак, давайте погрузимся прямо в…
Оптимистичный рендеринг. Что это такое?
Оптимистичный рендеринг просто обновляет наш внешний интерфейс, не дожидаясь обновления внутреннего интерфейса. Это позволяет нам сделать наш сайт более внимательным к действиям пользователя и сводит к минимуму время ожидания, пока пользователь увидит результат своего взаимодействия.
При оптимистическом рендеринге мы в основном делаем очень высокую ставку на то, что когда мы в конечном итоге отправим данные на наш сервер для обновления, все пойдет по плану, и данные будут получены и обновлены в базе данных без проблем. «Всегда оптимист!». Это верно!
Если вы просмотрите приведенный ниже код, вы увидите, что DOM обновляется до отправки PATCH для внесения изменений в базу данных.
То, что происходит в приведенном выше коде, является примером оптимистичного рендеринга. Пользователь нажимает кнопку «Нравится», мы распознаем событие клика и сразу же увеличиваем количество лайков изображения на экране на 1. Затем мы начинаем вызывать наш внутренний сервер и даем ему указание обновить количество лайков соответствующим образом. Как только наш запрос будет обработан, внутренний сервер обновит и сохранит новое количество лайков, которое будет соответствовать количеству лайков, которое пользователь видит во внешнем интерфейсе. Однако все эти обновления будут происходить на бэкенде асинхронно, и пользователь об этом не узнает.
Как только кнопка нажата, пользователь видит обновленный счетчик лайков, который учитывает их! Красиво и быстро! В этом красота оптимистичного рендеринга!
Что такое пессимистический рендеринг?
Как вы, возможно, уже догадались, при пессимистическом рендеринге мы будем обращать цепочку событий, когда будем обновлять сервер на основе взаимодействия с пользователем. Мы опасаемся ошибок, которые могут возникнуть при отправке данных вниз по течению, и хотим убедиться, что получен успешный ответ от нашего сервера, прежде чем мы обновим внешний интерфейс.
В приведенном выше примере наш счетчик лайков будет обновляться на экране данными непосредственно с сервера после обновления сервера. Это гарантирует, что данные, отображаемые пользователю, всегда совпадают с теми, что есть на внутреннем сервере.
Этот подход определенно менее предпочтителен для конечных пользователей, потому что им, возможно, придется ждать дольше, чтобы увидеть результат своего взаимодействия, но это более безопасный подход, если ваша цель — обеспечить безопасное получение информации вашим сервером.
Как лучше? Примечание от автора
Мне лично нравится оптимистичный рендеринг, и я использовал его при создании функции likeCount в простом приложении NFT Liker. Я сделал пошаговое руководство здесь. Я выбрал оптимистичный рендеринг, потому что я просто храню лайки пользователей на своем локальном json-сервере, и эти транзакции обычно легкие, быстрые и, если что-то пойдет не так, их влияние на конечного пользователя будет минимальным.
Однако, когда я работал в финансовом учреждении, которое выдавало кредитные карты, мы очень стремились избежать оптимистичного рендеринга, потому что хотели убедиться, что каждый пользователь обрабатывается должным образом и получает подтверждение того, что его информация записана нашей системой. Иногда это приводило к тому, что пользователи ждали более 30 секунд на промежуточной странице, но, поверьте мне, это всегда лучше, чем недовольный пользователь, который думал, что его заявка прошла, но в итоге так и не получил от нас ответа. В данном случае пессимистический рендеринг наших данных позволил нам убедиться, что пользователь был уведомлен о получении его данных или, в случае сбоя, ему был предоставлен способ исправить ошибку (см. Обработка ошибок!).
В конце концов, вам решать, какой подход выбрать, но я призываю вас всегда оценивать вариант использования и убедиться, что ваш подход поможет вам достичь конечной цели наилучшим образом.
