PreRender

Концепция предварительного рендеринга предстоящего компонента, чтобы пользователь не ждал.

Понимание PreRender

Подумайте о просмотре Tinder для пролистывания изображений. Скажем, эти изображения огромны по размеру в несколько мегабайт. Теперь, если вы хотите отобразить каждое изображение после того, как пользователь провел по текущему, изображение будет загружаться в течение нескольких секунд, прежде чем отобразить его на самом деле (например: 2 секунды для каждого изображения, которое будет отображаться). Любой пользователь потеряет терпение из-за такого медленного рендеринга.

<img src={current_image} />

Как я могу решить эту проблему?

Используйте два места для изображений вместо одного. Сначала загрузите данные первого изображения и выполните рендеринг в первом слоте как обычно. А вот и второй трюк. Вместо того, чтобы ждать, пока пользователь проведет пальцем по экрану, а затем загрузить изображение, начните рендеринг изображения сразу после того, как первое изображение будет назначено на слот один.

Поступая таким образом, мы не блокируем отображение текущего изображения, а вместо этого заранее визуализируем следующее. Теперь мы скрываем предварительно визуализированное изображение от пользователя, используя hide className или устанавливая высоту 0 пикселей в случае React Native.

Рассматривая данные как массив из двух элементов и отслеживая активный индекс, мы можем решить, какие данные извлекать, а какие отображать.

onSwipe() {
// make pre-render the active image
const availableSlot = this.state.active;
if (this.state.active === 0) {
    this.setState({ active: 1 });
  } else {
    this.setState({ active: 0});
  }
// now start fetching the next image and assign it to the availableSlot
  const images = this.state.images;
  images[availableSlot] = newImage;
  this.setState({ images });
}
render() {
  return (
    <div>
     {
       this.state.images.map((image, index) => {
         return (<img
          src={image}
          key={index}
          style={{ height: this.state.active === index ? '100%' : 0 
         }} />);
       });
      }
    </div>
   );
}

Если вы присмотритесь, на самом деле мы используем возможность реакции, чтобы избежать повторного рендеринга компонента, когда ключ остается таким же для того же набора данных. Итак, мы установили key = {index}, хотя это не предлагается.

Эффективность

Ранее предполагалось, что рендеринг каждого изображения занимал t секунд, а пользователь просматривал изображение в течение x секунд. Общее время, затрачиваемое только на ожидание обработки n изображений, составит n * t секунд.

Но с предварительным рендерингом пользователь должен просто подождать t секунд, которое было для первого изображения и загрузки всех остальных изображений в течение времени просмотра, равного x секунд.

Независимо от количества изображений у нас всегда будет время отрисовки t, учитывая, что пользователь просматривает каждое изображение дольше, чем время отрисовки (x ›t).

Примечание: это не обязательно должны быть изображения, которые должны быть предварительно обработаны. Любой компонент, данные которого известны заранее, может быть предварительно обработан.

Обновление

Масштабируя массив до n элементов, мы также можем поддерживать несколько слотов, из которых вы можете выбрать один для отображения следующим. например: имея три слота и в зависимости от направления движения выберите активный слот и доступные слоты для замены данных.

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

Замечательно ❤, теперь мы добились высокопроизводительных пользовательских интерфейсов. У нас есть аналогичные варианты использования в просмотрах продуктов в электронной коммерции, изображениях в фотогалереях и т. Д.